Professional PHP

Troutgirl wieghs in with some more information on the Friendster PHP conversion:

1) We had not one but TWO guys here who had written bestselling JSP books. Not that this necessarily means they’re great Java devs, but I actually think our guys were as good as any team.

2) We tried rewriting the site in Java twice, using MVC and all available best practices. It actually got slower. Anyway, what does MVC have to do with speed or scalability? I thought it was a design cleanliness and maintainability thing.

3) We tried different app servers, different JVMs, different machines.

4) Anything that money could do, it did.

George Schlossnagle has the best coverage of the topic, saying It’s the App code, stupid (As an Adult Swim fan, I have to appreciate the Big O reference):

My personal bias against java is that many Java programmers seem to be thread-crazy, and as has been noted, humans just aren’t smart enough to program threads.

I once lost a job by saying “Threads are dangerous” at a job interview. Everything was going well, until they asked me what I thought about threading. (this was a business application) Obviously, my opinion didn’t agree with this companies vision for their software. Ironically, I was being interviewed to help them fix their problems with frequent unrepeatable lockups and GPFs. They did not see the connection.

One advantage of PHP is that it simplifies your life by not bothering you with threading, just as it doesn’t bother you with memory management. That doesn’t mean that concurrency issues go away, any multi user application will have them, it just means that they are made explicit at the application level.

George Schlossnagle:

Share nothing’ (which if you don’t want to click on the link basically means not performing much inter-process or inter-thread data sharing or pooling) is not something unique to PHP. In fact, I’m quite sure that you can implement it in Java as well. The problem is that Java gives you a number of powerful facilities with which to shoot yourself in the foot

Here is a java performance article that recommends against object pooling. The struts vs. webwork comparison has an interesting take on this:

Struts Actions must be thread-safe because there will only be one instance to handle all requests. This places restrictions on what can be done with Struts Actions as any resources held must be thread-safe or access to them must be synchronized.

WebWork Actions are instantiated for each request, so there are no thread-safety issues. In practice, Servlet containers generate many throw-away objects per request, and one more Object does not prove to be a problem for performance or garbage collection.

It seems like the Java culture, if not the java language seems to encourage premature optimization in the form of creating pools of shared information.

John Lim expresses some skepticism about the inherent scalability properties of any language, claiming its the developer skill not the language.

I think I’ll end this post with heresy. The field of web development seems to have a mental model of application development forged from the dot-com boom era. We operate with the vision that our applications are going to experience exponential usage growth. Perhaps this leads to an unhealthy focus on scalability in web applications versus other requirements. Perhaps this also leads us to employ optimizations prematurely before we can even understand their impact or even have a need for them. Perhaps these premature optimizations even hurt scalability and performance and needlessly complicate our applications.

Perhaps the Java Culture is more infected with “dot-com-itis” than the php culture?

Scalability - YAGNI?