Hello all,
I have already notified to the mailing list a performance problem with
apache/mod_php5.
Now I have an update and I think this is probably a bug.
PHP lstat the full path more times before read the file when in apache httpd
configuration is specified *PHP_ADMIN_VALUE open_basedir *settin
On 6/23/10 12:38 PM, Stas Malyshev wrote:
> Hi!
>
>> But sadly not usable with common apps or frameworks as it will break
>> very easily.
>>
>> That's fixable (userland) but painful.
>
> I didn't mean the stat call but rather the open call which precedes
> include_once. stat is a separate issue.
Hi!
But sadly not usable with common apps or frameworks as it will break
very easily.
That's fixable (userland) but painful.
I didn't mean the stat call but rather the open call which precedes
include_once. stat is a separate issue.
--
Stanislav Malyshev, Software Architect
SugarCRM: http:/
But sadly not usable with common apps or frameworks as it will break very
easily.
That's fixable (userland) but painful.
On 23 Jun 2010 20:44, "Rasmus Lerdorf" wrote:
On 6/23/10 11:40 AM, Stas Malyshev wrote:
> Hi!
>
>> Another option may be to compute a hash of the...
APC does the same if you
On 6/23/10 11:40 AM, Stas Malyshev wrote:
> Hi!
>
>> Another option may be to compute a hash of the file. When you find
>> that file content has the same hash value as a known file you flag
>> them as "same file". This could be faster (file contents are cached
>
> First, two files with the same
Hi!
Another option may be to compute a hash of the file. When you find
that file content has the same hash value as a known file you flag
them as "same file". This could be faster (file contents are cached
First, two files with the same content is not the same as same file
referred twice wi
Rasmus Lerdorf:
[ Charset ISO-8859-1 unsupported, converting... ]
> On 6/23/10 6:56 AM, Wietse Venema wrote:
> > Stas Malyshev:
> >> Hi!
> >>
> >>> could anybody tell me why also for every single php file engine must lstat
> >>> all path?
> >>> Why php engine don't simply try to open directly the f
On 6/23/10 6:56 AM, Wietse Venema wrote:
> Stas Malyshev:
>> Hi!
>>
>>> could anybody tell me why also for every single php file engine must lstat
>>> all path?
>>> Why php engine don't simply try to open directly the file?
>>
>> There are some places where PHP engine has to know "true" name of the
Stas Malyshev:
> Hi!
>
> > could anybody tell me why also for every single php file engine must lstat
> > all path?
> > Why php engine don't simply try to open directly the file?
>
> There are some places where PHP engine has to know "true" name of the
> file - i.e. filename that would be the sa
Many thanks to everybody helped me.
I will follow your suggestions and check it.
Best regards,
Vincenzo
On Mon, Jun 21, 2010 at 9:39 PM, Stas Malyshev wrote:
> Hi!
>
>
> could anybody tell me why also for every single php file engine must lstat
>> all path?
>> Why php engine don't simply try to
Hi!
could anybody tell me why also for every single php file engine must lstat
all path?
Why php engine don't simply try to open directly the file?
There are some places where PHP engine has to know "true" name of the
file - i.e. filename that would be the same for each file regardless of
ho
On 6/21/10 9:35 AM, Vincenzo D'Amore wrote:
> Thanks Rasmus,
>
> we are using wordpress. Looking at code:
>
> find . -type f -exec grep realpath {} \;
>
> I see a lot of:
>
> if ( function_exists('realpath') )
> $path = realpath($path);
> if ( function_exists('realpath') )
> $path = realpath($p
hi,
On Mon, Jun 21, 2010 at 7:23 PM, Vincenzo D'Amore wrote:
> Hello All,
>
> could anybody tell me why also for every single php file engine must lstat
> all path?
It is done once per paths set and then cached.
> Why php engine don't simply try to open directly the file?
Many reasons, one of
Hello All,
could anybody tell me why also for every single php file engine must lstat
all path?
Why php engine don't simply try to open directly the file?
[pid 13792] lstat("/usr", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
[pid 13792] lstat("/usr/local", {st_mode=S_IFDIR|0755, st_size=4096,
Rasmus,
I have disabled realpath from php.ini,
disable_functions =
passthru,proc_close,proc_get_status,proc_nice,proc,exec,shell_exec,system,proc_open,popen,curl_multi_exec,parse_ini_file,show_source,set_time_limit,error_reporting,mail,fsockopen,ini_set,
*realpath*
And stop and start of apache h
Thanks Ferenc,
there is non Suhosin patch/extension installed.
On Mon, Jun 21, 2010 at 4:52 PM, Ferenc Kovacs wrote:
> Check the output of phpinfo()
> should see
> "This server is protected with the Suhosin Patch"
> and/or
> "This server is protected with the Suhosin Extension"
>
> Tyrael
>
> O
Thanks Rasmus,
we are using wordpress. Looking at code:
find . -type f -exec grep realpath {} \;
I see a lot of:
if ( function_exists('realpath') )
$path = realpath($path);
if ( function_exists('realpath') )
$path = realpath($path);
if ( function_exists('realpath') )
$path = realpath($path);
Check the output of phpinfo()
should see
"This server is protected with the Suhosin Patch"
and/or
"This server is protected with the Suhosin Extension"
Tyrael
On Mon, Jun 21, 2010 at 4:48 PM, Vincenzo D'Amore wrote:
> Hello Oliver,
>
> looking at php.ini configuration I don't see any suhosin ent
Hello Oliver,
looking at php.ini configuration I don't see any suhosin entry, so I think
no.
do you know if there is another way to understand if it is installed?
On Sun, Jun 20, 2010 at 12:06 PM, Olivier B. wrote:
> Hi,
>
> are you using the "suhosin" patch for PHP ? I can see the same lstat
>
Is this only useful for 5.2.x and is it only for realpath() or is it for any
sort of path lookup and caching? Like resolving include paths and such?
On Jun 20, 2010, at 6:37 AM, Rasmus Lerdorf wrote:
> realpath_cache_size = 256k
> realpath_cache_ttl = 7200
--
PHP Internals - PHP Runtime Deve
On 6/19/10 11:49 PM, Vincenzo D'Amore wrote:
> Could anybody explain me why I have this behavior and if it is attributable
> to a misconfiguration of php?
This doesn't look like a PHP misconfiguration. It looks more like an
application-level issue. Do a grep for "realpath" in your application
co
Hi,
are you using the "suhosin" patch for PHP ? I can see the same lstat
behaviour with my setups, because of suhosin.
But for the 8 tentative of reading, are you sure php deliver only one
page here ?
Olivier
Le 20/06/2010 08:49, Vincenzo D'Amore a écrit :
Hello,
to have a performance prob
If you have more than once directory in your include path, then the engine
have to look up the given file in each of the given directories, which is in
the worst case scenario (the given file is in the directory which is in the
last in the include path) could mean N lookup, where N is the number of
Hi Dinh,
sorry, I don't get why having a wrong include_path configuration inside WP
should have a negative outcome like have 8 tentatives in order to read this
file.
Regards,
Vincenzo
On Sun, Jun 20, 2010 at 9:26 AM, Dinh wrote:
> Hi,
>
> Unfortunately, your web application abused include_pat
Yes, right.
# /usr/libexec/php5-cgi/bin/php -v
PHP 5.2.9 (cli) (built: Sep 14 2009 16:52:55)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies
with the ionCube PHP Loader v3.1.33, Copyright (c) 2002-2007, by ionCube
Ltd.
# httpd -V
Server vers
Hi.
Shouldn't we seeing failed lstats if the include_path would be the problem?
And I thought that the php engine itself tries to cache the fileinfo, to
minimize the lstat calls ( see
http://hu.php.net/manual/en/function.clearstatcache.php )
So I think that we shouldn't see this much duplicate lst
Hi,
Unfortunately, your web application abused include_path. You can change WP
source code to include PHP files using absolute path
Regards,
Dinh
On Sun, Jun 20, 2010 at 1:49 PM, Vincenzo D'Amore wrote:
> Hello,
>
> to have a performance problem with apache/mod_php5 configuration under
> heavy
On 20.06.2010, at 10:49, Vincenzo D'Amore wrote:
> Hello,
>
> to have a performance problem with apache/mod_php5 configuration under heavy
> load the website becomes too slow.
> Using strace I found what appears to me a strange behavior
> The strange behavior I want point out is related to a seq
Hello,
to have a performance problem with apache/mod_php5 configuration under heavy
load the website becomes too slow.
Using strace I found what appears to me a strange behavior
The strange behavior I want point out is related to a sequence of tentative
httpd/mod_php5 does in order to read an php
29 matches
Mail list logo
