> 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 of data that it adds to the output brigade.
>>>>
>>>> The 'ub' stands for unbuffered.. you can avoid that by
>>>> enabling output buffering in php.ini.
>>>
>>> IMHO, that's a design flaw. Regardless of whether PHP is doing
>>> buffering, it shouldn't break up blocks of static content into
>>> small pieces--especially not as small as 400 bytes. While it's
>>> certainly valid for PHP to insert a flush bucket right before a
>>> block of embedded code (in case that code takes a long time to
>>> run), breaking static text into 400-byte chunks will usually mean
>>> that it takes *longer* for the content to reach the client, which
>>> probably defeats PHP's motivation for doing the nonbuffered output.
>>> There's code downstream, in the httpd's core_output_filter and
>>> the OS's TCP driver, that can make much better decisions about
>>> when to buffer and when not to buffer.
>>
>
> We did quite a lot of tests on this issue a couple of years ago and found
> that not scanning all of the embedded HTML in one big piece but breaking
> it down to chunks around 400bytes yields better performance.
>
> I can say that in general, best performance with PHP is achieved when
> using full output buffering. ASP seems to do the same and while we were at
> MS Labs doing benchmarks of PHP vs. ASP this was one of the settings we
> found made PHP compete well with ASP.
>
> Another change we made, as I mentioned in a previous Email, was using
> non-mutexing per-thread memory pools (HeapCreate(HEAP_NO_SERIALIZE, ...)).
> To get best performance with Apache 2 we would really need such a memory
> pool.
And we already have it! Just do:
apr_allocator_t *allocator;
apr_allocator_create(&allocator);
apr_pool_create_ex(&pool, parent_pool, abort_fn, allocator);
apr_allocator_owner_set(allocator, pool);
Now you have a mutexless allocator associated with a pool. All child pools
of this pool will use the same allocator and will therefor also have no
mutex.
Apache 2.0 uses this extensively in the mpms where we indeed know that only
one thread is going to be accessing a pool.
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.
Sidenote: the mutex isn't even being used on each and every allocation, only
when a full 8k block is fully consumed and a new one is needed.
[Pasted this in from a mail in the same thread]
>>* php_request_shutdown() calls shutdown_memory_manager(), which
>> does a large number of calls to free() per request. If there's
>> any way to get the PHP allocator to use an APR pool, that
>> should help speed things up a lot. (The mallocs and frees are
>> going to be especially problematic within multithreaded MPMs.)
> We're already doing this for Win32. Check out
> ZEND_DO_MALLOC/ZEND_DO_FREE/ZEND_DO_REALLOC in zend_alloc.c. Note that in
> Win32 we only skip the free's if we're in release mode. If we're in debug
> mode we use a per-thread pool but we do the frees because it's our memory
> leak detector.
Just run with --enable-pool-debug=yes and enable a tool like electric fence
or valgrind. No need to put that stuff in your own code.
> Andi
Sander
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
