NYCPHP Meetup

NYPHP.org

[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