[PHP-DEV] RE: PHP profiling results under 2.0.37 Re: Performance of Apache 2.0 Filter

2002-06-10 Thread Sander Striker
From: Andi Gutmans [mailto:[EMAIL PROTECTED]] Sent: 08 June 2002 13:59 On Fri, 7 Jun 2002, Ryan Bloom wrote: On Fri, 7 Jun 2002, Brian Pane wrote: On Fri, 2002-06-07 at 01:14, Sascha Schumann wrote: The function php_apache_sapi_ub_write() is inserting a flush bucket after each bucket

Re: [PHP-DEV] RE: PHP profiling results under 2.0.37 Re: Performance of Apache 2.0 Filter

2002-06-10 Thread Zeev Suraski
At 09:03 AM 6/10/2002, Sander Striker wrote: Why is PHP even using its own memory allocation scheme? It would be much easier to just use pools and point out where it doesn't work for you. Because we don't want it depend on any underlying services which aren't available in all servers. We can

Re: [PHP-DEV] RE: PHP profiling results under 2.0.37 Re: Performance of Apache 2.0 Filter

2002-06-10 Thread Aaron Bannert
On Mon, Jun 10, 2002 at 11:46:46AM +0300, Zeev Suraski wrote: What we need for efficient thread-safe operation is a mechanism like the Win32 heaps - mutexless heaps, that provide malloc and free services on a (preferably) contiguous pre-allocated block of memory. The question is whether

Re: [PHP-DEV] RE: PHP profiling results under 2.0.37 Re: Performance of Apache 2.0 Filter

2002-06-10 Thread Aaron Bannert
On Mon, Jun 10, 2002 at 09:29:58AM -0700, Aaron Bannert wrote: - creation (called once per server lifetime) - malloc (called many times per request) - free (called many times per request) - end-of-request (called many times per request) (Whoops, that should have been -- called

Re: [PHP-DEV] RE: PHP profiling results under 2.0.37 Re: Performance of Apache 2.0 Filter

2002-06-10 Thread Zeev Suraski
At 07:29 PM 6/10/2002, Aaron Bannert wrote: On Mon, Jun 10, 2002 at 11:46:46AM +0300, Zeev Suraski wrote: What we need for efficient thread-safe operation is a mechanism like the Win32 heaps - mutexless heaps, that provide malloc and free services on a (preferably) contiguous pre-allocated

Re: [PHP-DEV] Re: PHP profiling results under 2.0.37 Re: Performance of Apache 2.0 Filter

2002-06-09 Thread Aaron Bannert
On Sun, Jun 09, 2002 at 03:09:24AM +0300, Zeev Suraski wrote: Hmm, but doesn't that mean that the largest contiguous block this heap will be able to provide is 8KB, then? 8K is just the minimum chunk size, there is no absolute maximum. * There's a two-layer structure to the heaps: -

Re: [PHP-DEV] Re: PHP profiling results under 2.0.37 Re: Performance of Apache 2.0 Filter

2002-06-09 Thread Andi Gutmans
At 12:53 PM 6/9/2002 -0700, Aaron Bannert wrote: On Sun, Jun 09, 2002 at 03:09:24AM +0300, Zeev Suraski wrote: Hmm, but doesn't that mean that the largest contiguous block this heap will be able to provide is 8KB, then? 8K is just the minimum chunk size, there is no absolute maximum. *

Re: [PHP-DEV] Re: PHP profiling results under 2.0.37 Re: Performance of Apache 2.0 Filter

2002-06-08 Thread Andi Gutmans
At 09:12 PM 6/7/2002 -0700, Brian Pane wrote: In case it's helpful to the PHP developers, here are some more performance problems that I found by running a quick system call profile of PHP-4.2.1 within Apache-2.0.37-dev: * php_request_shutdown() calls shutdown_memory_manager(), which does a

Re: [PHP-DEV] Re: PHP profiling results under 2.0.37 Re: Performance of Apache 2.0 Filter

2002-06-08 Thread Andi Gutmans
At 10:41 AM 6/8/2002 +0300, Andi Gutmans wrote: At 09:12 PM 6/7/2002 -0700, Brian Pane wrote: In case it's helpful to the PHP developers, here are some more performance problems that I found by running a quick system call profile of PHP-4.2.1 within Apache-2.0.37-dev: * php_request_shutdown()

[PHP-DEV] Re: PHP profiling results under 2.0.37 Re: Performance of Apache 2.0 Filter

2002-06-08 Thread Aaron Bannert
On Sat, Jun 08, 2002 at 02:03:21PM -0400, Cliff Woolley wrote: If the unbuffered write really *is* allowed to be buffered (wtf?), then by all means we should change to using apr_brigade_write() there instead of the flush() buckets. The data that gets passed to ub_write() is transient in

Re: [PHP-DEV] Re: PHP profiling results under 2.0.37 Re: Performance of Apache 2.0 Filter

2002-06-08 Thread Andi Gutmans
At 10:47 AM 6/8/2002 -0700, Brian Pane wrote: Andi Gutmans wrote: I just checked and it seems like Apache APR memory pools use mutex locking. It'd be better to use functions like the Win32 ones which don't use mutex locking (as we made sure that only one thread allocates from its pool). This

Re: [PHP-DEV] Re: PHP profiling results under 2.0.37 Re: Performance of Apache 2.0 Filter

2002-06-08 Thread Zeev Suraski
PHP has its own buffering mechanism which can take care of this. Try output_buffering = 4096 in your php.ini. Zeev At 08:33 PM 6/8/2002, Brian Pane wrote: Looking at some more syscall call traces, I'm seeing that the flush buckets used by php_apache_sapi_ub_write() are causing very small

Re: [PHP-DEV] Re: PHP profiling results under 2.0.37 Re: Performance of Apache 2.0 Filter

2002-06-08 Thread Zeev Suraski
At 12:55 AM 6/9/2002, Brian Pane wrote: I just looked through zend_alloc.c. It looks like the HeapCreate only happens once, at startup--did I get that right? It's called on the per-thread startup (start_memory_manager(), which is called from alloc_globals_ctor(), which is the per-thread

Re: [PHP-DEV] Re: PHP profiling results under 2.0.37 Re: Performance of Apache 2.0 Filter

2002-06-08 Thread Zeev Suraski
At 02:57 AM 6/9/2002, Brian Pane wrote: In the httpd, we've done two things to minimize the fragmentation: * Memory for these heaps is almost always allocated in chunks of a fixed size, 8KB. Hmm, but doesn't that mean that the largest contiguous block this heap will be able to provide is

Re: [PHP-DEV] Re: PHP profiling results under 2.0.37 Re: Performance of Apache 2.0 Filter

2002-06-08 Thread Andi Gutmans
At 04:57 PM 6/8/2002 -0700, Brian Pane wrote: Zeev Suraski wrote: At 12:55 AM 6/9/2002, Brian Pane wrote: I just looked through zend_alloc.c. It looks like the HeapCreate only happens once, at startup--did I get that right? It's called on the per-thread startup (start_memory_manager(), which