> > > A user posted [1] a "benchmark" today in the German PHP Newsgroup [2] > > > stating that Apache 2.0 and PHP (current HEAD) are about 20% slower > > > than Apache 1.3.
On Thu, Jun 06, 2002 at 09:05:16AM -0700, Rasmus Lerdorf wrote: > > It doesn't really surprise me. The bucket brigade stuff adds overhead as > > does the thread stuff in PHP. There is nothing inherently faster about > > threaded apps. They tend to scale a little bit better in most cases, so > > under extreme load performance should be better. But under light loads I > > would expect a non-threaded Apache+PHP to be quicker. From: Aaron Bannert [mailto:[EMAIL PROTECTED]] > Right, so I'd expect (hope) that at low load the performance is > still reasonably fast, but at high concurrency and high load it still > performs. Another thing that is gained in the new Apache 2.0 multithreaded > architecture is memory conservation -- I've run a 500-thread system on > under 20MB resident memory. Under Apache 1.3 that would require > hundreds of MB of memory. This is a subject about which I still wonder. Multi-threading is a huge win for applications where the amount of computation is small, and most of the time is spent waiting on I/O. File servers are a classic example (NFS, SMB, FTP, file only HTTP) where multi-threading is a huge win. There are major downsides to multi-threading that need mention. For one making an application thread-safe requires substantial code, and the added code effectively imposes a run-time "tax". For another applications that do a lot of computation are very often complex, and complex applications naturally contain more bugs. So a complex application - one with lots of computation between each context switch - may well be slower and less reliable when written as a multi-threaded application. Where is the cross-over point? Another question is the true memory footprint. Back in the late 1980's pretty much every Unix vendor added copy-on-write fork() semantics to their implementation. I believe Linux also uses the same copy-on-write (sometimes known as COW) behavior in fork(). Copy-on-write means that when you fork() a process, each process gets it's own virtual memory address space, but the physical memory is in fact *shared* between two processes. Immediately after fork() the contents of memory is exactly the same, so why store it twice? When a process writes to one of the shared pages a copy is made, and the virtual pages no longer share physical memory. Naturally the operating system still has to allocate virtual memory and swap space for the new process, but the amount of added physical memory used may in fact be very small. So the physical memory footprint for a multi-threaded application may in fact not be much different from a tradition Unix application that uses multiple processes. I don't know how to verify this - dig out the physical memory usage and check the copy-on-write behavior - on Linux. -- Preston L. Bannister http://members.cox.net/preston.bannister/ pbannister on Yahoo Messenger -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
