PHP with open_basedir performance problem

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

PHP with open_basedir performance problem

Miroslav Lachman
Hi all,

I found a painful performance problem with Apache + PHP 5 when
open_basedir directive is enabled.
Application performance drops by more than 50% with open_basedir enabled.
There is also significant disproportion between usr / sys CPU load. (sys
is much higher than usr)
I do not know if this is problem on FreeBSD side or in PHP code itself.
This problem exists on FreeBSD 6 and 7 (maybe older versions too - I did
not check).
I tested both shedulers on FreeBSD 7, no big difference (application
performance is little better with 4BSD).
Is there anyone with enough knowledge and time to look at it?

This problem affects Mac OS X as well, but does not seem to appear on Linux.
http://lists.apple.com/archives/macos-x-server/2006/Nov/msg00623.html


Application workload - tested by http_load (on dual Xeon 3GHz!)
with open_basedir: 11.5403 fetches/sec
without open_basedir: 4.53845 fetches/sec


Synthetic test:
## with open_basedir
CPU states: 17.5% user,  0.0% nice, 82.3% system,  0.2% interrupt,  0.0%
idle

# http_load -parallel 10 -fetches 1000 load.urls
1000 fetches, 10 max parallel, 2000 bytes, in 29.3449 seconds
2 mean bytes/connection
34.0775 fetches/sec, 68.155 bytes/sec
msecs/connect: 0.302057 mean, 0.441 max, 0.156 min
msecs/first-response: 292.693 mean, 525.471 max, 159.389 min
HTTP response codes:
  code 200 -- 1000

## without open_basedir
CPU states: 54.0% user,  0.0% nice, 45.2% system,  0.8% interrupt,  0.0%
idle

http_load -parallel 10 -fetches 1000 load.urls
1000 fetches, 10 max parallel, 2000 bytes, in 4.47231 seconds
2 mean bytes/connection
223.598 fetches/sec, 447.196 bytes/sec
msecs/connect: 0.297157 mean, 0.442 max, 0.153 min
msecs/first-response: 44.3433 mean, 157.334 max, 8.044 min
HTTP response codes:
  code 200 -- 1000



Simple testcase:

---- content of index.php ----
<?php
$num = 100;
for ($i = 0; $i < $num; $i++) {
    require_once('whatever.php');
}
?>


---- content of whatever.php ----
<?php
// whatever, does not matter
?>

http_load is instructed to do 1000 fetches of index.php in 10 parallel
connections.


Miroslav Lachman

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: PHP with open_basedir performance problem

Thomas Hurst
* Miroslav Lachman ([hidden email]) wrote:

> I found a painful performance problem with Apache + PHP 5 when
> open_basedir directive is enabled.

Looks like it's lstat()/readlink() overhead.  I wrote a simple bit of
PHP similar to yours, but doing 10 * 1000 require "foo/%d/%d.php" calls
from the command line:

-% time ktrace php main.php
Real: 0:09.61 CPU: 99.8% (3.725/5.885) Page: 0 Swap: 0 I/O: (0/0) Mem:
13704

-% time ktrace php -d open_basedir='/home/freaky/openbasedir/foo'
main.php
Real: 0:16.21 CPU: 86.4% (8.185/5.840) Page: 0 Swap: 0 I/O: (0/0) Mem:
13696

Without open_basedir, a simple script to parse the kdump syscall times
produces:

   lstat        : 1.147s/70065 calls = 0.000s per call.  Max=0.000s Min=0.0000s
   fcntl        : 0.408s/60007 calls = 0.000s per call.  Max=0.000s Min=0.0000s
sigprocmask     : 0.229s/40311 calls = 0.000s per call.  Max=0.000s Min=0.0000s
    open        : 0.223s/10085 calls = 0.000s per call.  Max=0.000s Min=0.0000s

With open_basedir:

   lstat        : 4.182s/270065 calls = 0.000s per call.  Max=0.005s Min=0.0000s
readlink        : 2.142s/10006 calls = 0.000s per call.  Max=2.020s Min=0.0000s
   fcntl        : 0.421s/60007 calls = 0.000s per call.  Max=0.002s Min=0.0000s
   close        : 0.295s/10085 calls = 0.000s per call.  Max=0.115s Min=0.0000s
sigprocmask     : 0.237s/40311 calls = 0.000s per call.  Max=0.000s Min=0.0000s
    open        : 0.222s/10085 calls = 0.000s per call.  Max=0.000s Min=0.0000s

