Slashdot Mirror
PHP Scales As Well As Java
mactari writes "Jack Herrington at the O'Reilly Network has had the audacity to claim that
both PHP and J2EE architecture... are converging on the same design [regarding scalability]. Can it be that he's disproven the idea that 'Java scales and scripting languages don't' when he says, 'The idea that PHP does not scale is clearly false at the performance level'?
Even if a little oversimplified (ignores horizontal scaling), it's an interesting comparison that takes a peek at the architecture beneath both hypes."
Well seeing as Yahoo is switching over to php, from C no less! Plus if you want to, you could use slashdot as an example of scripted sites. Of course slashdot at random interval won't load for about 10 or 15 minutes (rarely longer).
/* oops I accidentally made a comment, sorry */
2. DB is the bottleneck for most websites. A good connection pooling and caching system are critical. Ahem ... last time I checked, Java did considerably better than PHP in terms of both.
3. As PHP was not designed as a multipurpose language, sometimes a PHP-only solution is simply a kludge. PHP's power is in writing webpages quickly, if you want to do, for instance, something more complex like charting in a web page (well, in a .PNG), things can get messy. Yeah, you can do that in C, but what's the point ?
The Raven
What I would love to see is a 100,000+ lines project written in PHP being mantained by one or two developers. You can't do that without strict typing.
PHP is perfect for small projects, but when you have huge requerements and a ton of lines to mantain, that's when the real scalability shows off. You can build a 1,000,000+ lines project in PHP and run it on a distrubuted server and whatnot. But who the hell is going to mantain it??
Life isn't like a box of chocolates. It's more like a jar of jalapenos. What you do today, might burn your ass tomorrow.
Java scales up very well, PHP scales down better.
If you're trying to run on a budget where you can't add a ton of servers and are limited to aging technology, Java will not scale to that environment very well. PHP can do quite well there.
Sun isn't interested in that market, which is a shame because there are a lot of companies still cutting budgets. I'd love to buy a server newer than a P2 1ghz, but it's not going to happen until at least next fiscal and even then, unlikely. We don't all work for technology companies who understand or care.
The global economy is a great thing until you feel it locally.
...then yes, it does. However:
"PHP can use the database as the back-end session store."
and
"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."
are pretty tough assumptions to swallow. Storing session state in a database only works when you have a small amount of session state to store. Otherwise the database quickly becomes the bottleneck for any operation you need to perform. The alternative is that you have to have your session state distribuited in a cluster, which is something that, AFAIK, you cannot do in PHP. You can, however, do it Java. In fact, some of things that JBoss is trying to do will make session replication across a cluster fairly easy.
PHP can be very useful. I think PHP as a view layer sitting on top of a a J2EE controller and object model would be a wonderful idea. But to say "PHP scales as well as Java" is a huge oversimplification of the extremely complex problem that is enterprise computing.
"A page showing ten fields from twenty objects would make two hundred RMI calls before it was completed."
Sure if it was coded by former vb guy w/o a clue.
Even naive J2EE applications I saw would be smart enough to use a view object (containing all twenty business objects and their fields) to come back from the buisness layer in one call.
A person to use argument like this about J2EE scalability has no credibility whatsoever.
Maybe with dynamic typing, that would only be a 30,000 line project.
Tomcat is pretty slow in general. Why don't you try Resin?
Prevent email address forgery. Publish SPF records for y
PHP offers us no way to build an application server (unless you write one in C or C++ and send commands to it via a cli or directly through sockets). If you embed Tomcat in your application server, you can simply create contexts and mount them with mod_jk. Quite simply, you can take any server that you've written in Java and web enbale it fairly quickly. PHP lacks persistence, and I'm not talking about sessions.
Let's say that we want to add a request to our application from the web. With Java I can toss the request on a queue which a thread picks up and balances to several other worker threads who interpret the request and works with it. With PHP I would have to enter data into a flat file, or a database, and have a cronjob setup to run every minute or so and do something with data in the database. Even then, at that point, I can only have one thread unless I want to mix and match several cronjobs to run at seperate times (or unless I want to fork the process off very uncleanly using exec() or system()). In any case, does PHP scale as well as Java? Maybe, I'd need to do more tests. Is it nearly as useful? No, not right now, probably not ever. Unless you are willing to write your own custom PHP module in C and play with PHP that way, I think big jobs should be left to the heavyweight in this discussion.
"It's here, but no one wants it." - The Sugar Speaker
The article doesn't ignore horizontal scaling. It scales to over twice the width of my browser.
If Tyranny and Oppression come to this land,
it will be in the guise of fighting a foreign enemy. -James Madison
In the article, the author assumes that the J2EE application includes EJB's and from this assumption he builds in additional layers of overhead, especially with RMI calls to the EJB layer. His assumption is incorrect.
If you really want performance in a J2EE app, you can stick to JSP's and servlets and limit the usage of EJB's. Still keep the presentation in the JSP layer and isolate the business logic in servlets. This approach is quite lean and scales hugely.
When and how to use EJB's is just one part of J2EE application design.
Jetty running on that single aging server will blow the doors off of PHP. That's what I saw when I did some BRL benchmarking some time ago. Presumably you'll get similar results with JSP.
We have a 500,000+ line VB project that is very GUI intensive and it works/scale quite well. OO is good for some applications, but its more work than its worth for others. There are places in our project where having inheritence would be very helpful, but we have designed around this limitation. Threading for would have limited use as well. The ease of the GUI building more than makes up for the threading and OO limitations, at least in our project.
I'm not sure if your post was a troll or not, but it is pretty arrogant to assume any one language, especially one as widely used as VB, is for "kiddies."