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."

yeah whatever

[TedCheshireAcad]

I call bullshit.

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

[marmoset]

PHP is certainly cool, but there are some fairly major gaps [joelonsoftware.com] to be filled.

Some facts

[vlad_petric]

1. Scaling != performance. Scaling simply means that if you multiply the hardware by n you should be getting (ideally) close to throughput *n.

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

[consumer]

PHP provides persistent connections, so the system does not need to reconnect to the database on each hit. It also provides various caching tools, like memcached [danga.com]. Charts and graphs are typically handled with third-party libraries. It's not exactly hard.

Re:of course it does...

[FattMattP]

Tomcat is pretty slow in general. Why don't you try Resin [caucho.com]?

Re:Some facts

[Anonymous Coward]

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

[shaper]

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

[consumer]

Connection pooling only scales better if most of the time in your application is spent doing calculations or something without the database. If your app mostly is about accessing a database, then the connection will be constantly in use and there will be no benefit from pooling.

Re: Could someone explain instead of just flaming?

[jsse]

I'll try.

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

[brlewis]

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

[crazyphilman]

Connection pooling means, basically, that the server sets up a pool of already open connections to a database, and your app can borrow a connection from the pool when it needs to interact with the database, then release the connection back to the pool. It's a performance trick, because opening a connection and closing it eats up resources, so you open up all the connections at once and leave them open, and they just handle requests which is less resource-intensive. I haven't had much need for it myself, but I've read about it...

Re:Here's why...

[sheldon]

I work for a Fortune 500 company as well, and one of our major web apps is written in a combination of ASP, VB and C++.

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?

[jadavis]

Python, Perl, PHP, Ruby... Thats four object orientated languages without strong typing

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 /: 'str' and 'str'
>>> 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.