The top two syscalls seem to account for most of the 6.mumble seconds of
additional runtime; presumably these are much cheaper on Linux.

--
Thomas 'Freaky' Hurst
    http://hur.st/
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: PHP with open_basedir performance problem

Miroslav Lachman
Thomas Hurst wrote:

> * Miroslav Lachman ([hidden email]) wrote:
>
>
>>I found a painful performance problem with Apache + PHP 5 when
>>open_basedir directive is enabled.
>
>
> Looks like it's lstat()/readlink() overhead.  I wrote a simple bit of
> PHP similar to yours, but doing 10 * 1000 require "foo/%d/%d.php" calls
> from the command line:
>
> -% time ktrace php main.php
> Real: 0:09.61 CPU: 99.8% (3.725/5.885) Page: 0 Swap: 0 I/O: (0/0) Mem:
> 13704
>
> -% time ktrace php -d open_basedir='/home/freaky/openbasedir/foo'
> main.php
> Real: 0:16.21 CPU: 86.4% (8.185/5.840) Page: 0 Swap: 0 I/O: (0/0) Mem:
> 13696
>
> Without open_basedir, a simple script to parse the kdump syscall times
> produces:
>
>    lstat        : 1.147s/70065 calls = 0.000s per call.  Max=0.000s Min=0.0000s
>    fcntl        : 0.408s/60007 calls = 0.000s per call.  Max=0.000s Min=0.0000s
> sigprocmask     : 0.229s/40311 calls = 0.000s per call.  Max=0.000s Min=0.0000s
>     open        : 0.223s/10085 calls = 0.000s per call.  Max=0.000s Min=0.0000s
>
> With open_basedir:
>
>    lstat        : 4.182s/270065 calls = 0.000s per call.  Max=0.005s Min=0.0000s
> readlink        : 2.142s/10006 calls = 0.000s per call.  Max=2.020s Min=0.0000s
>    fcntl        : 0.421s/60007 calls = 0.000s per call.  Max=0.002s Min=0.0000s
>    close        : 0.295s/10085 calls = 0.000s per call.  Max=0.115s Min=0.0000s
> sigprocmask     : 0.237s/40311 calls = 0.000s per call.  Max=0.000s Min=0.0000s
>     open        : 0.222s/10085 calls = 0.000s per call.  Max=0.000s Min=0.0000s
>
> The top two syscalls seem to account for most of the 6.mumble seconds of
> additional runtime; presumably these are much cheaper on Linux.

I did some more research on saturday - test with old PHP 5 version 5.1.4
on FreeBSD 7.0 machine. It seems there is some significant change in PHP
code.

(on = with open_basedir / off = without open_basedir):
# real webapplication
FreeBSD 6.0 + PHP 5.1.4  on / off = 6.8 / 13.5 req/s
FreeBSD 7.0 + PHP 5.2.5  on / off = 3.6 / 12.9 req/s
FreeBSD 7.0 + PHP 5.1.4  on / off = 8.0 / 11.8 req/s

# synthetic test
FreeBSD 6.0 + PHP 5.1.4  on / off =  98.3 / 144.2 req/s
FreeBSD 7.0 + PHP 5.2.5  on / off =  20.6 / 245.4 req/s
FreeBSD 7.0 + PHP 5.1.4  on / off = 204.3 / 239.5 req/s

