Re: [PHP-DEV] APC in trunk
On Jun 21, 2010, at 10:02 PM, Zeev Suraski wrote: > At 14:09 21/06/2010, Pierre Joye wrote: >> Same here. >> >> +1 to bundle >> -1 to enable it by default > > Slightly late to the game but my view is the same, +1 to bundle, -1 to enable > by default. Is it too late to discuss the topic of leaving extensions in PECL, and bundling [some] near release time? Maybe Trunk could begin that idealistic revolution? Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
At 14:09 21/06/2010, Pierre Joye wrote: Same here. +1 to bundle -1 to enable it by default Slightly late to the game but my view is the same, +1 to bundle, -1 to enable by default. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: APC in trunk
hi, On Tue, Jun 22, 2010 at 12:21 AM, Derick Rethans wrote: > On Tue, 22 Jun 2010, Kalle Sommer Nielsen wrote: > >> It seems like theres been enough votes for moving it to the core, is >> there anyone willing to make that change? Rasmus or Derick? We can >> always decide whether to enable it by default afterwards. > > I can do it; but the question is whether we want to use APC 3.x or 4.x > in trunk? Gopal, Rasmus? For one, I would prefer to see 4.x but I'm not sure it is ready yet. However 4.x also needs the changes applied to support recent optimizations in the engine (they have been applied to trunk only). I would suggest to do the merges prior to include it. Cheers, -- 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
[PHP-DEV] Re: APC in trunk
Hi It seems like theres been enough votes for moving it to the core, is there anyone willing to make that change? Rasmus or Derick? We can always decide whether to enable it by default afterwards. As for enabled it by default, I think it should be okay to atleast enable it as a shared extension by default, atleast on Windows, like GD is. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: APC in trunk
On Tue, 22 Jun 2010, Kalle Sommer Nielsen wrote: > It seems like theres been enough votes for moving it to the core, is > there anyone willing to make that change? Rasmus or Derick? We can > always decide whether to enable it by default afterwards. I can do it; but the question is whether we want to use APC 3.x or 4.x in trunk? Gopal, Rasmus? regards, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Performance problem with php
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Safemode Missing?
On 06/21/2010 11:16 PM, Sufficool, Stanley wrote: > OK, order of operations problem. Remove references, then remove file or no > one can build. ;-) It builds allright, check your build. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Safemode Missing?
>-Original Message- >From: Pierre Joye [mailto:pierre@gmail.com] >Sent: Monday, June 21, 2010 12:18 PM >To: Sufficool, Stanley >Cc: Ferenc Kovacs; internals@lists.php.net >Subject: Re: [PHP-DEV] Safemode Missing? > > >On Mon, Jun 21, 2010 at 9:16 PM, Sufficool, Stanley > wrote: >> OK, order of operations problem. Remove references, then remove file >> or no one can build. ;-) >> >> When will this be complete? > >It builds just fine. Be sure to: > >- make clean >- buildconf > >before trying again :) > >Cheers, Thanks, I thought of that 2 seconds before you replied... No really, I did ;-) Thanks >> >> On Mon, Jun 21, 2010 at 9:09 PM, Sufficool, Stanley >> mailto:ssuffic...@rov.sbcounty.gov>> >> wrote: >> >> >> Trunk no longer contains main/safe_mode.c >> >> Is this being removed? >> >> make: *** No rule to make target `/php-src/main/safe_mode.c', needed >> by `main/safe_mode.lo'. Stop. >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> >> >> >> > > > >-- >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] Safemode Missing?
On Mon, Jun 21, 2010 at 9:16 PM, Sufficool, Stanley wrote: > OK, order of operations problem. Remove references, then remove file or no > one can build. ;-) > > When will this be complete? It builds just fine. Be sure to: - make clean - buildconf before trying again :) Cheers, > > On Mon, Jun 21, 2010 at 9:09 PM, Sufficool, Stanley > mailto:ssuffic...@rov.sbcounty.gov>> wrote: > > > Trunk no longer contains main/safe_mode.c > > Is this being removed? > > make: *** No rule to make target `/php-src/main/safe_mode.c', needed by > `main/safe_mode.lo'. Stop. > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > -- 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] Safemode Missing?
OK, order of operations problem. Remove references, then remove file or no one can build. ;-) When will this be complete? -Original Message- From: tyr...@gmail.com [mailto:tyr...@gmail.com] On Behalf Of Ferenc Kovacs Sent: Monday, June 21, 2010 12:12 PM To: Sufficool, Stanley Cc: internals@lists.php.net Subject: Re: [PHP-DEV] Safemode Missing? yes Tyrael On Mon, Jun 21, 2010 at 9:09 PM, Sufficool, Stanley mailto:ssuffic...@rov.sbcounty.gov>> wrote: Trunk no longer contains main/safe_mode.c Is this being removed? make: *** No rule to make target `/php-src/main/safe_mode.c', needed by `main/safe_mode.lo'. Stop. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Safemode Missing?
yes Tyrael On Mon, Jun 21, 2010 at 9:09 PM, Sufficool, Stanley < ssuffic...@rov.sbcounty.gov> wrote: > Trunk no longer contains main/safe_mode.c > > Is this being removed? > > make: *** No rule to make target `/php-src/main/safe_mode.c', needed by > `main/safe_mode.lo'. Stop. > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
[PHP-DEV] Safemode Missing?
Trunk no longer contains main/safe_mode.c Is this being removed? make: *** No rule to make target `/php-src/main/safe_mode.c', needed by `main/safe_mode.lo'. Stop. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
>From my point-of-view as a developer (and occasional sysadmin) this is something which I have been looking forward too for some time so +1 for including in core +1 for compiling but not enabling Marco -- 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/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($path);
> if ( function_exists('realpath') )
> $path = realpath($path);
> if ( realpath($path) == $path )
> if ( !is_null($dest_path) and $_dest_path = realpath($dest_path) )
>
> What do you think if I disable such function?
It is more likely a cache problem. Fix your realpath_cache settings
like I suggested.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Performance problem with php
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 the parent paths may not be accessible, check open base dir, etc. It can resolve links too while being at it. cheers, -- 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
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, ...}) =
0
[pid 13792] lstat("/usr/local/sitipersonali", {st_mode=S_IFDIR|0755,
st_size=4096, ...}) = 0
[pid 13792] lstat("/usr/local/sitipersonali/sitipersonali08",
{st_mode=S_IFDIR|0777, st_size=1024, ...}) = 0
[pid 13792] lstat("/usr/local/sitipersonali/sitipersonali08/NSP",
{st_mode=S_IFDIR|0755, st_size=13312, ...}) = 0
[pid 13792] lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa",
{st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
[pid 13792] lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al",
{st_mode=S_IFDIR|0755, st_size=80, ...}) = 0
[pid 13792] lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall",
{st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
[pid 13792]
lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall/webspace",
{st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
[pid 13792]
lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall/webspace/siteapps",
{st_mode=S_IFDIR|0750, st_size=1024, ...}) = 0
[pid 13792]
lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall/webspace/siteapps/21451",
{st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
[pid 13792]
lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall/webspace/siteapps/21451/htdocs",
{st_mode=S_IFDIR|0755, st_size=2048, ...}) = 0
[pid 13792]
lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall/webspace/siteapps/21451/htdocs/wp-blog-header.php",
{st_mode=S_IFREG|0644, st_size=274, ...}) = 0
--
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
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 httpd.
Again when I tried to strace the site I see same behavior:
[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, ...}) = 0
[pid 13792] lstat("/usr/local/sitipersonali", {st_mode=S_IFDIR|0755,
st_size=4096, ...}) = 0
[pid 13792] lstat("/usr/local/sitipersonali/sitipersonali08",
{st_mode=S_IFDIR|0777, st_size=1024, ...}) = 0
[pid 13792] lstat("/usr/local/sitipersonali/sitipersonali08/NSP",
{st_mode=S_IFDIR|0755, st_size=13312, ...}) = 0
[pid 13792] lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa",
{st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
[pid 13792] lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al",
{st_mode=S_IFDIR|0755, st_size=80, ...}) = 0
[pid 13792] lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall",
{st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
[pid 13792]
lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall/webspace",
{st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
[pid 13792]
lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall/webspace/siteapps",
{st_mode=S_IFDIR|0750, st_size=1024, ...}) = 0
[pid 13792]
lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall/webspace/siteapps/21451",
{st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
[pid 13792]
lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall/webspace/siteapps/21451/htdocs",
{st_mode=S_IFDIR|0755, st_size=2048, ...}) = 0
[pid 13792]
lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall/webspace/siteapps/21451/htdocs/wp-blog-header.php",
{st_mode=S_IFREG|0644, st_size=274, ...}) = 0
[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, ...}) = 0
[pid 13792] lstat("/usr/local/sitipersonali", {st_mode=S_IFDIR|0755,
st_size=4096, ...}) = 0
[pid 13792] lstat("/usr/local/sitipersonali/sitipersonali08",
{st_mode=S_IFDIR|0777, st_size=1024, ...}) = 0
[pid 13792] lstat("/usr/local/sitipersonali/sitipersonali08/NSP",
{st_mode=S_IFDIR|0755, st_size=13312, ...}) = 0
[pid 13792] lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa",
{st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
[pid 13792] lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al",
{st_mode=S_IFDIR|0755, st_size=80, ...}) = 0
[pid 13792] lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall",
{st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
[pid 13792]
lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall/webspace",
{st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
[pid 13792]
lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall/webspace/siteapps",
{st_mode=S_IFDIR|0750, st_size=1024, ...}) = 0
[pid 13792]
lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall/webspace/siteapps/21451",
{st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
[pid 13792]
lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall/webspace/siteapps/21451/htdocs",
{st_mode=S_IFDIR|0755, st_size=2048, ...}) = 0
[pid 13792]
lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall/webspace/siteapps/21451/htdocs/wp-blog-header.php",
{st_mode=S_IFREG|0644, st_size=274, ...}) = 0
[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, ...}) = 0
[pid 13792] lstat("/usr/local/sitipersonali", {st_mode=S_IFDIR|0755,
st_size=4096, ...}) = 0
[pid 13792] lstat("/usr/local/sitipersonali/sitipersonali08",
{st_mode=S_IFDIR|0777, st_size=1024, ...}) = 0
[pid 13792] lstat("/usr/local/sitipersonali/sitipersonali08/NSP",
{st_mode=S_IFDIR|0755, st_size=13312, ...}) = 0
[pid 13792] lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa",
{st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
[pid 13792] lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al",
{st_mode=S_IFDIR|0755, st_size=80, ...}) = 0
[pid 13792] lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall",
{st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
[pid 13792]
lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall/webspace",
{st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
[pid 13792]
lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall/webspace/siteapps",
{st_mode=S_IFDIR|0750, st_size=1024, ...}) = 0
[pid 13792]
getcwd("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall/webspace/siteapps/21451/htdocs"...,
4096) = 87
[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, ...}) = 0
[pid 13792] lstat("/usr/local/sitipersonali", {st_mode=S_IFDIR|0755,
st_size=4096, ...}) = 0
[
Re: [PHP-DEV] Performance problem with php
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
>
> 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 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
>> > 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 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 page.
>> >>
>> >> In this particular case apache httpd servers tries 8 times before reach
>> >> and
>> >> read the file (if you want I can send the complete strace output)
>> >> More strange all these tentative seems to be correctly completed
>> because
>> >> of
>> >> success (0) return code for each line.
>> >> Ffor every file should be served by apache httpd, apache httpd tries to
>> >> lstat all directory in path more times:
>> >>
>> >> lstat("/usr", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
>> >> lstat("/usr/local", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
>> >> lstat("/usr/local/sitipersonali", {st_mode=S_IFDIR|0755, st_size=4096,
>> >> ...})
>> >> = 0
>> >> lstat("/usr/local/sitipersonali/sitipersonali08",
>> {st_mode=S_IFDIR|0777,
>> >> st_size=1024, ...}) = 0
>> >> lstat("/usr/local/sitipersonali/sitipersonali08/NSP",
>> >> {st_mode=S_IFDIR|0755,
>> >> st_size=13312, ...}) = 0
>> >> lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa",
>> >> {st_mode=S_IFDIR|0755, st_size=80, ...}) = 0
>> >> lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al",
>> >> {st_mode=S_IFDIR|0755, st_size=80, ...}) = 0
>> >> lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall",
>> >> {st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
>> >>
>> lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall/webspace",
>> >> {st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
>> >>
>> >>
>> lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall/webspace/siteapps",
>> >> {st_mode=S_IFDIR|0750, st_size=1024, ...}) = 0
>> >>
>> >>
>> lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall/webspace/siteapps/21451",
>> >> {st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
>> >>
>> >>
>> lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall/webspace/siteapps/21451/htdocs",
>> >> {st_mode=S_IFDIR|0755, st_size=2048, ...}) = 0
>> >>
>> >>
>> lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall/webspace/siteapps/21451/htdocs/wp-content",
>> >> {st_mode=S_IFDIR|0777, st_size=1024, ...}) = 0
>> >>
>> >>
>> lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall/webspace/siteapps/21451/htdocs/wp-content/languages",
>> >> {st_mode=S_IFDIR|0777, st_size=1024, ...}) = 0
>> >>
>> >>
>> lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall/webspace/siteapps/21451/htdocs/wp-content/languages/zh_CN.php",
>> >> {st_mode=S_IFREG|0777, st_size=1312, ...}) = 0
>> >>
>> >> *FIRST TENTATIVE*
>> >>
>> >> lstat("/usr", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
>> >> lstat("/usr/local", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
>> >> lstat("/usr/local/sitipersonali", {st_mode=S_IFDIR|0755, st_size=4096,
>> >> ...})
>> >> = 0
>> >> lstat("/usr/local/sitipersonali/sitipersonali08",
>> {st_mode=S_IFDIR|0777,
>> >> st_size=1024, ...}) = 0
>> >> lstat("/usr/local/sitipersonali/sitipersonali08/NSP",
>> >> {st_mode=S_IFDIR|0755,
>> >> st_size=13312, ...}) = 0
>> >> lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa",
>> >> {st_mode=S_IFDIR|0755, st_size=80, ...}) = 0
>> >> lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al",
>> >> {st_mode=S_IFDIR|0755, st_size=80, ...}) = 0
>> >> lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall",
>> >> {st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
>> >>
>> lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall/webspace",
>> >> {st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
>> >>
>> >>
>> lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall/webspace/siteapps",
>> >> {st_mode=S_IFDIR|0750, st_size=1024, ...}) = 0
>> >>
>> >>
>> lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall/webspace/siteapps/21451",
>> >> {st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
Re: [PHP-DEV] Performance problem with php
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);
if ( realpath($path) == $path )
if ( !is_null($dest_path) and $_dest_path = realpath($dest_path) )
What do you think if I disable such function?
Best regards,
Vincenzo
On Sun, Jun 20, 2010 at 3:37 PM, Rasmus Lerdorf wrote:
> 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
> code. A single call to realpath() would cause that tree of stat calls
> you see. Also, you might be overflowing your realpath cache. PHP 5.2
> is not using the cache very efficiently. This is fixed in 5.3. But try
> increasing your cache ttl and the size as well. eg.
>
> realpath_cache_size = 256k
> realpath_cache_ttl = 7200
>
> -Rasmus
>
--
Vincenzo D'Amore
email: v.dam...@gmail.com
msn: free...@hotmail.com
skype: free.dev
mobile: +39 349 8513251
Re: [PHP-DEV] APC in trunk
Am 21.06.2010 13:05, schrieb Rob Richards: > It was already agreed to include it into 6 before so why the need for > another vote on this just because its a new trunk? Also eludes me :-) -- Sebastian BergmannCo-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
I would like to know why a third party can develop a better (or more agile?) cache than the core php devs. I would think that if anyone can align it nicely especially when writing the core code itself and could also think about "this is a great place for apc to hook in" or something. It's obvious due to the strong feelings that this is a controversial point due to how well other options work. As a user myself I have to ask "why can't there be one that encompasses all the best of all of them" On Jun 21, 2010, at 5:50 AM, Antony Dovgal wrote: > On 06/21/2010 04:32 PM, Jim Jagielski wrote: >> As a PHP user, when moving to PHP 5.3, from 5.2 I had the question >> regarding which accel to use (I had been using APC). From most >> of what I read, APC was not compatible and looking at the APC site, >> the last 'stable' release was ~2years ago with a bunch of betas. I >> then looked at XCache and saw that it was "more maintained" as well >> as explicitly mentioned PHP 5.3 compatibility. >> >> In other words, to the unwashed masses, XCache, for example, >> seemed a "better" and "safer" choice than APC, despite the >> list of names attached to the latter. > > We've been experiencing some troubles with APC + 5.3, too, > so I tried switching to XCache and my experience is described here: > http://xcache.lighttpd.net/ticket/240 > Judging by XCache SVN, there were no changes since then. > > So we're still using APC + 5.3 in production, even though > I get a core now and then (weird, last segfault was ~2 weeks ago..). > > -- > Wbr, > Antony Dovgal > --- > http://pinba.org - realtime statistics for PHP > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Performance problem with php
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 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
> > 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 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 page.
> >>
> >> In this particular case apache httpd servers tries 8 times before reach
> >> and
> >> read the file (if you want I can send the complete strace output)
> >> More strange all these tentative seems to be correctly completed because
> >> of
> >> success (0) return code for each line.
> >> Ffor every file should be served by apache httpd, apache httpd tries to
> >> lstat all directory in path more times:
> >>
> >> lstat("/usr", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> >> lstat("/usr/local", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> >> lstat("/usr/local/sitipersonali", {st_mode=S_IFDIR|0755, st_size=4096,
> >> ...})
> >> = 0
> >> lstat("/usr/local/sitipersonali/sitipersonali08", {st_mode=S_IFDIR|0777,
> >> st_size=1024, ...}) = 0
> >> lstat("/usr/local/sitipersonali/sitipersonali08/NSP",
> >> {st_mode=S_IFDIR|0755,
> >> st_size=13312, ...}) = 0
> >> lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa",
> >> {st_mode=S_IFDIR|0755, st_size=80, ...}) = 0
> >> lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al",
> >> {st_mode=S_IFDIR|0755, st_size=80, ...}) = 0
> >> lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall",
> >> {st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
> >>
> lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall/webspace",
> >> {st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
> >>
> >>
> lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall/webspace/siteapps",
> >> {st_mode=S_IFDIR|0750, st_size=1024, ...}) = 0
> >>
> >>
> lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall/webspace/siteapps/21451",
> >> {st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
> >>
> >>
> lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall/webspace/siteapps/21451/htdocs",
> >> {st_mode=S_IFDIR|0755, st_size=2048, ...}) = 0
> >>
> >>
> lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall/webspace/siteapps/21451/htdocs/wp-content",
> >> {st_mode=S_IFDIR|0777, st_size=1024, ...}) = 0
> >>
> >>
> lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall/webspace/siteapps/21451/htdocs/wp-content/languages",
> >> {st_mode=S_IFDIR|0777, st_size=1024, ...}) = 0
> >>
> >>
> lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall/webspace/siteapps/21451/htdocs/wp-content/languages/zh_CN.php",
> >> {st_mode=S_IFREG|0777, st_size=1312, ...}) = 0
> >>
> >> *FIRST TENTATIVE*
> >>
> >> lstat("/usr", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> >> lstat("/usr/local", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> >> lstat("/usr/local/sitipersonali", {st_mode=S_IFDIR|0755, st_size=4096,
> >> ...})
> >> = 0
> >> lstat("/usr/local/sitipersonali/sitipersonali08", {st_mode=S_IFDIR|0777,
> >> st_size=1024, ...}) = 0
> >> lstat("/usr/local/sitipersonali/sitipersonali08/NSP",
> >> {st_mode=S_IFDIR|0755,
> >> st_size=13312, ...}) = 0
> >> lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa",
> >> {st_mode=S_IFDIR|0755, st_size=80, ...}) = 0
> >> lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al",
> >> {st_mode=S_IFDIR|0755, st_size=80, ...}) = 0
> >> lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall",
> >> {st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
> >>
> lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall/webspace",
> >> {st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
> >>
> >>
> lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall/webspace/siteapps",
> >> {st_mode=S_IFDIR|0750, st_size=1024, ...}) = 0
> >>
> >>
> lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall/webspace/siteapps/21451",
> >> {st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
> >>
> >>
> lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall/webspace/siteapps/21451/htdocs",
> >> {st_mode=S_IFDIR|0755, st_size=2048, ...}) = 0
> >>
> >>
> lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall/webspace/siteapps/21451/
Re: [PHP-DEV] Performance problem with php
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
> 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 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 page.
>>
>> In this particular case apache httpd servers tries 8 times before reach
>> and
>> read the file (if you want I can send the complete strace output)
>> More strange all these tentative seems to be correctly completed because
>> of
>> success (0) return code for each line.
>> Ffor every file should be served by apache httpd, apache httpd tries to
>> lstat all directory in path more times:
>>
>> lstat("/usr", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
>> lstat("/usr/local", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
>> lstat("/usr/local/sitipersonali", {st_mode=S_IFDIR|0755, st_size=4096,
>> ...})
>> = 0
>> lstat("/usr/local/sitipersonali/sitipersonali08", {st_mode=S_IFDIR|0777,
>> st_size=1024, ...}) = 0
>> lstat("/usr/local/sitipersonali/sitipersonali08/NSP",
>> {st_mode=S_IFDIR|0755,
>> st_size=13312, ...}) = 0
>> lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa",
>> {st_mode=S_IFDIR|0755, st_size=80, ...}) = 0
>> lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al",
>> {st_mode=S_IFDIR|0755, st_size=80, ...}) = 0
>> lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall",
>> {st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
>> lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall/webspace",
>> {st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
>>
>> lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall/webspace/siteapps",
>> {st_mode=S_IFDIR|0750, st_size=1024, ...}) = 0
>>
>> lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall/webspace/siteapps/21451",
>> {st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
>>
>> lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall/webspace/siteapps/21451/htdocs",
>> {st_mode=S_IFDIR|0755, st_size=2048, ...}) = 0
>>
>> lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall/webspace/siteapps/21451/htdocs/wp-content",
>> {st_mode=S_IFDIR|0777, st_size=1024, ...}) = 0
>>
>> lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall/webspace/siteapps/21451/htdocs/wp-content/languages",
>> {st_mode=S_IFDIR|0777, st_size=1024, ...}) = 0
>>
>> lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall/webspace/siteapps/21451/htdocs/wp-content/languages/zh_CN.php",
>> {st_mode=S_IFREG|0777, st_size=1312, ...}) = 0
>>
>> *FIRST TENTATIVE*
>>
>> lstat("/usr", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
>> lstat("/usr/local", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
>> lstat("/usr/local/sitipersonali", {st_mode=S_IFDIR|0755, st_size=4096,
>> ...})
>> = 0
>> lstat("/usr/local/sitipersonali/sitipersonali08", {st_mode=S_IFDIR|0777,
>> st_size=1024, ...}) = 0
>> lstat("/usr/local/sitipersonali/sitipersonali08/NSP",
>> {st_mode=S_IFDIR|0755,
>> st_size=13312, ...}) = 0
>> lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa",
>> {st_mode=S_IFDIR|0755, st_size=80, ...}) = 0
>> lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al",
>> {st_mode=S_IFDIR|0755, st_size=80, ...}) = 0
>> lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall",
>> {st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
>> lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall/webspace",
>> {st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
>>
>> lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall/webspace/siteapps",
>> {st_mode=S_IFDIR|0750, st_size=1024, ...}) = 0
>>
>> lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall/webspace/siteapps/21451",
>> {st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
>>
>> lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall/webspace/siteapps/21451/htdocs",
>> {st_mode=S_IFDIR|0755, st_size=2048, ...}) = 0
>>
>> lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall/webspace/siteapps/21451/htdocs/wp-content",
>> {st_mode=S_IFDIR|0777, st_size=1024, ...}) = 0
>>
>> lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall/webspace/siteapps/21451/htdocs/wp-content/languages",
>> {st_mode=S_IFDIR|0777, st_size=1024, ...}) = 0
>>
>> lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall/webspace/siteapps/21451/htdocs/wp-content/languages/zh_CN.php",
>> {st_mode=S_IFREG|0777, st_size=1312, ...}) = 0
>>
>> *SECOND*
>>
>> lstat("/
Re: [PHP-DEV] APC in trunk
On 06/21/2010 04:32 PM, Jim Jagielski wrote: > As a PHP user, when moving to PHP 5.3, from 5.2 I had the question > regarding which accel to use (I had been using APC). From most > of what I read, APC was not compatible and looking at the APC site, > the last 'stable' release was ~2years ago with a bunch of betas. I > then looked at XCache and saw that it was "more maintained" as well > as explicitly mentioned PHP 5.3 compatibility. > > In other words, to the unwashed masses, XCache, for example, > seemed a "better" and "safer" choice than APC, despite the > list of names attached to the latter. We've been experiencing some troubles with APC + 5.3, too, so I tried switching to XCache and my experience is described here: http://xcache.lighttpd.net/ticket/240 Judging by XCache SVN, there were no changes since then. So we're still using APC + 5.3 in production, even though I get a core now and then (weird, last segfault was ~2 weeks ago..). -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
On Sun, Jun 20, 2010 at 11:39:30PM -0400, Ilia Alshanetsky wrote: > Stas, > > If there is a better alternative to APC we can bundle with PHP, I am > definitely open to exploring that idea. However the alternatives I am > familiar either are closed source or have licences incompatible with > PHP, and that's without getting into the "better" argument. > As a PHP user, when moving to PHP 5.3, from 5.2 I had the question regarding which accel to use (I had been using APC). From most of what I read, APC was not compatible and looking at the APC site, the last 'stable' release was ~2years ago with a bunch of betas. I then looked at XCache and saw that it was "more maintained" as well as explicitly mentioned PHP 5.3 compatibility. In other words, to the unwashed masses, XCache, for example, seemed a "better" and "safer" choice than APC, despite the list of names attached to the latter. Certainly I would have preferred staying with APC but it sure seemed like it was a side project that people just lost interest in... Moving it to be an actual *part* of PHP would go a LNG way in showing others that APC is a serious codebase again. -- === Jim Jagielski [|] j...@jagunet.com [|] http://www.jaguNET.com/ "Great is the guilt of an unnecessary war" ~ John Adams -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
>> Competition between opcode caches for php will definitely be reduced by >> adding APC into the core, >> so the market will shrink, of course. > > > i think this is a likely outcome indeed. it might also be phrased in a > more > positive tone in that likely efforts will be joined. for example maybe > zend > will decide to contribute some of their code to APC. my poor english does not allow me to impress it clearly that my tone is as positive as possible :) > so the key question might be more is there something in APC that makes > it fundamentally the right or wrong approach. Is there any possibility for you or anybody else to run all php standard tests under Apache + php with and without APC to see how many among them are broken with APC? Please don't forget to run tests TWICE under APC because on the first run it does not use the cached opcodes. > furthermore does adding any byte code cache to core also enable new kinds > of optimizations > because its now possible to more tightly integrate with core? I'd think of tightly integrated opcode serializer/deserializer and it's what can be highly optimized after adding into the core. This approach would be much cleaner, indeed. -jv -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
Ilia Alshanetsky wrote: On windows it is even easier, just don't load the dll file, most extensions other then PCRE (?) are compiled as modules anyway... APC would be no different, and I would go as far as saying that on Win32 Wincache is probably a better choice. As long as these are added as loadable extensions then that is not a problem. The windows builds do bundle some things RATHER than adding everything as extensions, and it is that which I am probably flagging up. So as long as I can pick and choise which extensions are shipped with a windows build I'm happy. If it IS an extension that can be left out, then it should not be enabled by default anyway? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
On 19 June 2010 14:23, Kalle Sommer Nielsen wrote: > What are your views on including APC in the core, or reasons not to? +1 Added to core -1 Enabled by default If APC is not as stable on Windows as required _AND_ licensing issues are resolvable, could WinCache for Windows be an option? That is added to code but not enabled? -- - Richard Quadling "Standing on the shoulders of some very clever giants!" EE : http://www.experts-exchange.com/M_248814.html EE4Free : http://www.experts-exchange.com/becomeAnExpert.jsp Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 ZOPA : http://uk.zopa.com/member/RQuadling -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
On 21.06.2010, at 13:07, jvlad wrote: > Competition between opcode caches for php will definitely be reduced by > adding APC into the core, > so the market will shrink, of course. i think this is a likely outcome indeed. it might also be phrased in a more positive tone in that likely efforts will be joined. for example maybe zend will decide to contribute some of their code to APC. so the key question might be more is there something in APC that makes it fundamentally the right or wrong approach. furthermore does adding any byte code cache to core also enable new kinds of optimizations because its now possible to more tightly integrate with core? regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: APC in trunk
On 2010-06-19, Kalle Sommer Nielsen wrote: > Greetings > What are your views on including APC in the core, or reasons not to? +1 moving it into core -1 enabling by default -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
Same here. +1 to bundle -1 to enable it by default On 21 Jun 2010 13:05, "Rob Richards" wrote: Ilia Alshanetsky wrote: > > I for one think it is a really good idea, there is no compelling > reaso... +1 for including APC -1 for enabling by default It was already agreed to include it into 6 before so why the need for another vote on this just because its a new trunk? Rob -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub...
Re: [PHP-DEV] APC in trunk
>> Then is there any reason not to add all code compatible in php license >> terms >> into php core? > > What are you talking about? Who said that we have to add any php > licensed code to the core? I only said that the license is a critical > part of the decision. Nothing else. APC can be added, this fact does not mean that it should be added. So the license compatibility argument is neutral for adding or not adding APC. >> This approach will only reduce competition and will shrink the market. > > As of now the only competitor actually reducing competition is Zend > (no offense meant to the Zend guys), and the reasons are not technical > but marketing related. I don't think we can do anything like that or > anything against that. I didn't see any attempts from Zend to add NOT REQUIRED PHP MODULES into the core. They are going by a clear way and their efforts can't be underestimated. As I see they are changing the core in a right way: check for example zend_vm_xxx added in 5.1, check the proposed and implemented improvements in memory management etc. This all makes php position on the market stronger, so the competition between php and the other web-languages is NOT reduced by Zend efforts. Competition between opcode caches for php will definitely be reduced by adding APC into the core, so the market will shrink, of course. What can be further done for php performance improvements (if you care of it at all) is garbage collector, copy-on-write, and possibly jit compiler for some platforms. These techniques will put php on par with the best propriatary languages available for the web, or may be will make php even better. Meanwhile the benefit comming with php is a balance between cost, features, and stability. Don't break it. As of adding APC into the core, I expect more problems to come and nothing would be solved. -jv -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
Ilia Alshanetsky wrote: I for one think it is a really good idea, there is no compelling reason not to include APC, I would even go as far as say we should enable it by default. +1 +1 for including APC -1 for enabling by default It was already agreed to include it into 6 before so why the need for another vote on this just because its a new trunk? Rob -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
On windows it is even easier, just don't load the dll file, most extensions other then PCRE (?) are compiled as modules anyway... APC would be no different, and I would go as far as saying that on Win32 Wincache is probably a better choice. On Mon, Jun 21, 2010 at 2:15 AM, Lester Caine wrote: > Ilia Alshanetsky wrote: >> >> The test was done on Windows... I never said it was IIS only, it is >> however >> win32 only. > > Sorry - Most people using it will no have bought win64 yet was the point and > the > test was done on win32 as far as I can tell. Anyway Pierre keeps saying that > 64 bit is slower anyway ;) > >> All extensions can be disabled by the user compiling the code... > > On Linux that is fine, but on Windows? We keep having this debate on what is > compiled into windows builds and what is optional and that is the point > here. Although the increase in third party sites providing more flexible > windows builds is probably the way ahead. > > -- > Lester Caine - G8HFL > - > Contact - http://lsces.co.uk/wiki/?page=contact > L.S.Caine Electronic Services - http://lsces.co.uk > EnquirySolve - http://enquirysolve.com/ > Model Engineers Digital Workshop - http://medw.co.uk// > Firebird - http://www.firebirdsql.org/index.php > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
hi, On Mon, Jun 21, 2010 at 12:30 PM, jvlad wrote: >> This bug is not APC specific. >> > > In this case you can easily point out to another module suffering from this > bug, don't you? > >>> License argument does not work at all. >> >> It does, more than ever. > > Then is there any reason not to add all code compatible in php license terms > into php core? What are you talking about? Who said that we have to add any php licensed code to the core? I only said that the license is a critical part of the decision. Nothing else. > Pierre, I understand your position toward APC How can you understand something I did not even mention (if I like or not to bundle APC)? > and you won't accept any > criticism and will see only what you like to see. I do accept criticism as well, when constructive. And that's sadly not the case here, I don't see any kind of actual bugs or issues but some random complaints. My replies are only about getting the facts behind "not maintained" and "buggy". I'm still waiting for them. > This approach will only reduce competition and will shrink the market. As of now the only competitor actually reducing competition is Zend (no offense meant to the Zend guys), and the reasons are not technical but marketing related. I don't think we can do anything like that or anything against that. Cheers, -- 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] APC in trunk
> This bug is not APC specific. > In this case you can easily point out to another module suffering from this bug, don't you? >> License argument does not work at all. > > It does, more than ever. Then is there any reason not to add all code compatible in php license terms into php core? If not, what did stop from adding DBG debugger? >> But I think we have now got the idea, you don't like APC. Point made > (or at least said). > Pierre, I understand your position toward APC and you won't accept any criticism and will see only what you like to see. In fact there is nothing personal. I like APC in its current place and its role is visible to me. I am aware of APC as well as all other publicly avalable php opcode caches such as xcache, eaccelerator, phpexpress. What I don't like is the idea of providing preferences to an extension among the others playing the same role, especially taking into account that the particular extension is not the best among the others. I don't like the idea of solving marketing tasks such as increasing visibility and awareness by such manipulations like adding NOT required and poorly maintained code into the core. This approach will only reduce competition and will shrink the market. -jv -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
On Mon, Jun 21, 2010 at 11:55 AM, jvlad wrote: >>> keep on the topic pls, which is the inclusion of potentially buggy and >>> poorly maintained APC. >> >> I'm on topic. You seem to be able to fix this bug very easily, I only >> told you how to provide patches. > > I do not care of bugs in APC unless this module is NOT in php core. > If they appear in php core, I'll decide whether php is a right way for me to > go at all. This bug is not APC specific. >> APC is well maintained but all I can read from you are some random >> bashing about non APC specific bugs. > > Know what? APC is wrongly designed as a php extension which does not allow > it to catch certain things at certain time, so it is definitely bug in APC. Certain thing at certain time? Ok. > License argument does not work at all. It does, more than ever. But I think we have now got the idea, you don't like APC. Point made (or at least said). Cheers, -- 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] APC in trunk
>> keep on the topic pls, which is the inclusion of potentially buggy and >> poorly maintained APC. > > I'm on topic. You seem to be able to fix this bug very easily, I only > told you how to provide patches. I do not care of bugs in APC unless this module is NOT in php core. If they appear in php core, I'll decide whether php is a right way for me to go at all. > APC is well maintained but all I can read from you are some random > bashing about non APC specific bugs. Know what? APC is wrongly designed as a php extension which does not allow it to catch certain things at certain time, so it is definitely bug in APC. The fact that the other opcode caches do not suffer from this bug being installed as zend extension only prove that the bug is in APC and it is poory maintained. > APC is the only opcode cache available at php.net and under a very > permissive license (aka PHP's). You may like other options more than > APC but that's definitively not arguments against APC. License argument does not work at all. Many years ago the first php debugger DBG was released under PHP license but it didn't allow Rasmus and Zeev to merge it into the core even though the formal request was published on php.internals. What was changed since that, Pierre? Or the extension author/maintainer should be only Rasmus and Zeev to get it into the core? > If you have specific issues with APC or specific cases to show how APC > is poorly maintained, then please raise them. Try to understand the arguments above. -jv -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
On Mon, Jun 21, 2010 at 11:31 AM, jvlad wrote: > keep on the topic pls, which is the inclusion of potentially buggy and > poorly maintained APC. I'm on topic. You seem to be able to fix this bug very easily, I only told you how to provide patches. APC is well maintained but all I can read from you are some random bashing about non APC specific bugs. APC is the only opcode cache available at php.net and under a very permissive license (aka PHP's). You may like other options more than APC but that's definitively not arguments against APC. If you have specific issues with APC or specific cases to show how APC is poorly maintained, then please raise them. Cheers, -- 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] APC in trunk
>>> >>> By the way, including APC in the core is actually likely to fix this >>> problem because it has to do with the order the rshutdown functions are >>> called. Read Christian's excellent description of the problem here: >>> >>> http://news.php.net/php.internals/46999 >>> >>> -Rasmus >> >> concerting http://news.php.net/php.internals/46999 >> If APC is that well-maintained as many people impressed here, why this >> rather simple bug is still not fixed during the year? > >Thanks to volunteer to fix this bug. Please attach patch to the bug report. keep on the topic pls, which is the inclusion of potentially buggy and poorly maintained APC. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
>> This is an unfixed PHP bug. There have been a number of threads about >> the object destruction order on internals. It isn't just APC that is >> affected by this. Other extensions are affected as well. > > I understand that this effect is caused by the fact that APC destroys PHP > classes earlier than PHP engine otherwise would. You can claim it's a bug > but then until it's fixed enabling APC would still cause BC break, and no > amount of renaming this fact would change it. > If we can fix it and make it work properly - fine, then this ojection > ceases to exist as soon as it's done, if there's no more cases when APC > behaves differently. > > > I am still undecided if to enable by default, but originally > the idea was to bundle with PHP 6, and I think this type > of BC break in an edge feature (or rather edge bug) would be ok in a major > update to the language. If I get it right, the BC break will depend on whether apc is enabled or not. So, it's not major update brings the breach. -jv -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
hi, On Mon, Jun 21, 2010 at 10:58 AM, jvlad wrote: > > "Rasmus Lerdorf" wrote in message > news:4c1ed90d.2030...@lerdorf.com... >> On 6/20/10 7:44 PM, Stas Malyshev wrote: >>> Hi! >>> Can you elaborate? What "average user"-facing features are non-obvious? We should document them if nothing else. >>> >>> This recently caught my attention: >>> http://pecl.php.net/bugs/bug.php?id=16745 >>> As I understood from this bug, APC changes how PHP works (since it works >>> >> >> By the way, including APC in the core is actually likely to fix this >> problem because it has to do with the order the rshutdown functions are >> called. Read Christian's excellent description of the problem here: >> >> http://news.php.net/php.internals/46999 >> >> -Rasmus > > concerting http://news.php.net/php.internals/46999 > If APC is that well-maintained as many people impressed here, why this > rather simple bug is still not fixed during the year? Thanks to volunteer to fix this bug. Please attach patch to the bug report. Cheers, -- 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] APC in trunk
"Rasmus Lerdorf" wrote in message news:4c1ed90d.2030...@lerdorf.com... > On 6/20/10 7:44 PM, Stas Malyshev wrote: >> Hi! >> >>> Can you elaborate? What "average user"-facing features are non-obvious? >>> We should document them if nothing else. >> >> This recently caught my attention: >> http://pecl.php.net/bugs/bug.php?id=16745 >> As I understood from this bug, APC changes how PHP works (since it works >> > > By the way, including APC in the core is actually likely to fix this > problem because it has to do with the order the rshutdown functions are > called. Read Christian's excellent description of the problem here: > > http://news.php.net/php.internals/46999 > > -Rasmus concerting http://news.php.net/php.internals/46999 If APC is that well-maintained as many people impressed here, why this rather simple bug is still not fixed during the year? Why the other php opcode caches do NOT impose similar problems? Isn't it yet another reason not to add APC into the core? Doesn't it plainly show that there is no benefits from the fact that people behind APC are known? -jv -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] TestFest 2010 News Announcement.
So.. Commit? :) -Hannes On Sun, Jun 6, 2010 at 05:05, Eric Stewart wrote: > Wrote up and attempted to commit a news announcement for TestFest 2010, only > to find out I don't have karma for that section of the repository. I've > attached the entry XML file if someone would be kind enough to commit it for > me. > Thanks, > Eric Lee Stewart > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
> > "Ilia Alshanetsky" wrote in message > news:aanlktilzlbbfucuv-jtmkm-qljl1il7wsqy0fyhn3...@mail.gmail.com... > Including into core of PHP has no impact on other opcode caches, if > they do a better job then APC, people can definitely (and should) use > them. The main purpose of including APC would be to raise the level of > awareness PHP users to the fact opcode caches exist and should be used > in virtually all instances where PHP is used. > > Most people do not use opcode, I know it from asking that question at > just about every conference. As if you do a google query searching for > phpinfo() and try to find those with any cache, you'll see that there > are FAR fewer of those then those without any caching being enabled. > > Just because APC package exists on most linux and BSD distros does not > mean people know what it is, you have lots of extensions that are > available as packages... > > How is adding an extension forcing anyone to use, dba extension has > been in core in ages, and only people who choose to use it do... "in > core" does not mean that you must use it. Obviously, the target should not and could not be to just improve the awareness of opcode caches. If you want to improve the awareness, there are many ways that would leave all competing caches under the same equal conditions. For example, add a table on pecl.php.net: ten most popular pecl extensions and duplicate it on php.net. As soon as APC appeared there, it will be seen and all people will be aware. If people behind XCache or eAccelerator decide to move in this direction, they would make the license compatible and bring their code into pecl. Isn't it a right way amongst many other right ways? How would a disabled and potentially even not installed php extension affect awareness? In fact, you can add APC into trunk and you can remove it, nothing will change on a particular platform until the OS vendor (like RedHat) will move or remove the module into/from php package, and what they will do is not that obvious. Try to talk to them first: are they ready for the change? Adding APC into trunk makes it preferrable while the choise is based on the fact that one of the people behind APC is the php creator. After all, I'd love to see Zend's people opinion posted on this thread. In particular Zeev's and/or Andi's. Dmitry should be listened too. You didn't answer to the question about problems with further php mainentability. How the releases process of PHP will be changed? What will be done in order to keep APC as bug-free as PHP CORE which functionality APC affects. -jv -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
On Mon, Jun 21, 2010 at 8:15 AM, Lester Caine wrote: > Ilia Alshanetsky wrote: >> >> The test was done on Windows... I never said it was IIS only, it is >> however >> win32 only. > > Sorry - Most people using it will no have bought win64 yet was the point and > the > test was done on win32 as far as I can tell. Anyway Pierre keeps saying that > 64 bit is slower anyway ;) What I say is something else: We do not support win64 for production use, yet. No matter what you think. Secondly, Microsoft recommendation for win64 is IIS 64bit with 32bit SAPI (FasftCGI here). And yes, 64bit has no benefit now and can be slower. Now, keep on the topic pls, which is the inclusion of APC. -- 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] APC in trunk
2010/6/21 Sebastian Bergmann : > Am 20.06.2010 20:21, schrieb Ilia Alshanetsky: >> I for one think it is a really good idea, there is no compelling >> reason not to include APC, I would even go as far as say we should >> enable it by default. > > +1 for bundling > +1 for removing the "layer of checks for macros" for PHP <= 5.4 > +1 for building it by default > -1 for enabling it by default Double those votes! Patrick > -- > Sebastian Bergmann Co-Founder and Principal Consultant > http://sebastian-bergmann.de/ http://thePHP.cc/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
Am 21.06.2010 09:33, schrieb Ferenc Kovacs: > What's the problem with moo? You are not seriously asking that question, are you? -- Sebastian BergmannCo-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
On 21.06.2010, at 05:32, Stas Malyshev wrote: > Hi! > >> This is an unfixed PHP bug. There have been a number of threads about >> the object destruction order on internals. It isn't just APC that is >> affected by this. Other extensions are affected as well. > > I understand that this effect is caused by the fact that APC destroys PHP > classes earlier than PHP engine otherwise would. You can claim it's a bug but > then until it's fixed enabling APC would still cause BC break, and no amount > of renaming this fact would change it. > If we can fix it and make it work properly - fine, then this ojection ceases > to exist as soon as it's done, if there's no more cases when APC behaves > differently. I am still undecided if to enable by default, but originally the idea was to bundle with PHP 6, and I think this type of BC break in an edge feature (or rather edge bug) would be ok in a major update to the language. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
What's the problem with moo? Tyrael On Mon, Jun 21, 2010 at 8:49 AM, Sebastian Bergmann < s...@sebastian-bergmann.de> wrote: > Am 20.06.2010 23:07, schrieb Rasmus Lerdorf: > > No, it is not enough to just have source code. The developers need to > > play along as well. > > Which reminds me: does anybody actually know who develops xcache? Last > time I checked the answer I found was: moo. > > -- > Sebastian BergmannCo-Founder and Principal Consultant > http://sebastian-bergmann.de/ http://thePHP.cc/ > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
