Re: [PHP-DEV] Re: APC in trunk
On Wed, Jun 23, 2010 at 2:47 AM, Ilia Alshanetsky i...@prohost.org wrote: I believe it is a *nix specific patch. Yes, the patch is unix only. I don't think either it can be simply 'ported' to windows. -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Performance problem with php
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 smalys...@sugarcrm.comwrote:
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 how it is
accessed - through relative path, symlinks, etc. Example can be
{include|require}_once. For that, it needs to figure out the whole path. It
is done only once per file, then cached. If you seeing it on repeated runs
in the same process, increase your realpath cache size (yes, the default is
way too small for any big app).
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
Vincenzo D'Amore
email: v.dam...@gmail.com
msn: free...@hotmail.com
skype: free.dev
mobile: +39 349 8513251
Re: [PHP-DEV] Performance problem with php
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 same for each file regardless of
how it is accessed - through relative path, symlinks, etc. Example can
be {include|require}_once. For that, it needs to figure out the whole
path. It is done only once per file, then cached. If you seeing it on
repeated runs in the same process, increase your realpath cache size
(yes, the default is way too small for any big app).
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
in main memory because the OS already knows the files are the same,
and finding the real name of a file is a slow process).
Wietse
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Performance problem with php
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
file - i.e. filename that would be the same for each file regardless of
how it is accessed - through relative path, symlinks, etc. Example can
be {include|require}_once. For that, it needs to figure out the whole
path. It is done only once per file, then cached. If you seeing it on
repeated runs in the same process, increase your realpath cache size
(yes, the default is way too small for any big app).
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
in main memory because the OS already knows the files are the same,
and finding the real name of a file is a slow process).
When properly configured the realpath result should be cached as well
though and we avoid calling a hash function on what could potentially be
a lot of data.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Performance problem with php
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 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
how it is accessed - through relative path, symlinks, etc. Example can
be {include|require}_once. For that, it needs to figure out the whole
path. It is done only once per file, then cached. If you seeing it on
repeated runs in the same process, increase your realpath cache size
(yes, the default is way too small for any big app).
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
in main memory because the OS already knows the files are the same,
and finding the real name of a file is a slow process).
When properly configured the realpath result should be cached as well
though and we avoid calling a hash function on what could potentially be
a lot of data.
The idea is to replace lstat system calls by hashing; in both cases
one would cache the result. Which is faster depends on the number
of pathname elements: system calls are relatively expensive, and
memory mapping could avoid the need for explicit file read() system
calls. If someone has the time then they can test if my idea is
totally bonkers (which it may well be).
Wietse
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] svn account
Hi. I wanted to request an svn user for fixing the hungarian documentation, but I got this error: An error occured when trying to create the account: someone is already using that svn id I'm curious that we have another guy around here with the same nick, or I've just registered(maybe I got it with my wiki.php.net account?) in the past already, and forgot it. Tyrael
Re: [PHP-DEV] Performance problem with php
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 with different name. Second, to know that I'd need to open and read the whole file and then compute the hash of it - which sounds quite expensive. Right now with proper caching non-including include_once can be done with 0 system calls (unfortunately, pure PHP doesn't do it yet, though IIRC Zend's Optimizer+ does - not sure about APC). in main memory because the OS already knows the files are the same, and finding the real name of a file is a slow process). It's only slow process once, then it's cached. And I'm not sure it's faster to load all the file into memory then check it's path. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-DOC] svn account
On Jun 23, 2010, at 11:24 AM, Ferenc Kovacs wrote: Hi. I wanted to request an svn user for fixing the hungarian documentation, but I got this error: An error occured when trying to create the account: someone is already using that svn id I'm curious that we have another guy around here with the same nick, or I've just registered(maybe I got it with my wiki.php.net account?) in the past already, and forgot it. The account request lives within the queue as of today: tyrael: Wed, 23 Jun 2010 05:49:37 -0700 - Fixing(and maybe taking over the maintaining) the hungarian documentation to let it to be enabled again. Maybe the form was submitted twice? That or more likely there's a bug somewhere because there isn't a svn account request email on the list, so that's not good. Maybe wiki related, I'll look into it. Also, write the doc list (and doc-hu@) and say hi, and we'll get this going :) Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Performance problem with php
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 ras...@lerdorf.com 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 set apc.stat=0 to not check for file modifications. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/...
[PHP-DEV] Re: [PHP-DOC] svn account
On Wed, Jun 23, 2010 at 8:50 PM, Philip Olson phi...@roshambo.org wrote: On Jun 23, 2010, at 11:24 AM, Ferenc Kovacs wrote: Hi. I wanted to request an svn user for fixing the hungarian documentation, but I got this error: An error occured when trying to create the account: someone is already using that svn id I'm curious that we have another guy around here with the same nick, or I've just registered(maybe I got it with my wiki.php.net account?) in the past already, and forgot it. The account request lives within the queue as of today: tyrael: Wed, 23 Jun 2010 05:49:37 -0700 - Fixing(and maybe taking over the maintaining) the hungarian documentation to let it to be enabled again. Yep, thats me. Maybe the form was submitted twice? That or more likely there's a bug somewhere because there isn't a svn account request email on the list, so that's not good. Maybe wiki related, I'll look into it. Maybe, I had to try 2 or 3 times before setting up everything perfectly. :) Also, write the doc list (and doc-hu@) and say hi, and we'll get this going :) will do, thanks. Tyrael
Re: [PHP-DEV] Performance problem with php
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. APC works around the open call by replacing the opcode handler. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Compilation of trunk with --enable-dtrace
Hi, On Wed, 2010-06-23 at 22:04 +0200, Frederic Hardy wrote: f...@witchblade:/usr/home/fch/php/sapi/cli 26 sudo dtrace -ln 'php*:::' -c './php -m' Password: ID PROVIDERMODULE FUNCTION NAME Segmentation fault: 11 (core dumped) Well, if DTrace segfaults I'd guess that's due to the DTrace port, not PHP. It works for me on Solaris. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Compilation of trunk with --enable-dtrace
On 06/23/2010 22:43, Johannes Schlüter wrote: Hi, On Wed, 2010-06-23 at 22:04 +0200, Frederic Hardy wrote: f...@witchblade:/usr/home/fch/php/sapi/cli 26 sudo dtrace -ln 'php*:::' -c './php -m' Password: ID PROVIDERMODULE FUNCTION NAME Segmentation fault: 11 (core dumped) Well, if DTrace segfaults I'd guess that's due to the DTrace port, not PHP. It works for me on Solaris. I'm agree. But i will hope that someone has the same problem or has a solution. Can you say me if dtrace -l | grep php must return nothing ? Best regards, Fred. -- Frédéric Hardy : Architecte d'application/Admin. système/Ergonome Status : En recherche d'emploi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