It demonstrates my performance problem from year ago (also reported on
this list 2007-02-03 with subject "PHP Performance problem after upgrade
to 5.1.6 or 5.2.0"). It is still unsolved problem, but now I know it is
influenced by open_basedir.
As I reported a year ago - problem occured in 5.1.6 (maybe 5.1.5 - I
never tried it, I jumped from 5.1.4 to 5.1.6 or newer). Can somebody
look at PHP sources of those two versions and find the "bad change"?

This was reported to PHP developers by me
http://bugs.php.net/bug.php?id=38940 but marked as "bogus" with comment
"We only support our own sources, not ports or patched source or binary
packages."

Is there any chance to fix this on FreeBSD side (patch in ports) or in
PHP itself?
I don't want to lose performance with each "security" upgrade of PHP. :(

Miroslav Lachman
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: PHP with open_basedir performance problem

Thomas Hurst
* Miroslav Lachman ([hidden email]) wrote:

> As I reported a year ago - problem occured in 5.1.6 (maybe 5.1.5 - I
> never tried it, I jumped from 5.1.4 to 5.1.6 or newer). Can somebody
> look at PHP sources of those two versions and find the "bad change"?

Handily I have 5.1.4 sources right next to my copy of trunk PHP5;
main/fopen_wrappers.c php_check_specific_open_basedir() is about half
the size there, and doesn't perform any readlink() calls, so it's
probably vulnerable to escaping the basedir using symlinks, but
considerably faster.

--
Thomas 'Freaky' Hurst
    http://hur.st/
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: PHP with open_basedir performance problem

Hugo Silva-2
In reply to this post by Miroslav Lachman
Miroslav Lachman wrote:

> Hi all,
>
> I found a painful performance problem with Apache + PHP 5 when
> open_basedir directive is enabled.
> Application performance drops by more than 50% with open_basedir enabled.
> There is also significant disproportion between usr / sys CPU load. (sys
> is much higher than usr)
> I do not know if this is problem on FreeBSD side or in PHP code itself.
> This problem exists on FreeBSD 6 and 7 (maybe older versions too - I did
> not check).
> I tested both shedulers on FreeBSD 7, no big difference (application
> performance is little better with 4BSD).
> Is there anyone with enough knowledge and time to look at it?
>
> This problem affects Mac OS X as well, but does not seem to appear on
> Linux.
> http://lists.apple.com/archives/macos-x-server/2006/Nov/msg00623.html

I too have seen this, sys% is so MUCH higher and jumps from about 30% to
70% and higher all the time. In my case it's like 3% user time, 30-70%
system time. I will try disabling open_basedir on one of the webservers
and report back.

Best regards,

Hugo
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: PHP with open_basedir performance problem

Hugo Silva-2
Hugo Silva wrote:

> Miroslav Lachman wrote:
>> Hi all,
>>
>> I found a painful performance problem with Apache + PHP 5 when
>> open_basedir directive is enabled.
>> Application performance drops by more than 50% with open_basedir
>> enabled.
>> There is also significant disproportion between usr / sys CPU load. (sys
>> is much higher than usr)
>> I do not know if this is problem on FreeBSD side or in PHP code itself.
>> This problem exists on FreeBSD 6 and 7 (maybe older versions too - I did
>> not check).
>> I tested both shedulers on FreeBSD 7, no big difference (application
>> performance is little better with 4BSD).
>> Is there anyone with enough knowledge and time to look at it?
>>
>> This problem affects Mac OS X as well, but does not seem to appear on
>> Linux.
>> http://lists.apple.com/archives/macos-x-server/2006/Nov/msg00623.html
>
> I too have seen this, sys% is so MUCH higher and jumps from about 30%
> to 70% and higher all the time. In my case it's like 3% user time,
> 30-70% system time. I will try disabling open_basedir on one of the
> webservers and report back.
>
> Best regards,
>
> Hugo
> _______________________________________________
> [hidden email] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-performance
> To unsubscribe, send any mail to
> "[hidden email]"

 From 30-70% to 3%. What a difference!

Hugo
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: PHP with open_basedir performance problem

Hugo Silva-2
Hugo Silva wrote:

> Hugo Silva wrote:
>> Miroslav Lachman wrote:
>>> Hi all,
>>>
>>> I found a painful performance problem with Apache + PHP 5 when
>>> open_basedir directive is enabled.
>>> Application performance drops by more than 50% with open_basedir
>>> enabled.
>>> There is also significant disproportion between usr / sys CPU load.
>>> (sys
>>> is much higher than usr)
>>> I do not know if this is problem on FreeBSD side or in PHP code itself.
>>> This problem exists on FreeBSD 6 and 7 (maybe older versions too - I
>>> did
>>> not check).
>>> I tested both shedulers on FreeBSD 7, no big difference (application
>>> performance is little better with 4BSD).
>>> Is there anyone with enough knowledge and time to look at it?
>>>
>>> This problem affects Mac OS X as well, but does not seem to appear
>>> on Linux.
>>> http://lists.apple.com/archives/macos-x-server/2006/Nov/msg00623.html
>>
>> I too have seen this, sys% is so MUCH higher and jumps from about 30%
>> to 70% and higher all the time. In my case it's like 3% user time,
>> 30-70% system time. I will try disabling open_basedir on one of the
>> webservers and report back.
>>
>> Best regards,
>>
>> Hugo
>> _______________________________________________
>> [hidden email] mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-performance
>> To unsubscribe, send any mail to
>> "[hidden email]"
>
> From 30-70% to 3%. What a difference!
>
> Hugo
> _______________________________________________
> [hidden email] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-performance
> To unsubscribe, send any mail to
> "[hidden email]"


http://bugs.php.net/bug.php?id=43946
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: PHP with open_basedir performance problem

Alexey Popov-3
In reply to this post by Miroslav Lachman
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


Miroslav Lachman wrote:

> Hi all,
>
> I found a painful performance problem with Apache + PHP 5 when
> open_basedir directive is enabled.
> Application performance drops by more than 50% with open_basedir enabled.
> There is also significant disproportion between usr / sys CPU load. (sys
> is much higher than usr)
> I do not know if this is problem on FreeBSD side or in PHP code itself.
> This problem exists on FreeBSD 6 and 7 (maybe older versions too - I did
> not check).
> I tested both shedulers on FreeBSD 7, no big difference (application
> performance is little better with 4BSD).
> Is there anyone with enough knowledge and time to look at it?

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: PHP with open_basedir performance problem

Antony Mawer-12
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...?

--Antony
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: 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
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: PHP with open_basedir performance problem

Alexey Popov-3
Hi

Miroslav Lachman wrote:

> 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.
> CPU states:  8.1% user,  0.0% nice, 88.6% system,  0.2% interrupt,  3.2%
> idle
> Does somebody have any other ideas?
Here's the patch helped me in the similar situation:
http://lists.freebsd.org/pipermail/freebsd-stable/2007-November/038449.html

If it also does not help, I think LOCK_PROFILING(9) and pmc stats
( http://freebsd.rambler.ru/bsdmail/freebsd-current_2006/msg01581.html ) would
be useful to see what exactly is slow.

With best regards,
Alexey Popov
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: PHP with open_basedir performance problem

Stanislav Sedov-3
In reply to this post by Miroslav Lachman
On Mon, Jan 28, 2008 at 03:23:52PM +0100 Miroslav Lachman mentioned:
>
> Does somebody have any other ideas?
>

I'd suggest you to disable open_basedir at all or roll out specialized
implementation. I had a lot of similar problems with open_basedir in
the past, so I just rewrote it to match our specific security policy.

Most basedir problems are linked with the fact it produce a lot of lstast/
readlinks on every require, include or open command. On Linux it pereforms
even worse, as they implemented readlink there by hand, and, of course,
their implementation isn't particulry good.

I don't thinks this problem could be solved with PHP guys, taking in account
the fact that a simple bug report with the patch usually result in two weeks
of formal replies like "it's not a bug, it's a feature". Not speaking about
they desicover new bugs in basedir every couple of days.

--
Stanislav Sedov
ST4096-RIPE
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: PHP with open_basedir performance problem

Arkadi Shishlov
Stanislav Sedov wrote:
> I'd suggest you to disable open_basedir at all or roll out specialized
> implementation. I had a lot of similar problems with open_basedir in
> the past, so I just rewrote it to match our specific security policy.

Can you share a hint how exactly this specialized implementation may look like?
The requirement is simple: php script working under apache mod_php can't open files outside of
virtual host document root whenever php safe mode is enabled or disabled. Website owners can create
symlinks.
I understand the open_basedir is kinda flawed security measure, and safe_mode is a primary safeguard
with mod_php, but it would be nice to get it working under FreeBSD too.

> Most basedir problems are linked with the fact it produce a lot of lstast/
> readlinks on every require, include or open command. On Linux it pereforms
> even worse, as they implemented readlink there by hand, and, of course,
> their implementation isn't particulry good.

But there is no high sys cpu usage on Linux in contrary to FreeBSD, as reported by original author
of the thread..?
Do you have numbers or benchmark ready? I see the number of syscalls required is astonishing (on
Linux) but doesn't cause any problem at first look.
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: PHP with open_basedir performance problem

Stanislav Sedov-3
On Thu, Feb 14, 2008 at 07:22:46PM +0200 Arkadi Shishlov mentioned:

> Stanislav Sedov wrote:
>> I'd suggest you to disable open_basedir at all or roll out specialized
>> implementation. I had a lot of similar problems with open_basedir in
>> the past, so I just rewrote it to match our specific security policy.
>
> Can you share a hint how exactly this specialized implementation may look like?
> The requirement is simple: php script working under apache mod_php can't
> open files outside of virtual host document root whenever php safe mode is
> enabled or disabled. Website owners can create symlinks.
> I understand the open_basedir is kinda flawed security measure, and
> safe_mode is a primary safeguard with mod_php, but it would be nice to get
> it working under FreeBSD too.

Well, my security mechanizms are pretty simple and use some combination of
MAC and bare uids/gid to enforce required permissions. The code is about
100 lines of code, much less then original open_basedir implementation.
In any case, the code won't be usuful to you as is, it works combined with
ad-hoc apache module, that sets required flags, variables, etc.

>
>> Most basedir problems are linked with the fact it produce a lot of lstast/
>> readlinks on every require, include or open command. On Linux it pereforms
>> even worse, as they implemented readlink there by hand, and, of course,
>> their implementation isn't particulry good.
>
> But there is no high sys cpu usage on Linux in contrary to FreeBSD, as
> reported by original author of the thread..?
> Do you have numbers or benchmark ready? I see the number of syscalls
> required is astonishing (on Linux) but doesn't cause any problem at first
> look.
>

I don't have specific benchmark numbers, and it's true, that top on Linux
don't show such sys time usage, as on FreeBSD boxes. However, the overall
performance of boxes on FreeBSD is 30-40% higher, that Linux ones. This numbers
is empirical, but I'm pretty sure in them: in past I migrated Linux hosting
to FreeBSD-based, and after that, I was able to add a bunch of new users to
that boxes without performance impact. In fact, the load average on these
boxes are MUCH lower, that was on Linux. Also, I notices, that stat() costs
much more on Linux, that FreeBSD. I don't certainly know, why Linux shows low
sys time usage, probably it's just bugs in accounting.

My basedir patches was implemented later on FreeBSD boxes, and I never returned
to Linux. Thus I can't say whether it impacts Linux performance, or nor...

--
Stanislav Sedov
ST4096-RIPE
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: PHP with open_basedir performance problem

Arkadi Shishlov
Stanislav Sedov wrote:

> On Thu, Feb 14, 2008 at 07:22:46PM +0200 Arkadi Shishlov mentioned:
>> Stanislav Sedov wrote:
>>> Most basedir problems are linked with the fact it produce a lot of lstast/
>>> readlinks on every require, include or open command. On Linux it pereforms
>>> even worse, as they implemented readlink there by hand, and, of course,
>>> their implementation isn't particulry good.
>> But there is no high sys cpu usage on Linux in contrary to FreeBSD, as
>> reported by original author of the thread..?
>> Do you have numbers or benchmark ready? I see the number of syscalls
>> required is astonishing (on Linux) but doesn't cause any problem at first
>> look.
>
> I don't have specific benchmark numbers, and it's true, that top on Linux
> don't show such sys time usage, as on FreeBSD boxes. However, the overall
> performance of boxes on FreeBSD is 30-40% higher, that Linux ones. This numbers
> is empirical, but I'm pretty sure in them: in past I migrated Linux hosting
> to FreeBSD-based, and after that, I was able to add a bunch of new users to
> that boxes without performance impact. In fact, the load average on these
> boxes are MUCH lower, that was on Linux. Also, I notices, that stat() costs
> much more on Linux, that FreeBSD. I don't certainly know, why Linux shows low
> sys time usage, probably it's just bugs in accounting.

I can confirm the FreeBSD was significantly faster than Linux in the
open_basedir test I just conducted. With open_basedir check enabled, FreeBSD
throughput dropped 2x, Linux 3x, and FreeBSD is 2x faster than Linux in this
situation.

The test system is Pentium4 3.8GHz HT, 2MB cache, 2.5GB RAM.
FreeBSD 7.0-RELEASE i386.
Linux kernel 2.6.24.2 i386.
Both kernels are SMP.
Software is lighttpd 1.4.18, PHP 5.2.5 in FastCGI mode, without op-code cache.

The index.php that was tested by ApacheBench is a do-nothing script, that just
includes other scripts (in sub-dir.), that in turn include other scripts,
bringing total count of includes to 25 - like in a typical PHP application.
Website document root depth is 4 (/usr/local/www/data).

I've varied test parameters and filesystem setup (tmpfs, mdmfs), but in overall
the picture is:

http         | no open_basedir     | with open_basedir
response size>    25kB  |     50B  |    50B
-------------+----------+----------+------------------
FreeBSD      | 192/125  | 243/ 89  | 99/247
Linux        | 165/116  | 152/126  | 50/382
         [Requests per second / 99% of requests served within N ms]

ApacheBench concurency level is 15.
10 FastCGI processes.
TOP shows approximatelly  20% user / 80% system time split for both Linux and
FreeBSD in all tests (so accounting is likely correct on Linux).

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[hidden email]"