[nycphp-talk] thread-safety analysis...
Paul Houle
paul at devonianfarm.com
Sun Oct 22 13:08:04 EDT 2006
Hans Zaunere wrote:
> This I disagree with. One of the primary reasons Java is built to be
> threaded from the ground up is that it has to be. I couldn't imagine having
> a separate process instance of Java for every request - there isn't a server
> on the planet with that much RAM - whereas PHP/Apache can happily live in
> 15-25mb of RAM or less. Long story short, PHP is fair lighter than Java,
> threads or no threads
In the limit of low load and small memory consumption per process,
you're right. Java often takes 50 MB to just get started. Under the
real-world circumstances of most developers, PHP is remarkably
efficient. In most cases, my understanding is that PHP burns up about
2 M per process -- it takes 25 of those to equal an idle Java process,
and you can still fit 1000 processes in 2 GB, a typical amount of
memory for a small server.
When considering details, it gets more complicated. It's not just
a matter of the cost of the runtime system, but also the cost of memory
that your application uses. In a language like Java, you can create a
really big data structure, say, 200 MB in RAM; you might load it out
of a file when your application starts. Thousands of threads can share
that data structure, getting excellent performance with low memory
consumption. This is one way Java can win for large systems.
Java has it's own problems that surface in large systems. Java uses
16-bit characters internally, which is a bad choice. Java puffs up
English text by a factor of two, but can't handle Chinese text
correctly. In my book, Lucene is a toy. When I'm handling 5 GB of
text, I dont need to have my storage requirements doubled.
More information about the talk
mailing list