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

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

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

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 i

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

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 > is called from alloc_globals_c

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

Zeev Suraski wrote: > PHP has its own buffering mechanism which can take care of this. Try > output_buffering = 4096 in your php.ini. That works, but IMHO it won't help enough unless it becomes the default. The problem, from my perspective, is that people using the default, non-buffered set

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

Cliff Woolley wrote: > > > > > It looks like "unbuffered" PHP output in 1.3 is benefitting from the > > httpd's own buffering. And "unbuffered" output in 2.0, in contrast, > > is really, really not buffered, because of the flush buckets inserted > > by php_apache_sapi_ub_write. > > > If the un

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

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 alloc

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

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 pa

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

Andi Gutmans wrote: > At 10:47 AM 6/8/2002 -0700, Brian Pane wrote: ... >> So the simplest case, the lifetime of a pool looks like: >> - create the pool, requiring a lock/unlock >> - do hundreds of allocations from the pool, none of which require >> locking > > > You mean that different thr

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

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).

[PHP-DEV] CVS Account Request: netholic

I want to translate docs into Korean. -- PHP Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] filesystem security questions

The more I think about it, I dont know if streams should be done in the domxml extension currently. This is a big change from its current implementation and if it was to be undertaken, then why not just start fresh with the unified implementation? You are talking about implementing everything as s

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

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 l

[PHP-DEV] Re: PHP profiling results under 2.0.37 Re: Performance of Apache2.0 Filter

On Sat, 8 Jun 2002, Brian Pane wrote: > 1.3: > writev(3, [{"HTTP/1.1 200 OK\r\nDate: Sat, 08 J"..., 4089}, {"28\r\n", > 4}, {" write(3, "ffb\r\nas"..., 4098) = 4098 ... > 2.0: > writev(8, [{"HTTP/1.1 200 OK\r\nDate: Sat, 08 J"..., 220}, {"47\r\n", > 4}, {" writev(8, [{"6\r\n", 3}, {"", 6}, {"\r\n

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

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 could be achieved by compiling apr_po

[PHP-DEV] Re: PHP profiling results under 2.0.37 Re: Performance of Apache2.0 Filter

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 packets even for script-generated output, not just for blocks of static text. For example, I just compared the write patterns for 2.0.37 and 1.3.24, both with the

Re: [PHP-DEV] Zend Engine expert wanted!

At 2:57 AM +0300 6/8/02, Zeev Suraski wrote: >We're on the job. I generally think you're right, we have to do >some more thinking but chances are we will change the shutdown order >to be reversed. Just a FYI, may want to do the same for zend_extension (reverse order). I think that is a zend_

[PHP-DEV] CVS Account Request: thku

like to check my improvements of the OOHForms in -> talked to ulf wendel and the rest oh the german php user group at the linux tag -- PHP Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] filesystem security questions

I am talking about the domxml. After thinking about a bit and reading the post from Melvyn, I think that streams might be the way to go, but not quite positive yet. In a long term sense, I am just not sure how far domxml is going to go; meaning the discussion of the unified xml implementation. I

Re: [PHP-DEV] filesystem security questions

Are you talking about your own extension or ext/domxml ? I think (but could be wrong) that sooner or later streams should be used everyone for consistency. - Markus On Sat, Jun 08, 2002 at 07:22:25AM -0400, Rob Richards wrote : > I think using stream functions may be overkill fo

[PHP-DEV] On vacation

I'm on vacation until June 16th and will not read any mail until I return. Your mail concerning "Assigned PHP 4 bugs reminder" will be read when I'm back. Stig -- PHP Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] PHP 4 Bug Summary Report

PHP 4 Bug Database summary - http://bugs.php.net Num Status Summary (1564 total including feature requests) ===[*Configuration Issues] 13561 Suspended --without-pear prevent install of php-config,phpize,... 15182 Open php.ini seems

[PHP-DEV] Re: PHP profiling results under 2.0.37 Re: Performance of Apache2.0 Filter

On Fri, 7 Jun 2002, Cliff Woolley wrote: > > On Fri, 7 Jun 2002, Brian Pane wrote: > > > 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 > > cer

Re: [PHP-DEV] filesystem security questions

Hi Rob, At 13:22 8-6-2002, Rob Richards shared with all of us: >right now I am using the following to test for a remote path: > if (!strncasecmp(file,"http://";, 7) || !strncasecmp(file,"ftp://";, 6)) { >which could be expanded upon if additional protocols are added to libxml. From a user'

Re: [PHP-DEV] filesystem security questions

I think using stream functions may be overkill for what I need to do. While fixing an issue with using relative paths in domxml and decided to add filesecurity features in at the same time. The file path comes in as a string and is sent directly to libxml as such. also, going through the locate_u

Re: [PHP-DEV] filesystem security questions

At 12:42 PM 6/8/2002 +0200, Markus Fischer wrote: > Practically, there's no documentation about streams except > some mail Wez sent to php-dev@ a few weeks (months?) ago (and > the sources, of course), I hope you can find it in the > archives. Maybe we can get Wez to write complet

Re: [PHP-DEV] filesystem security questions

Hi, On Sat, Jun 08, 2002 at 06:22:29AM -0400, Rob Richards wrote : > I have a few questions about correctly implementing safe_mode, open_basedir > and allow_url checks within an extension. > Probably an easy question, but I have seen it implemented in various ways in > different extensions a

[PHP-DEV] filesystem security questions

I have a few questions about correctly implementing safe_mode, open_basedir and allow_url checks within an extension. Probably an easy question, but I have seen it implemented in various ways in different extensions and want to make sure i implement this correctly. allow_url checks: is there

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

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_s

Re: [PHP-DEV] Re: [Zend Engine 2] RE: [PHP-DEV] oo != php

At 05:02 AM 6/8/2002 +0100, Michael Dransfield wrote: >At 02:40 08/06/2002 +0100, you wrote: >> > There are two reasons we repeat the 'PHP is not Java mantra': >> > >> > (a) Many of those requesting these changes actually DO want to see PHP >> > as a Java with PHPish syntax. >> >>Anyone wanting P

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

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 > doe