PHP Scales As Well As Java 627
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."
yeah whatever (Score:2, Informative)
PHP is a useful language, and it certainly has its place. But for large enterprise applications, it can't hold a candle to J2EE, in terms of speed and scalability. If you drop some serious bank on an application server, you'll know what you're paying for.
Moderators, have mercy.
Re:Props to PHP (Score:1, Informative)
Some facts (Score:5, Informative)
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 ?
Re:Some facts (Score:3, Informative)
Re:of course it does... (Score:4, Informative)
Re:Some facts (Score:1, Informative)
if you want to do, for instance, something more complex like charting in a web page (well, in a .PNG), things can get messy.
Huh? I keep seeing this claim, where did it come from? PHP has had native image processing for years. PEAR also has an imagemagick module. Nothing messy involving C at all.
J2EE != EJB (Score:4, Informative)
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.
Re:Some facts (Score:3, Informative)
Re: Could someone explain instead of just flaming? (Score:3, Informative)
Performance-wise, J2EE decouples major components which would otherwise become bottleneck of overall performance. E.g. most popular architecture decouples frontend(e.g. load-balancer, apache), business logics(e.g. servlets, EJB-containers) and database(e.g. Oracle, Sybase) such that optimization could be done on individual components. Optimization can be ranged from adding CPU/RAM, disk stripping to clustering. Experience told us that this architecture can be very sucessful in improving performance and scalability.
I can't really disgree on the critism on the raw speed of Java, but as you may see J2EE successfully spreads the loading among entire framework, which lead to huge gain in overall performance.
I'm not going too deep into design and implementation issues here, as they might be off-topic this time. However, as you can see, design and implementation can be done seperately on each components as listed above.
Frankly, I'm not so sure if PHP has gone that far.
Get the most out of that aging single server (Score:4, Informative)
Jetty [mortbay.com] running on that single aging server will blow the doors off of PHP. That's what I saw when I did some BRL [codesimply.net] benchmarking some time ago. Presumably you'll get similar results with JSP.
Re:Some facts (Score:3, Informative)
Re:Here's why... (Score:3, Informative)
It's not clear to me that object oriented programming is a criteria for enterprise applications. Many of our big enterprise apps still use COBOL.
This all depends on how you define scalability, and what the app does. On our app, the web, business logic and data tier is all in VB, the calculation engine is in C++. We use Oracle as a back end. It handles the volume, for now.
Does it scale? Well, that all depends on your definition. Right now we have like 36 two-proc servers handling the load. It scales horizontally, just like PHP in this example.
For the past year they've been rewriting the whole app using C#, and it's almost done. During testing they've been able to handle the same load on four 8-proc servers, which is a bit easier to manage than 36.
"Trusting a VB-only developer to write an Enterprise class application is like having the "tire change boy" be your machanic. It is a stupid choice to make."
It depends. The C++ part of our app costs 4 times more to maintain than the VB part. It may be worth it, it's hard to say. I'm just glad we now have options like Java and C# out there, so I don't have to beat my head against the C++ wall.
Re:What is your point? (Score:3, Informative)
Python is a strongly typed language with extremely late binding.
Variables can change type at runtime, which means it's late binding.
Strong typing just means that variables definately do have a type (even if it can be easily changed) and you can't apply an illegal operator. For example:
>>> one = '1'
>>> two = '2'
>>> two / one
Traceback (most recent call last):
File "", line 1, in ?
TypeError: unsupported operand type(s) for
>>> one = int(one)
>>> two = int(two)
>>> two / one
2
>>>
so, you can change a variable's type, but it still does have a type, and as long as it has that type it's enforced strictly.