The PHP Scalability Myth
by Jack Herrington10/15/2003
PHP scales. There, I said it. The word on the street is that "Java scales and PHP doesn't." The word on the street is wrong, and PHP needs someone to stand up and tell the truth: that it does scale.
Those with a closed mind can head straight to the inevitable flame war located at the end of this article. Those with an open mind who are interested in taking their web development skills and putting them to use building applications in the cross-platform, easy-to-write, easy-to-maintain, scalable, and robust PHP platform, but were hesitant because of the scalability myth, should read on. It starts by looking at the term scalability.
What is Scalability?
There are a number of different aspects of scalability. It always starts with performance, which is what we will cover in this article. But it also covers issues such as code maintainability, fault tolerance, and the availability of programming staff.
These are all reasonable issues, and should be covered whenever you are choosing the development platform for any large project. But in order to convey a convincing argument in this small space, I need to reduce the term scalability to its core concern: performance.
|
Related Reading 
|
Language and Database Performance
Both Java and PHP run in virtual machines, which means that neither perform as well as compiled C or C++. In the great language shootout, Java beat PHP on most of the performance benchmarks, even substantially on some. However, overall the two languages were not an order of magnitude different. In addition, an older version of PHP was used in the test, and substantial performance improvements have been made since and are continuing to be made.
Another area of performance concern is in the connection to the database. This is a misnomer, however, as the majority of the time spent in a database query is on the database server end, processing the query, and the transmit time to marshal the data between the server and the client. PHP's connectivity to the database consists of either a thin layer on top of the C data access functions, or a database abstraction layer called PEAR::DB. There is nothing to suggest that there is any PHP-specific database access performance penalty.
Yet another area of efficiency concern is in the connection between the language and the web server. In the CGI model, the program or interpreter is booted on each request. In the in-process model, the interpreter stays around after each request. One of the original Java-versus-scripting-languages (e.g. PHP) benchmarks pit in-process Java against CGI invocation on the server. In the CGI model, each page incurred the overhead of the startup and shutdown of the interpreter. Even at the time, the comparison was unfair, as production machines used server-scripting extensions (such as PHP), which run in-process and stay loaded between each page fetch. There is no performance penalty for loading the interpreter and compiled pages remain in memory.
With these basic efficiency questions out of the way, it's time to look at the overall architecture of the web application.
Comparing Architectures
There are three basic web architectures in common use today: two-tier, logical three-tier, and physical three-tier. Engineers give them different names and slightly different mechanics, so to be clear about what I mean, I will illustrate the three architectures.
Two-Tier Architecture
A two-tier application web application has one tier for the display and application logic, connected to a second tier, which is the database server. Two-tier web applications perform best because they require the least processing for a single request.
Three-Tier Architecture
A three-tier architecture separates the display and application logic into two separate tiers. To the left, a physical three-tier architecture puts the three tiers onto three separate machines or processes. To the right, a logical three-tier architecture has the application and business logic layer together in one process, but still divided by an API layer.
Three-tier web applications trade some performance hit for better code factoring. With the business logic separated from the user interface, it is possible to access the application logic from multiple directions. For example, we could expose the layer through web services.
J2EE Web Server Architecture
Perhaps the second most contentious part of this article is my definition of a J2EE web server application architecture. Externally to the Java community, the application structure looks clear: JSPs talk to EJBs, which talk to the database. Within the Java community, the standard J2EE topology is anything but clear. A comparison is only valid between two things, so to decide whether "Java scales and PHP doesn't," I need to be clear about what a Java web application server is.
I'll take the two most common interpretations of J2EE architecture. The first is Sun's EJB 1.0 architecture, and the second is the EJB 2.0 architecture. Shown below is Sun's EJB 1.0 architecture for web application servers:
This is classic physical three-tier architecture, and it pays the performance price. I've highlighted the portions of the architecture that involve network traffic, either via database connection, an overhead shared by PHP, or by Remote Method Invocation (RMI), an overhead not shared by PHP.
To be fair, the connection between the web server and the servlet engine can be avoided with modern application servers and web servers, such as Tomcat and Apache 2.0. At the time when the first versions of the JSP and EJB standards were released, the prevalent web server was (and still is) Apache 1.x, which had a process model that was not compatible with Java's threading model. This meant that a small stub was required on the web server side to communicate with the servlet engine. The remains a non-trivial performance overhead for those that decide to pay it, and was a significant performance overhead when the first scalability comparisons were made.
A much more significant source of overhead was in the RMI connection between the servlet engine and the EJB layer. A page showing ten fields from twenty objects would make two hundred RMI calls before it was completed. This overhead was removed with the EJB 2.0 standard, which introduced local interfaces. This topology is shown below:
This is logical three-tier architecture. The web server box has been removed because more recent web servers are not separated from the servlet code (e.g. Tomcat, Apache 2.0, etc.). As you will see when we compare this model to the PHP model, EJB 2.0 moved Java web application server development closer to the successful, and scalable, PHP model.
PHP Web Server Architecture
PHP has always been capable of running the gamut between a two-tier architecture and a logical three-tier architecture. Early versions of PHP could abstract the business and database access logic into a functional second tier. More recent versions can abstract the business logic with objects, and with PHP 5, these objects can use public, protected, and private access control.
A modern PHP architecture, strikingly similar to the EJB 2.0 model, is shown below:
This is logical three-tier architecture, and this is how modern PHP applications are written. As with Java web servers, the PHP code is in-process with the web server, so there is no overhead in the server talking to the PHP code.
The PHP page acts as a broker between second-tier business objects and Smarty templates, which format the page for presentation. As with the JSP "best practice," the Smarty templates are only capable of displaying the data presented, with rudimentary looping and conditional control structures.
But this is all about the design of the server. What about the architecture of the application itself?
Stateful and Stateless Architecture
The lack of an external, stateful object store, where the application can hold session state, is often voiced as a scalability concern. PHP can use the database as the back-end session store. There is little performance difference, because a network access is required in both cases. An argument can be made that the external object store allows for any arbitrary data to be stored conveniently; however, this is easily offset by the fact that the object store itself is a single point of failure. If the object store is replicated across multiple web servers, that becomes an issue of data replication and cache coherency, which is a very complex problem.
Another familiar Java pattern is the use of a local persistent object store on each web server. The user is limited to a single server by use of sticky sessions on the router. The same could be done in PHP: a local, persistent data store. But this is an anti-pattern anyway, because a sticky session-based server pool is prone to overloading of a single web server. Or should the server go down, the result is the denial of service to a group of customers.
The ideal multi-server model is a pod architecture, where the router round-robins each of the machines and there is only a minimal session store in the database. Transient user interface information is stored in hidden variables on the web page. This allows for the user to run multiple web sessions against the server simultaneously, and alleviates the "back button issue" in web user interfaces.
This section has covered some very complex issues in web application server design. Scalability is mainly about the architecture of the application layer, and there is no one true panacea architecture that will work for all application architectures. The key to success is not in any particular technology, but in simplifying your server model and understanding all of the components of the application layer, from the HTML and HTTP on the front end to the SQL in the back end. Both PHP and Java are flexible enough to create scalable applications for those who spend the time to optimize their application architecture.
The Convergence of Web Application Architecture
This article started by asserting that PHP scales. When the tag-line "Java scales and scripting languages don't" was born, it was based on EJB 1.0, an architecture that most Java architects would consider absurd, based on its high overhead. Based on EJB 1.0, Java's performance was much worse than that of scripting languages. It is only the addition of local interfaces in EJB 2.0 that makes the J2EE architecture perform well.
The argument for PHP scalability is further simplified, however, by the fact that both PHP and J2EE architecture (as well as others) are converging on the same design. And if "J2EE scales" given this simpler, logical three-tier architecture, then it follows that PHP does as well.
The performance principle for scalability is simple: if you want to scale, then you have to serve web pages quickly. To serve web pages quickly, you either have to do less, or do what you do faster. Faster is a non-starter, because Java is not so much faster than PHP that it makes much of a difference. Doing less is the key. By using a logical three-tier architecture and by reducing the number of queries and commands sent to the database, we can get web applications that scale, both in Java and in PHP.
For the open-minded developer, there is a world of applications that can be built quickly, cheaply, robustly, and scalably with PHP. Services such as Amazon, Yahoo, Google, and Slashdot have known about scripting languages for years and used them effectively in production. Yahoo even adopted PHP as its language of choice for development. Don't believe the hype in the white papers that says that PHP isn't for real applications or doesn't scale.
I'm sure that what I have said in this article will be picked to death and ridiculed by some. I stand by what I have said. The idea that PHP does not scale is clearly false at the performance level. In fact, we should have never even gotten to the point where this article was necessary, because as engineers, we should recognize that the argument that one language clearly "scales better" than another is, on its face, ridiculous. As engineers and architects, we need to look objectively at technologies and use a factual and rational basis to make technology decisions.
Still not convinced? Consider JSR 223, the effort to turn PHP into the front end for J2EE by porting it to Java. If PHP on top of Java is scalable, then why isn't PHP on top of C?
Author's Note: These views are my own and have nothing to do with those of Macromedia.
Jack Herrington is an engineer, author and presenter who lives and works in the Bay Area. His mission is to expose his fellow engineers to new technologies. That covers a broad spectrum, from demonstrating programs that write other programs in the book Code Generation in Action. Providing techniques for building customer centered web sites in PHP Hacks. All the way writing a how-to on audio blogging called Podcasting Hacks.
Return to ONJava.com.
You've heard the argument for PHP scalability, now let's hear what you have to say.
You must be logged in to the O'Reilly Network to post a talkback.
You must be logged in to the O'Reilly Network to post a talkback.
Showing messages 1 through 201 of 201.
-
Still Q? remains if we have both JSP+other SUN features AND PHP which one to use
2007-11-06 02:06:29 AMOL_G [Reply | View]
After reading all the views i got more confused that once when we have good JAVA+ JSP and want professional web-site to provide most features then why use PHP.
OR
if PHP vs JSP situtation comes for a slighlty big project which one to go for.
-
Java V. PHP Conundrum
2007-06-12 15:20:02 MrTentacles [Reply | View]
I have developed in Java and in PHP and I can tell you that in regards to pure development time, PHP wins every time. Java is too big. By the time you factor in all the imports and jar file calls, your code bloats so big that accomplishing the same task in PHP yields smaller (faster) code. PHP is also easier to work with. It's not that I dislike Java. It's that Java is not the end-all tool for web development---no tool is. You use the tool that fits right for the task at hand. For my purposes, small and lean apps, I prefer PHP, an easy to use scripting language that is flexible, well supported and well documented.
-
Gaming industry, php, dynamo server
2006-01-08 10:21:52 photo312 [Reply | View]
I used to code in Java for the Dynamo Server platform. Just to set it up was a pain and we spent days and days just to set it up.
PhP is a cheaper solution and is my preference. I have looked at Zope engine and it is something to look into again.
Or typo3.com engine.
But - all this drama about performance. If I want better performance - I just spend another $200 and get DDR2 memory and SATA hard drive. Hey - its quicker now.
The gaming industry is pushing for faster CPUs, Faster Hard drives and Memory so when it comes to performance - just get a new AMD Athlon XP, DDR2, SATA hard drive and you are good to go!!!
-
People Are Doing The Wrong Comparsion Here!
2005-11-06 01:02:14 dealmaker [Reply | View]
Shouldn't people compare PHP with JSP instead of Java?
Java can be fast if implemented correctly, look at Nutch and Lucene. They are used in high traffic environment, and the performance is very good. Can you imagine writing Nutch and Lucene with PHP?!! Is it even usable even if possible?
PHP is more like the Display/Presentation Layer, and the Java is the Business Logic Layer. I think they both can coexist using php-java-bridge.
So let's be friends. :) -
People Are Doing The Wrong Comparsion Here!
2008-04-12 19:50:16 wiangube [Reply | View]
I'm only going to recall a completely true sentence by Bill Snyder:
"Java is becoming the new Cobol"
Java, the oldest new programming language around, is falling out of favor with developers. When it comes to developing
the increasingly common rich Internet applications, Java is losing ground to Ruby on Rails, PHP, AJAX and other cool new
languages. And there are even reports that Microsoft’s .Net, of all things, is pushing Java out of the enterprise. Makes you wonder
whether Sun was smart to change its stock-ticker code to JAVA last summer
-
PHP scalability....
2004-12-06 01:27:25 Ruturaj [Reply | View]
After all that long stuff , guess what this site is running on Apache/1.3.33 (Unix) PHP/4.3.9 mod_perl/1.29
ha haa haaaa, The big Java Brother does not seem to be reaching public as well as his younger brother PH P is...
-
Scalability is a buzzword
2004-11-20 07:54:02 oldfart [Reply | View]
and a compromise at best. There is a different design in the run-time environment in each language (Java/PHP).
Java has sought to achieve faster response in the face of large numbers of users by, keeping byte code resident in RAM for as long as possible, avoiding reloading programs with each request. The cost of this choice is that in large complex systems, multiple dedicated servers must be used or as it runs out of memory, it looses its advantage. Scalability means buying more servers, and designing applications with dedicated servers in mind, one for one purpose, and another server for another purpose.
ISP's like PHP because it is not a part of the strategy to dedicate servers to a specific purpose or part of an application and one server can support multiple users with entirely different applications on the same machine, up to a point of course.
I know of more than one large site that has had to go out and buy more servers after implementing Java as a solution, primarily because of this tradeoff. Scalability is a buzzword which seeks to place a spin on this impact and disquise the additional cost.
Depending on the hardware involved, I have seen PHP sites supporting 400-500 concurent users with a wide variety of applications, same hardware supporting supporting 5000 concurrent users but only one dedicated app with Java. If you like Java, be sure to bring your pocket book.
Scalability comes at a price (what did you expect?).
-
i likey php
2004-01-05 09:14:08 anonymous2 [Reply | View]
i love php, java is just too overwhelming with all it's features and strict syntax. php does EVERYTHING i need server-side fast and effeciently and that's all i need it for, i'm even making socket servers and such with php. php5 is gonna rock!
-
Scalability != performance
2003-12-07 05:52:24 anonymous2 [Reply | View]
I'm not sure if you have the correct understanding of what scalability is.
The main concern of scalability is IMO:
If I have a server that can serve 1000 request per second, will it serve 2000/sec if I double the resources (CPU, memory, DB servers)?
But you are talking most of the time about the performance of PHP vs. Java -
Scalability != performance
2003-12-13 15:18:04 anonymous2 [Reply | View]
I agree. Scalability is about what happens when you had more machines / web servers /applications servers / databases ... . Doesnt matter what you write it in, if you dont think about whats going to happen when you cluster your app, it aint going to scale.
-
Plumber's Toolkit
2003-12-07 02:42:50 anonymous2 [Reply | View]
It was funny to see the little argument that came from the article. It is like listening to Democrats and Republicans -- there's only one party that is any good, and the other one is evil. In my opinion, programming any application is like plumbing. If a plumber came to your house and he only had one wrench, you would and should send him away. What if your pipes are bigger? What if he needs to cut into a wall to reach your pipes? What if your pipes are made of PVC or ABS? A good plumber has a whole toolkit, and uses tools based on what is needed for the job, not based on how great "this" wrench is and how awful all the other wrenches are.
As such, if you are doing those large, complex sites that PHP could never do before, you should at least LOOK at it again before you count it out. It might meet your needs. It might not. Same for JSP. Check it out and see if it meets your needs. It might. Or it might not. Don't marry the tool. Choose the tool that fits your specific needs at the time. A hammer really does not fix everything.
-
Plumber's Toolkit
2005-01-27 19:59:33 gsasikumar [Reply | View]
I too agree with this statement but still languages are not physical tools as that exist in the real world and can be changed without any problem. Once you choose a language then you need to be in there for as long as u can make money and vice versa. That's how bussiness runs. Imagine a company which changes its application from java to PHP or vice versa. Will any company dare to do it. No the wont until it has been pushed on them. But a plumber can use a tool today and finish his job later get a new tool to do his job. But that would never ever hold good in the software industry. Its a sticky bussiness and the users need to sticy too.
-
Java and PHP
2003-11-25 09:33:36 anonymous2 [Reply | View]
I have programmed in both langauages for some time and have my opinions about both. While PHP is great for some things I feel it is completely not for others. One reason behind this is because PHP is basically a procedure based programming language and thus is harder to manage in larger projects with multiple people working on them. And mixing biz logic in the view can lead to all sorts of problems down the road. I know that PHP has objects you can use but have you ever actually tried to create a MVC based application with php objects? Can get pretty messy. On the other hand java is horrible for smaller projects because of the amount of planning and coding it takes to do smaller things. While easier to maintain and in my opinion much cleaner it is very easy to create enterprise applications seperating the biz logic from the presentation. But as I said I think both languages are great in their own grown. But they are totally different beast. Just my two cents. -
Java and PHP
2003-12-14 23:28:15 anonymous2 [Reply | View]
It's all about design. You can design your PHP app using MVC, just the same as you can do the same in Java. You can separate Business Logic from Presentation Logic, it's just about your design.
Similarly, you can write small JSP apps just as quickly as you write small PHP apps. Just depends on your design.
And can anybody give me firm examples as to why "mixing biz logic in the view can lead to all sorts of problems down the road."? We all "know" it's bad design, but why exactly?
I think we tend to over complicate our designs to suit our academic twists. Do the job using the simplest methods possible, while still maintaining good design and coding practices. We have customers to serve who want software that works today, is cheap and can be changed in the future, not something that doesn't work today, costs the sun and offers no real advantage in terms of future changes.
Bit off topic, but it's all about design: we shouldn't need a language to force a design on us. That shows lack of craft. -
Java and PHP
2005-08-19 12:19:47 cyberlife [Reply | View]
And can anybody give me firm examples as to why "mixing biz logic in the view can lead to all sorts of problems down the road."? We all "know" it's bad design, but why exactly?
It really all comes down to isolating changes. If something needs to be modified, how much of your program will you have to alter? I can give you a real-world example that I ran into with a colleague.
He had created a 50+ page application driven by a relational database on the back-end. The code for interacting with the database and processing query results was directly mixed in with the presentation logic. One day, he was asked to change the application's storage system from a relational database to Berkeley DB. He ended up having to nearly rewrite the entire system since his database code (and other related elements) was scattered around everywhere instead of being confined to one or two source-code files.
This scenario is common to many applications, both large and small. Small snippets of business code are used repeatedly in several places by presentation code. Any dependencies on how that business code actually does its job are going to spell trouble should you need to change things.
It's like going to McDonalds. Do you care about the details of how they actually prepare their burgers? Generally not -- you just care about the result. By not being dependent on their internal processes, they are free to change their ways without upsetting you. Same thing applies to programming ..... or any engineering for that matter. -
Java and PHP
2007-07-25 14:57:20 Storm14k [Reply | View]
I know this is older but I still see this argument with regards to php and I do not believe it has merit.
Even prior to the advances made in php's OOP capabilities the file include flexibility of the language would allow you to achieve enough seperation to avoid this type of situation. The code and necessary html to represent a particular item could be written in one file and included where needed. Control variables could be used to handle differences between individual instances. And if the database connection was a problem DB::PEAR could have been used. To me it seems like most of the code/presentation/maintainability arguments against php stem from lack of a full understanding of the language and its capabilities.
On another note I have yet to see what I would actually consider true separation of code and presentation as it is hyped by other languages when compared to php (mainly asp.net). If you are putting anything in your html besides html then you are mixing code and presentation. It doesn't matter if its a php while loop, smarty template tag or an asp.net or jsp tag. They all do the same thing...loop over a piece of html and inject data values in place of place holders.
-
I can't believe this
2003-11-05 12:56:35 anonymous2 [Reply | View]
This whole mess indicates to me why I didn't get a CS degree and rather got an engineering degree. You use tools to solve problems. Almost all tools have their uses.
The fact that this degenerated into this "Java people" vs. "PHP people" is terrible. I hate reading such forums as this because I have to wade through this crap when for some reason I keep expecting an interesting discussion relevant technologies that I can use to solve problems and make money. Say something worthwhile or don't say it at all. -
I can't believe this
2003-11-05 13:01:56 anonymous2 [Reply | View]
in fact in this entire thread we can see the old arguments:
C is better than Java
Java people are idiots who get off on how cool Java is
PHP is better than Java
Java is too complex to use
I've been in IT for 20 years and I know.....
etc....
at least .NET didn't come up
how many years will this go on?
why do people say these things - it just reduces the value of any such forum -
I can't believe this
2003-11-17 16:38:13 anonymous2 [Reply | View]
you are all rookies. you are all aguing about CPU cycles (someone mentioned C). CPU cycles is not the goal in scalability. is an opitimised assembler app serving a fictitious figure of 1000 pages at once scalable? no, because how do you then serve 2000?
assume slow technology A cans server 100 pages at once. assume faster technology B servers 200 pages at once. A is given more overhead so that it can serve 50 pages simulaneously on seperate servers. A is run on 10 servers, thus serving 50 * 10 = 500 pages at once. A is more scalable than B.
-
PHP and Java
2003-10-30 04:26:16 anonymous2 [Reply | View]
I'm a programmer in both languages.
PHP is the perfect tool for hobbiest and fast developement of a small website from scrap.
JSP is the perfect tool for larger websites that need a lot of interactions with others technologies / parts.
It is also a perfect tool to reuse componants!
Personnaly I love JSP... But PHP is not bad.
Gab
-
PHP vs. Java
2003-10-27 09:58:32 anonymous2 [Reply | View]
I've always been a big fan of Java. I like the get up and go in the morning, and sometimes after a big dinner too.
I seem to remember trying PHP once a few years ago. But the hallucenations were way to extreme, even more so than from that double-expresso I got at Starbucks last Tuesday.
I never heard of XOOP---is that like X? But just from the sound of it, Zope sounds like it might be worth a try. Can anyone tell me how long it lasts?
-
Anyone who doesn't have an opinion, please stand up.
2003-10-24 04:32:02 anonymous2 [Reply | View]
First, I am sure that this message will have it's share of haters, but what the heck.
Second, I am no expert in either technology, and I claim this openly. So, those who only care what self-proclaimed experts say, please disregard the rest of this post.
Finally, the point of this post is in support of the article. I think (which is to say that you can think whatever you want, I am not going to ASSume that only my opinion matters), that the point of the writing is to say that PHP is a very valid technology, and an alternative to other web application development technologies. So, if you don't like Java, try PHP. If you don't like PHP, well, then don't use it.
Some of you spend entirely too much time bashing technologies you don't like. It almost seems that you want to be in some sort of club that is better than all of the other clubs. If that's the case, my club is founded on the philosophy, that if it works for you, great use it, otherwise don't. And if you want to think that you are better than me because of the technology you use, than fine, you are better than me. But enough of this, I am actually going to get some work done. Reply as you will, I won't read it anyway.
-
blah blah blah.
2003-10-23 10:19:53 anonymous2 [Reply | View]
I'm a hobbyist. not a programmer. but I've tried learing to program in python, java, ruby and now php. As a learning hobbyist I find php to be just fine. I think java is a good language too but it wasn't so much hard to learn as hard to get to work properly. I had Tomcat on my machine and well... it sucked royally. so I downgraded to php which I can say is a lot more fun, a lot less gray hair. Java's problem for people like me is it's bloat. so many bloody java this and that and this depends on this and that configuration that I just got fed up with it. If you like using it go ahead but us php lovers will go on using php. I wish I had started to learn about php a couple years ago when I was just getting into programming. I'd probably be light years ahead of where I am now. I don't care about the little things. I just want something I try to work. Tomcat just threw java out the window with all it's problems. so many tutorials that just couldn't be finished. "you should get this..." and I didn't. no explanation of why. At least PHP gives better feedback during errors. -
blah blah blah.
2003-11-09 16:11:49 anonymous2 [Reply | View]
well, you're an hobbyist, as you said. An I'm sure php is the best thing for you.
But I think if you were in the need to write N-tier stuff, to integrate legacy systems and so on.. I dont think you should go with php.
But, sure, you can.
Most people gets java ad hard. It may be harder than PHP in the first time, it is not in the long run. When someone first see EJB's xml think 'oh no! I have to write xml!" and doesn't get that xml is saving him the need to write sql and a whole persistence layer :)
-
Perl is so much better than PHP or Java
2003-10-21 12:54:13 chicks [Reply | View]
Arguing about the performance or maintainability of PHP versus Java is just an argument about the "also rans". As someone who has developed applications in all three languages that people were quite satisfied with I can't imagine why people still spend their time beating their heads against the limitations of java and php. There's this really pleasant world over here known as Perl where people share buckets of code and oh, it runs circles around the also rans. But arguing about performance in the golden days of Moore's Law is laughable - what about whether it's fun!? Hmm? -
Perl is so much better than PHP or Java
2003-11-03 05:03:12 anonymous2 [Reply | View]
well BLESS my little objects! -
Perl?
2003-10-29 11:54:27 anonymous2 [Reply | View]
Funny you should mention perl in a post where you name performance a virtue.
For the mission-/performance-critical applications, there's no excuse not to write them in C anyways (no, being lazy doesn't count).
On a sidenote, any aspiring programmer should learn the mother of all programminglanguages. For tearing down language barriers it is unsurpassed, and for speed, performance and possibilities it meets its match only in the troublesome assembler code.
Oh, and incidentally, there's quite a few buckets of free C-code around as well, including a dozen or so operating systems (which I don't think will be rewritten in perl any time soon).
Cheers
/Andreas -
The mother of all languages?
2006-08-09 22:51:45 arglborps [Reply | View]
So that could mean several:
Write binary the real mother of all...
Or write in Plankalkül which is more or less the first programming language (well it wasn't for a completely electronic device, though)
Or Short Code, the first computer language actually used on an electronic computing device.
Ah, you mean C, that Hippie language from the seventies? C’mon I am even older than that (by one year), and I don't have grey hair (no I'm not dyeing it).
I don't get it how you come to think of C as the mother of all programming languages...
-
The PHP Scalability IS NOT A Myth
2003-10-19 05:57:56 anonymous2 [Reply | View]
The PHP scalability IS NOT A myth because PHP can scale close to Java. However, the caveat is that Zend the company that makes PHP makes you buy a PHP accelerator for it to scale well. Most PHP is installed without the pricey PHP accelerator so of course everyone thinks PHP cannot cut it in the big leagues. -
The PHP Scalability IS NOT A Myth
2003-10-22 09:02:57 anonymous2 [Reply | View]
Free accelerator exists such as APC, Turck Soft mmcache and they are quite easy to compile and get going -
The PHP Scalability IS NOT A Myth
2003-10-22 05:16:31 anonymous2 [Reply | View]
There are several free (as in beer and source) PHP accelerators out there as well. -
The PHP Scalability IS NOT A Myth
2003-10-20 05:54:59 anonymous2 [Reply | View]
I used to run AdCritic.com on a single server installation (dual 800mhz proc, 1gb ram) running both Apache + Mod_PHP and MySQL. I was doing close to 1 million page views per day, with the capacity to handle 1.5-2 million. I could have added an additional server to increase my capacity to 3 million pages. I could have moved to 3 machines, 2 front ends and a mysql DB on the back end to get up to 4-5 million page views.
Every page view was running sessions, and over 50% of the page views were to logged-in users. Every page was generated from the DB. Sessions were stored in the DB.
I didn't use the PHP accelerator -- I wrote well-crafted SQL statements, optimized my DB, used persistent connections to the DB, optimized code and continued review of all code.
You don't need the PHP accelerator to make PHP scalable.
BTW, this was between 2000 and 2001 using PHP3 and the early versions of PHP4. I'm sure that using PHP5 the site would be able to handle more page views with the same hardware.
-
Is scalability related to pay rates?
2003-10-19 03:38:07 anonymous2 [Reply | View]
Some of the replies here that claim PHP can scale as well as J2EE seem to be a bit peeved about not getting paid as much as J2EE consultants.
Do employers think that J2EE is a more complicated technology that deserves better pay rates?
Or is it just a matter of supply and demand - ie too many PHP developers that can do a decent job on simple websites, and not many J2EE people who are needed for projects claim to require (legitimately or not) scalability and reliability? -
Is scalability related to pay rates?
2003-10-19 05:43:05 anonymous2 [Reply | View]
Although both probably play a factor, think it's mostly to do with Java's having the biggest IT heavyweights pushing it. When was the last time you saw PHP getting serious marketting? Plus PHP has the whole Open Source stigma attached.
-
Scalability in the possible real world
2003-10-17 21:18:53 anonymous2 [Reply | View]
Here's a web application for you.
The government of country A is cash strapped and needs a learning content management system and testing system for it's public schools, military, hospitals and universities. The government wants to allow all citizens to be able to check out learning materials (SCO's=shareable content objects) that can have test/progress results stored in a database that gov. ministers can see the "progress" of learning in the kingdom. New knowledge material can be updated dynamically across several sites. As soon as something new is viable enough for creating a class or learning session over the web, a learning object is created.
Several institutions must have a local server available for their use since the internet is not so reliable in country A. The system must have some safegaurds against cheating and fraud.
What is the best way to store a student's progress in the system across courses, years, sites and institutions?
Country A has several college students who can program but cannot afford expensive programmers, or Microsoft products, and cannot spend money buying solutions. Country A's people want the pride of having their own learning system that is standards complaint with various international learning standards and groups (RDF,AICC/SCORM/ADL). Moreover, they want their school's curricula and libraries accessible over the web by handicapped persons (section 508).
They want an opensource solution. Maybe a database such as Firebird, post-gre, mysql or even Oracle/MS Sql since each institution has their own database system. They want the datatypes to be stable across the application. They want an installer package that can set up a webserver/database server that can then download current courses/records to a central distributed repository on demand (DB to DB transfers, XML transfers, etc.)
What would you go with?
Would you use Java, Jython, PHP, Python, Perl, Pike or a more developed Content system like Plone/Zope that may require programming for the AICC/SCORM code base, etc.
I think with LAMP. PHP might win.
Tom Ellis
-
Scalability in the possible real world
2003-11-09 16:25:12 anonymous2 [Reply | View]
I think FRAP as in FreeBSD, Ruby, Apache,PostgreSQL.
Ruby has binding with pg and even a plruby module. XML (and xml-rpc and SOAP) are available with the basic distro. Apache+eruby+mod_ruby or FastCGI give you scalability and ease of development. And Being Full OO helps a lot.
BTW this looks somewy similar to what Dave Thomas did:
http://www.zenspider.com/dl/rubyconf2002/SummerVacation.tgz
In these slide he explains how he wrote a first class app in ruby and why he did not choose java. And for sure he's not a java hater :) -
Scalability in the possible real world
2003-10-21 12:13:18 anonymous2 [Reply | View]
this sounds a lot like the PFP LMS, a project I am curretnly working on. For me the choice is different in this situation. I think that there are plenty of open source solutions (PLONE, and in PHP XOOP or PHP Nuke) that can lift the abstaction and elminate reinventing a lot of features. They are extensible and could provide a good starting point for a project of the type you have described.
Ivan Labra
-
Zope
2003-10-17 19:24:34 anonymous2 [Reply | View]
Zope gets surprisingly little mention in these sorts of discussions. Zope has...
* a persistant enterprise level object database, that handles a distributed backend completely transparently (so you dont have to use nasty hacks like hidden variables to store state data. The session data can store key-value pairs of any python object, and is duplicated across multiple servers using ZEO)
* Zope Page Templates
Possibly the best templating language in existance, ZPT fullfills everything you need for your presentation layer.
* Python Scripting
Zope supports python scripts and python products. Scripts are stored inside the ZODB and are generally used to help process data for page templates.
Python Products are where the meat of the processing happens. This is where you define your classes. Each class can be instantiated multiple time into the ZODB (i.e. /sites/clienta AND /sites/clientb). So you can have the same codebase running two sites without setting up a seperate server.
* CMF and Plone
Two out-of-the-box products available for Zope, CMF and Plone are probably the most powerfull content management systems known to man. You can extend these to your hearts content- I've created systems for under $1000 that were estimated at $50,000 by a J2EE development firm. I've consistantly been able to duplicate a weeks worth of J2EE in about a day of Zope.
I havn't even began to touch the full power of zope. It's really such an extreme difference in philosophy to J2EE or PHP design models that you need to experience it for yourself.
-
Dude's right!
2003-10-17 19:19:37 anonymous2 [Reply | View]
Java bites. I write both Java and PHP. PHP is a LOT more fun. Hardware is cheap compared to developer time. Java doesn't make a lot of sense on the server anyway. Why do you care if your server side code is portable. It won't be anyway, more than likely, even if you write it in Java with all of the configuration involved. How often are you going to move your code from server to server?
Maitainability is DIRECTLY related to how much code you have to write to print "Hello World". If the chosen languge requires ten lines (like Java) to accomplish this, it's going to be a pain to maintain.
The things that matter are how long it takes for your visitor to receive the information they requested from your site and how long it takes you as a developer to deliver the functionality that your boss or client wants. -
Dude's right!
2004-11-09 12:15:15 igouy [Reply | View]
"The Great Computer Language Shootout" has been revived at<br/><br/>
http://shootout.alioth.debian.org -
Dude's right!
2003-11-19 18:43:56 anonymous2 [Reply | View]
This thread reminds me of Daffy, Buggs, and Elmer:
It's duck season!
It's rabbit season!
Duck season!
Rabbit season!
* Blam! *
While readjusting your beak, take a look at the link in the article to the Computer Language Shootout, specifically http://www.bagley.org/~doug/shootout/craps.shtml
Adjust your weightings to what is important to you then see where your language falls in the rankings.
-
Dude's right!
2004-01-08 03:25:03 anonymous2 [Reply | View]
I tried to run some scripts I found on that site. For example, ary3 script. The site says it takes about one second by Java and more than 50 seconds by PHP. On my Linux PC it takes about one second by Java and only 5 seconds by PHP. Of course my CPU is faster than the one used for the shootout tests but ask to yourself: which language scales better when I increase hardware resources?
Sergio -
Dude's right!
2003-10-17 19:58:30 anonymous2 [Reply | View]
System.out.println("Hello World");
Oh yea, 10 lines.. Maybe you need to learn to count.
MOM -
Dude's right! and you're wrong
2003-12-10 02:51:46 anonymous2 [Reply | View]
echo "Hello World"
I don't know Java and don't profess to. Plus I'm a hobbyist who's still learning (always learning!) but even I can see that PHP is going to be easier to script... -
Dude's right!
2003-10-18 01:23:46 anonymous2 [Reply | View]
Not to be disrespectful, but I do think you left out a few things.
For just a terminal
class HelloWorldApp {
public static void main(String[] args) {
System.out.println("Hello World!"); //Display the string.
}
}
For an Applet
import java.applet.Applet;
import java.awt.Graphics;
public class HelloWorld extends Applet {
public void paint(Graphics g) {
g.drawString("Hello world!", 50, 25);
}
}
For a Java Bean
package org.acme;
import java.rmi.RemoteException;
import javax.ejb.*;
public class HelloBean implements SessionBean {
private SessionContext sessionContext;
public void ejbCreate() {
}
public void ejbRemove() {
}
public void ejbActivate() {
}
public void ejbPassivate() {
}
public void setSessionContext(SessionContext sessionContext) {
this.sessionContext = sessionContext;
}
public String sayHello() throws java.rmi.RemoteException {
return "Hello World!!!!!";
}
}
-
Dude's right!
2003-10-19 00:32:44 anonymous2 [Reply | View]
but then a JSP?
<% out.println("Hello world"); %>
pretty much the same as php isnt it... -
Dude's right!
2003-10-20 15:01:28 anonymous2 [Reply | View]
Look into webserver generated files, what it makes with your 1 line - 1,2,3 or more classes??? -
Dude's right!
2003-10-21 07:22:48 anonymous2 [Reply | View]
It doesn't matter what it generates server side. Because you don't have to write that or maintain it.
JSP and PHP are very similar. Personally, I think that whenever your language has <% } %> in it you're doing something wrong. That's why I don't do PHP, and why I don't do Model 1 JSP.
ZPT *is* the best page templating language around. I just wish it was available for Java. Zope sucks.
-
Key Problem With This Article
2003-10-17 17:21:14 anonymous2 [Reply | View]
The key problem with this article is that now this information is getting out there. Java developers DO NOT want to see there billing rates drop which is what happens when big businesses learn that there is a language out there that is a perfect for developing a majority of there web based applications at a lower cost to them and a quicker time to market. I am a PHP coder at heart...have been for a long time. I work for a very large financial firm that is strictly a java shop. I look at the applications that are being built and truly believe that they could be done in 1/2 the time using PHP. If you java guys are really worried that PHP will be as hard to learn as Java don't worry. It's much easier. Pick up a php book and take a look! You'll be surprised at how much more you can do with much less code!
-
maintainability is king
2003-10-17 16:45:36 anonymous2 [Reply | View]
"I need to reduce the term scalability to its core concern: performance"
With that statement, the article went from interesting to uninteresting.
Performance is not really that important. There will always be faster machines with more RAM. You can load balance across machines, that is not really a language issue, although some support it better than others.
Maintainability is the key to any large software development project. If you have 100,000 lines or code in a mid-sized project, you definately want a language that provides the best concepts and tools to manage that complexity.
I am not a PHP user. I believe that PHP is behind Java in maintainability, but I don't know PHP well enough to compare them point by point, and I may consider using PHP on a future project so I want to know how far it is behind. How does PHP compare to java's packages, jar files, war files, import statement, class visibility, interfaces, reflection, javadocs, UML tools, etc. Now that would be a more useful article.
-
maintainability is king
2003-10-18 03:01:40 anonymous2 [Reply | View]
There's a philosophical and a practical answer to that.
On the practical front, PHP doesn't have such a mature set of development tools and there's still a fair amount of work to do on encapsulating common architectural issues in some form of re-usable package - PEAR is getting there although there's still some lessons to learn in re-use (PEAR is closer to CPAN right now than a well integrated class library). PHP5 is also needed to make things like error handling more uniform.
On the philosophical front, there's a different school of thought coming from an eXtreme programming angle which argues that static, compile time type checks are merely a subset of unit testing and don't bring you much closer to a bug free application. Bruce Eckel makes the case in Strong Typing vs Strong Testing. For a PHP unit test framework (there's a few), try Simple Test. -
maintainability is king
2003-10-17 19:16:37 anonymous2 [Reply | View]
I'll save you some time. PHP really sucks for projects more than a few pages. I'll briefly explain. It is about as far from concepts like type-safe as it could be made. Cute syntactic tricks are much more important (at least on the day you code your first program). Why do the PHP language developers bother saying that they added a function to the language if they aren't going to unambiguously document the damn thing?? Because the PHP team is entrenched with a screw-safety mindset and mean-spirited arrogance. If they weren't coding PHP they'd be creating viruses and stealing credit cards so I suppose we should be thankful. Zend was hatched from the same cesspool -- bug-laden crapware and rampant dishonesty from all angles.
This is the truth and readers, you have been warned. -
maintainability is king, author is queen
2003-10-20 08:31:13 anonymous2 [Reply | View]
seems to me like you have some personal axe to grind here...
Yahoo!, SourceForge.net, Lufthansa.com, Deutche Bank - they all run PHP and I dare say all these are "projects more than a few pages".
-
maintainability is king, author is queen
2003-10-20 15:51:29 anonymous2 [Reply | View]
"author is queen"
cute :)
"seems to me like you have some personal axe to grind here..."
Correct. It became personal for the reasons I've given.
"Yahoo!, SourceForge.net, Lufthansa.com, Deutche Bank - they all run PHP"
It can be done with a good debugger but much better alternatives exist, which is the point of this discussion.
For the record, such as it is, I'm brainbench master certified in PHP. -
maintainability is king, author is queen
2003-10-25 15:35:27 anonymous2 [Reply | View]
This has GOT to be a troll. :-)
That last sentence gave it away. -
maintainability is king, author is queen
2003-10-23 09:59:42 anonymous2 [Reply | View]
People who have to tell eveveryone what they're certified in tend to be completely incompetent in my experience. Certified means you studied for a test. It doesn't mean you *know* a damn thing--which your other arguments seem to support. Write some code first (more than a few pages) before you start to shoot your mouth off. Making a vast over generalization like this just makes you sound stupid. Then again, maybe you *are* stupid. -
maintainability is king
2003-10-18 02:28:32 anonymous2 [Reply | View]
Why do the PHP language developers bother saying that they added a function to the language if they aren't going to unambiguously document the damn thing??
So they can tell you to debugger_off() and die() -
maintainability is king
2003-10-17 23:10:23 anonymous2 [Reply | View]
"Zend was hatched from the same cesspool -- bug-laden crapware and rampant dishonesty from all angles."
Gee, that sounds a lot like Microsoft. You're running Windows, I bet. -
maintainability is king
2003-10-18 05:45:29 anonymous2 [Reply | View]
I'm running alot of things, including PHP. I invested literally years of my life in a PHP system and as a result I am now married to it.
One of the worst decisions I have ever made.
PHP is a gift horse I advise everyone to look carefully in the mouth before placing their bets, elsewhere. -
maintainability is king
2003-10-21 02:32:43 anonymous2 [Reply | View]
I'm replying to my post to clarify: I will re-write my PHP apps in other languages when I can now that multi-billion $ competitors have passed me by, but I'm now married to PHP in another way, as PHP is the freshest item on my resume. I've found that skill in this language is shockingly unsaleable compared with things like Java. Check out the help wanteds if you don't believe me. Employers have told me that they look for skills in a more substantive language, like C or Perl, even if the position will be mostly PHP programming because the last is a considerably simpler, derivative language.
If you've been pretty focused on PHP development for a while, your other skills may now be at least a version behind. If you develop a distinct lack of enthusiasm for the language on top of this don't be surprised that this reveals itself at interview. You may then find manning the proverbial hot dog stand looming rather large in your future. The fresh air may do you good but the point remains: think of the children before choosing PHP. :) Somehow that's not as funny on second reading.
Yes, I program alot better in other languages (particularly with a good IDE and clear documentation) but either I'm from Mars or this would be the general experience for the reasons already stated. -
maintainability is king
2003-10-24 08:15:04 anonymous2 [Reply | View]
PHP is not highly complex, and it is highly specialized. PHP was meant to be a web programming language. Perl was meant to be a text manipulation language and a general workhorse. Java was built to be a multi-platform development language. PHP as a web dev language is fantastic -- lots of web-related functionality built-in. Perl has that functionality as Perl Modules, adding on complexities which are not compiled into the language. Java has the same thing -- lots of modules and such that need to be added in to make coding for the web easier and less complex.
True, PHP can't do the millions of tricks that perl and java can do outside of the web world. But PHP can do most everything that a web developer needs to do, and it does it natively. It wouldn't make sense to implement a web server in PHP (although I suppose it might be possible), but it might in Perl or Java. It might be difficult to write an AIM client in PHP, but not so difficult in Perl or Java; but then again, Perl and Java are generalists whereas PHP is very specifically for web development.
If you are doing pure web development, using a language written specifically with that task in mind makes sense. If you are doing some major huge task that encompasses lots of non-web-related work, it would make more sense to use a more general language.
I also agree that PHP gives you a limitation in job opportunities. While PHP is a good language for web development, if that's all you know, you can't understand the general aspects of perl or java, and potentially not know things about typecasting or the problems with declaring everything global. I did perl for 5 years, then PHP for the last 4, and while I don't think my programming skills have suffered, I can't say that they have improved significantly since I've been out of the perl pool.
I program for the web best in PHP because PHP was built for that task; I do other non-web things in perl. -
maintainability is king
2003-12-09 11:31:12 anonymous2 [Reply | View]
If you are doing pure web development, using a language written specifically with that task in mind makes sense. If <small>yo</small>u are doing some major huge task that encompasses lots of non-web-related work, it would make more sense to use a more general language. -
maintainability is king
2003-10-20 01:06:32 anonymous2 [Reply | View]
Any language is "one of the worst decisions" you've ever made if you don't take time to properly learn how to use it. In most cases, those who are fanatically opposed to certain languages have had a bad experience with it primary because they were inadaquate programmers and not because the language was lacking. I can name hundreds of "great, experienced programers" who think C is a woefully inadaquate language to develop software in. Would you say they're right or is it more likely that the problem lies in their skills?
A bad programmer is a bad programmer. A bad programmer will produce crappy code in any language. The usual out for these programmers is never their inadaquate skills but rather "the language is crappy".
I've developed software -- high end software -- for both private industry and government in Java, PHP, and C. I've developed software in PHP using thousands of pages and I can tell you it CAN scale and it CAN handle complex applications. The problem isn't with the language. I can guarantee you that.
Anthony -
maintainability is king
2003-11-03 11:28:59 anonymous2 [Reply | View]
Right on....
I've been in the industry for 30 years (12 as a Consultant) and have been developing Web pages in Java/JSP, ASP, and PHP.
My favorite, PHP hands down. Powerful and maintainable.
Just by the nature the organization of JAVA, it forces you to be organized. If you take that mentality when coding in PHP, you'll write structured and highly maintainable code. The choise is up to you.
That is, if you're a talented enough of a programmer to recognize that you have that choice.
Roy -
maintainability is king
2004-11-18 16:18:47 Tablizer [Reply | View]
Re: "Just by the nature the organization of JAVA, it forces you to be organized."
Can you give an example? Messes can be made in Java just like anything. It appears to me that it often requires you to duplicate certain coding patterns to make stuff work, but a lot of it is also mindless beurocratic repetition for the sake of formality.
-
maintainability is king
2003-10-19 10:38:39 anonymous2 [Reply | View]
My experience has shown that those who dismiss a certain technology for "big" projects don't know the technology as well as they say they do.
So, I'm calling your bluff. I bet you suck at PHP. :-) -
maintainability is king
2003-10-23 10:05:38 anonymous2 [Reply | View]
I would bet he sucks at software design in general. No solution is viable regardless of language if you build it in such a way as to have no ability to maintain it easily. This guys is wasting all of our time. Read a design book, dude, and stop your whining.
-
Anyone ever hear of MVC?
2003-10-17 12:20:47 anonymous2 [Reply | View]
Insofar as PHP vs. Java app engines is concerned, the real key is design. If you design it badly, it will suck. If you design it well it won't suck. Which code base is better for what task is determined by the task at hand. What seems to be the most palatable design to date for the types of applications BOTH PHP and Java support is the Model View Controller model. You know.... separate business logic from presentation logic from DB logic and let each tire do the thing for which it was designed. You might liken this approach to using a hammer for nails, as wedge to split, saw to cut and a drill to make uniform holes. -
Anyone ever hear of MVC?
2003-11-03 11:49:14 anonymous2 [Reply | View]
I agree 100%...
My point may have the wrong place here. But as both a JSP/Servlet/JavaBean and PHP programmer I see an unbeatable marriage between PHP and JAVA.
The support is in it's infancy where you can call Java Beans with PHP. But I think the future is ready for an unbeatable marriage between PHP and Java. PHP performing the Model/View (get rid of JSP and Servlets, they both suck) and use the JavaBeans performing the Control.
You'd have the best of both worlds.
The Java support in Version 4 of PHP is the first step for this. When Verison 5 of PHP will be released, -
Anyone ever hear of MVC?
2003-11-03 11:58:11 anonymous2 [Reply | View]
Sorry. I need to re-read my post before I submit.
Article on the web about where Zend and Sun are merging the 2 technologies together. This might be what we all need to get people asking in a few years.... ".NET who????"
http://www.newsforge.com/programming/03/11/01/1859243.shtml?tid=105&tid=140&tid=48&tid=55
-
Two-tier vs. three-tier
2003-10-17 12:12:03 anonymous2 [Reply | View]
To begin with, the author apparently doesn't understand the reasons behind three-tiered architecture. It has nothing to do with "code factoring". It has to do with scalability. Not performance. Scalability. They are completely different issues, especially in the context of complex business applications.
In enterprise applications, it's not good enough that your end-to-end performance be good, it's also important that those machines service requests quickly, which is where a two-tiered architecture fails (and which is why people came up with the idea of a three-tiered architecture in the first place). This is the difference between performance and scalability.
For instance, suppose you get a sudden flood of requests coming in. Your webserver might be able to handle the number of incoming connections, but now, since all of the non-DB processing is happening on the same machine, you become CPU-bound, so that, even though the web server can accept more connections, it can't get enough of the CPU to service all of the requests it has.
Now, instead, think of a three-tier system. The web server handles the request, and passes off to another server (load balanced on the back end) to do the business processing (we're assuming here that the business processing is substantial compared to the display processing, which is usually the case in an enterprise context). Now, the web server can continue accepting requests up to its networking capacity, but it can offload its business processing onto *multiple* other machines if needs be, so that each request can happen faster, which is what the end user perceives as "better performance".
*That's* scalability. And that's what you won't achieve with PHP, or any two-tier based language. Now, if you want to talk about adding hooks to do remote procedure calls to PHP, or some other scripting language so you *can* do three-tier architecture, then we can talk about scalability (at least, scalability for an application that has non-trivial business logic). Otherwise, they are, and will continue to be, inadequate for complex business applications, because they aren't scalable. Period.
--
Jack Lund
STA Group, LLC -
Two-tier vs. three-tier
2003-12-12 09:11:13 anonymous2 [Reply | View]
Once a web server accepts an HTTP connection, that connection cannot be "passed off" to another system: it must handle that connection to completion.
Suppose an HTTP connection has been established between the client (e.g., browser) and the web server. That connection must remain open until the same web server generates a response. Also, even though information from the initial request may be is passed to another tier, the result of that information must be returned _back_ through the same web server for final processing before being returned to the client. During that time the web server must maintain all data structures necessary for the
- HTTP connection, and
- connection to the next tier (e.g., database connection).
This is where any scalability limitations apply.
It is better to maintain a redirector _ahead_ of the web servers. The purpose of this component is to redirect the request to the least-loaded web server. -
Two-tier vs. three-tier
2003-10-17 12:39:26 anonymous2 [Reply | View]
Physically separating the tiers is more hurtful than helpful. If your web server and application are both sharing the same hardware, and your application needs more power but your web server doesn't, how will it hurt anything to simply run the combination on more servers? It won't. But it will cut down on the overhead of communicating with remote servers, which is very significant.
The only thing that matters is being able to run the CPU-bound section (or whatever the bottleneck is) on more hardware. The fact that the web server is now getting more power than it needs is not a problem. -
Two-tier vs. three-tier
2003-10-17 12:53:13 anonymous2 [Reply | View]
It hurts things in several ways:
1) It means you now have to load balance across more web servers, which means you need more IP addresses mapped to your DNS entry (assuming you don't have a hardware-based web load balancer, which are expensive), which means changing your DNS entry every time you need more horsepower, which gets to be a pain to maintain.
2) You now have more webservers to maintain, rather than N webservers (N constant), and many more "generic" application machines. If you've every tried to maintain more than 10 webservers at a time, you'll realize this is a royal pain.
3) If you have a DMZ (which you probably do if you're in an enterprise situation), you don't really want your machines running your business logic in the DMZ (after all, we all know a DMZ is untrusted, right?). You especially don't want to multiply the number of DMZ machines because you're not getting the performance you need.
4) The assumption here is that the business logic is fairly non-trivial, i.e., that the hit you take from the network hop is trivial compared to the performance increase you get from being able to amortize the load across N machines.
5) It's MUCH easier to load balance back-end machines than webservers, simply because the discovery process for the webserver is DNS, whereas you can use something like a location service to find machines in the backend that can service your request. Even better, this means that you can add machines ON THE FLY in the backend without your front-end presence having to change at all. It's truly plug-and-play.
Folks, this is the reason for three-tiered architecture. Believe it or not, people didn't just make it up to sell more machines. It's a real solution to a real problem - how do you scale an application where the display processing is relatively trivial, but the business logic is where most of the processing occurs.
Gone are the days them PHP was called Personal Home Page and was only used for small websites. Today PHP is for both small and enterprise level applications. I am sure you must have heard about facebook.com and myheritage.com ??
Also, when you have backing of Oracle, Microsoft, IBM and SUN (please note Sun also funds JAVA) then I don't need to tell you how effective, scalable, fast and easy is PHP.
I think that, "building a web application in Java is like killing a housefly by a Bazooka." I am not saying it can not be done, all I am saying is just look at the time, cost and resources required to do that.
Here are few links to back my point: