PHP with open_basedir performance problem

[Miroslav Lachman]

Antony Mawer wrote:

> On 28/01/2008 6:52 PM, Alexey Popov wrote:
> 
>> The problem is that concurrent lstat()'s are very slow on FreeBSD now.
>>
>> Possibly you can decrease the number of lstat() calls by tuning 
>> realpath cache size in PHP. Just add "realpath_cache_size=512k" to 
>> php.ini. However I'm not sure this cache is used in open_basedir.
>>
>> See the following thread for details:
>> http://lists.freebsd.org/pipermail/freebsd-stable/2007-November/038371.html 
>>
> 
> 
> ... so how does one go about profiling lstat() to find out where the 
> source of the slowness originates from? Is pmc profiling the way to do 
> this?
> 
> The last thread on this topic (referenced above) seemed to point the 
> finger at the default value of vfs.ufs.dirhash_maxmem being too small... 
> which would suggest this is an inherit limitation in UFS(2?) and/or its 
> default tuning.
> 
> If you try increasing the amount of memory allocated for dirhash, does 
> this improve performance at all? eg:
> 
>     # sysctl vfs.ufs.dirhash_maxmem=10240000
>     vfs.ufs.dirhash_maxmem: 2097152 -> 10240000
> 
> ... and then re-run the benchmarks to see if this makes any noticeable 
> difference. The fact that it was indicated that Mac OS X also suffers 
> the same problems suggests this may be a VFS issue rather than UFS 
> specific...?

I tried sysctl vfs.ufs.dirhash_maxmem=10240000 and 
realpath_cache_size=512k in php.ini and sysctl vfs.lookup_shared=1
but all without any significant impact on performance with open_basedir 
enabled.
I also tried this patch for vfs_cache 
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/vfs_cache.c.diff?r1=1.114;r2=1.115 
but again without success.

top shows following CPU usage for synthetic test with PHP 5.2.5 on 
7.0-BETA4 with SCHED_ULE an vfs_cache patch + both sysctl tunables and 
php.ini directive:
CPU states:  8.1% user,  0.0% nice, 88.6% system,  0.2% interrupt,  3.2% 
idle

Does somebody have any other ideas?

Miroslav Lachman