Let me see if I understand the argument posted here: Why PHP Scales - A Cranky, Snarky Answer.
1. Php scales because the programmers are more careful designers, since everyone always tells them that their platform doesn't scale (paragraph 1) and they want to prove everyone wrong.
2. Php scales because it has a "share nothing" architecture.
3. Php scales because the language helps keep you from falling into typical scalability tar pits.
#2 is really the only argument as to why php scales. #1 is a generalization about the programmers which could apply to any platform/lanage, and #3 is a usability issue, not a scalability issue (it's perfectly possible to build essentially the same architecture that PHP uses in Java).
So we're left with the "share nothing" architecture. That's great if you can design your app so it is stateless on the server side. An app that doesn't have to worry about tracking state will always be faster and more scalable. But most full-functioned applications require some notion of state.
It seems that most of the friendster-php flap circles around this "share nothing" idea. But it seems that there is sharing, it's just at the database layer. So it's not really avoiding sharing, it's just pushing the sharing somewhere else. Essentially it's forcing you to build a robust, scalable database layer. Maybe that's okay, because you probably need one anyway. Personally, I'd rather have the design flexibility to scale at other levels as well. Why force the sharing to happen at the RDBMS layer, where you likely incur the overhead of transactions, network, and disk access. Since sessions need some of this capability, there is a certain elegance in reusing the RDBMS for it, but I've never thought performance would be one of them.
Theoretically at least, a model like weblogic's in-memory session replication should be much faster than a full blown RDBMS. Especially when start throwing more and more servers into the mix. 100 servers making reads and writes to a mysql database serving up session info is going to bring things to a crawl rather quickly.
In the end, it doesn't matter much, all we've proven is that you can build non-scalable apps in java and we can build non-scalable apps in php. No news there. The fact that the friendster team seems to be convincied that it's impossible to build a scalable app in java seems to point at some sort of misunderstanding on their part though, that's the only thing rubbing me the wrong way.
Basically, while I don't doubt that php scales, there's no reason Java can't scale the same way, and no one talking about this discussion has produced any accurate arguments as to why java can't scale the same way.
You misunderstand the "share nothing" architecture. PHP applications are not stateless. PHP/Apache is stateless.
With a PHP application if you want to maintain state you use proven systems like file systems and databases. The scalability of PHP is limited to the scalablity of your database or filesystem. The PHP attitude is to use Oracle or LDAP or RADIUS to solve problems, not create your own PHPDB solution.
That is unlike Java which has an application server in the middle that must be deployed in a careful way so that it scales as well. That's why Java has to create new solutions to already solved problems (like scaleablity).
Thanks for the comment (good to have some non-spam comments; are you sure you don't want to sell me some herbal viagra as well? :-)).
I don't misunderstand the share nothing architecture; I see the difference between sharing nothing (stateless app) and storing the state in various locations.
In almost every java app server you can store the sessions in a database if you wish, thus using the same architecture as PHP, and if that's truly the best performance/scalability tradeoff you are free to make it.
Again; not saying PHP doesn't scale, just saying that I haven't yet seen a real argument as to why java wouldn't scale in the same way. The friendster people can say that "Java doesn't scale" and that's fine, because I know it to be false. They can make that blanket statement and discard Java as an option automatically; personally I'll keep both in the toolbox and use each where appropriate.
to get back to the java vs php flame war:
do php have all the “threads problem” that java servlets have?
if u don’t synchronize risk corruption of shared variables, threadlocal is complicated.
if u synchronize, welcome to the world of complicated chain of locks
This is Rob Meyer's weblog, a weblog focused on software development and system administration based on 10 years of experience. Want to explore further? You can find out more me or see the rest of my website.
Wondering if I've written on something in particular? Try searching:
You might want to take a look at some of the more requested postings (as judged by incoming traffic):
Want more? Subscribe to this site 
or contact me at rob at big dis dot com.
See my writings on: