Re: [PHP-DEV] APC in trunk
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
Re: [PHP-DEV] APC in trunk
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 -- 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 Jun 20, 2010, at 10:06 PM, Rasmus Lerdorf wrote: > On 6/20/10 7:55 PM, Scott MacVicar wrote: >> >> On Jun 20, 2010, at 11:21 AM, 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 >> >> We'd need to get http://wiki.php.net/rfc/zendsignals committed before we >> even get it in the core. >> >> At the moment if the script gets killed while the cache was being cleaned it >> up it never unlocks it and your server is essentially dead. > > Depends on the locking mechanism. As long as you have owner-death > protection in your lock, you are fine for this particular problem. > shire's patch was fine, I think the only thing missing from it was Windows support though tbh its no worse than what is there before. - S -- 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: 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
Re: [PHP-DEV] APC in trunk
On 06/20/2010 10:21 PM, 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 on adding into the distro -1 on enabling by default -- 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 6/20/10 7:55 PM, Scott MacVicar wrote: > > On Jun 20, 2010, at 11:21 AM, 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 > > We'd need to get http://wiki.php.net/rfc/zendsignals committed before we even > get it in the core. > > At the moment if the script gets killed while the cache was being cleaned it > up it never unlocks it and your server is essentially dead. Depends on the locking mechanism. As long as you have owner-death protection in your lock, you are fine for this particular problem. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
On Jun 20, 2010, at 11:21 AM, 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 We'd need to get http://wiki.php.net/rfc/zendsignals committed before we even get it in the core. At the moment if the script gets killed while the cache was being cleaned it up it never unlocks it and your server is essentially dead. - S -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
Hi! 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. I don't know any better one, but this is not what I am talking about. I am talking about enabling it by default - and I'm saying it seems to me dangerous now. That doesn't mean APC is worse than something else - it just means something enabled by default in PHP has (or should have) higher requirements than something that'd be compiled by people that need it when they need it - as it happens now. I don't see a pressing need to have some bytecode cache enabled by default in any build of PHP. -- 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] APC in trunk
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. On Sun, Jun 20, 2010 at 11:31 PM, Stas Malyshev wrote: > Hi! > >> The point is that it would be there for people to use, with as little >> effort as possible, which would be changing 1 byte inside the INI >> file. The issues APC is having with certain code is not specific to >> APC, and does happen with other open source caches. Perhaps we need to > > We don't discuss putting other OSS (or non-OSS for that matter :) caches in > any PHP build, enabled by default, do we? That's the point. > And really, enabling extension - either in source build or in binary build - > is not that hard. If they are able to write PHP, they should be able to > remove ; before extension= or write --enable-apc. > >> examine the validity of that code, or simply not cache the code that's >> affected. > > I'd rather not make such kludges, especially if we talk about main PHP > source. It's not a good road to take. > -- > 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] APC in trunk
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. apc.file_update_protection could have some unexpected results too. Not any that change the behaviour of PHP. Do I misunderstand how this feature works? I was under impression that it prevents APC from updating the file for X seconds since its modification - while plain PHP of course would see the change instantly. -- 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] APC in trunk
Hi! The point is that it would be there for people to use, with as little effort as possible, which would be changing 1 byte inside the INI file. The issues APC is having with certain code is not specific to APC, and does happen with other open source caches. Perhaps we need to We don't discuss putting other OSS (or non-OSS for that matter :) caches in any PHP build, enabled by default, do we? That's the point. And really, enabling extension - either in source build or in binary build - is not that hard. If they are able to write PHP, they should be able to remove ; before extension= or write --enable-apc. examine the validity of that code, or simply not cache the code that's affected. I'd rather not make such kludges, especially if we talk about main PHP source. It's not a good road to take. -- 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] APC in trunk
The point is that it would be there for people to use, with as little effort as possible, which would be changing 1 byte inside the INI file. The issues APC is having with certain code is not specific to APC, and does happen with other open source caches. Perhaps we need to examine the validity of that code, or simply not cache the code that's affected. On Sun, Jun 20, 2010 at 11:19 PM, Stas Malyshev wrote: > Hi! > >> Even if the extension is compiled by default, we can (and probably >> should) leave apc.enabled at Off, recognizing some the things you are >> mentioning. > > I'm not sure I see the point of compiling it if it's disabled. Anyway, most > of the distributions probably would make it .so just as it happens now for > tons of other modules and would enable it in .ini. And building it from > source you almost never rely on defaults anyway if you know what you want > (which is the reason why you didn't use the binary one, I guess). So, > summarily, I don't think we should enable it by default, as for compiling it > by default, I don't think it matters too much since I don't believe defaults > matter too much there. > -- > 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] APC in trunk
Hi! Even if the extension is compiled by default, we can (and probably should) leave apc.enabled at Off, recognizing some the things you are mentioning. I'm not sure I see the point of compiling it if it's disabled. Anyway, most of the distributions probably would make it .so just as it happens now for tons of other modules and would enable it in .ini. And building it from source you almost never rely on defaults anyway if you know what you want (which is the reason why you didn't use the binary one, I guess). So, summarily, I don't think we should enable it by default, as for compiling it by default, I don't think it matters too much since I don't believe defaults matter too much there. -- 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] APC in trunk
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 > without APC but not with it) and it is not considered a problem in APC. > Which means enabling APC by default is a BC break, and there's already a > proof that it breaks real-life code (even if particular code had been > changed to work with it, the fact that APC can break otherwise working > code stays). Now probably most of the experienced users wouldn't mind > fixing the code a bit, but for enabling by default it should be 100% BC. 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
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 > without APC but not with it) and it is not considered a problem in APC. > Which means enabling APC by default is a BC break, and there's already a > proof that it breaks real-life code (even if particular code had been > changed to work with it, the fact that APC can break otherwise working > code stays). Now probably most of the experienced users wouldn't mind > fixing the code a bit, but for enabling by default it should be 100% BC. 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. > apc.file_update_protection could have some unexpected results too. Not any that change the behaviour of PHP. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
Stas, Even if the extension is compiled by default, we can (and probably should) leave apc.enabled at Off, recognizing some the things you are mentioning. On Sun, Jun 20, 2010 at 10: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 > without APC but not with it) and it is not considered a problem in APC. > Which means enabling APC by default is a BC break, and there's already a > proof that it breaks real-life code (even if particular code had been > changed to work with it, the fact that APC can break otherwise working code > stays). Now probably most of the experienced users wouldn't mind fixing the > code a bit, but for enabling by default it should be 100% BC. > > apc.file_update_protection could have some unexpected results too. > -- > 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 Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
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 without APC but not with it) and it is not considered a problem in APC. Which means enabling APC by default is a BC break, and there's already a proof that it breaks real-life code (even if particular code had been changed to work with it, the fact that APC can break otherwise working code stays). Now probably most of the experienced users wouldn't mind fixing the code a bit, but for enabling by default it should be 100% BC. apc.file_update_protection could have some unexpected results too. -- 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] APC in trunk
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. On Sun, Jun 20, 2010 at 8:15 PM, jvlad wrote: > "Ilia Alshanetsky" wrote in message > news:86a0c51a-e6f7-48f2-a065-eabe74c6a...@prohost.org... >> Several reasons: >> >> 1) APC is well maintained, by the same people who work on PHP. >> >> 2) The license does not preclude it's inclusion into the base version. >> >> 3) most people don't use any opcode cashes, which is not ideal when it >> comes to PHP. >> >> 4) apc inclusion does not prevent alternatives from existing... >> >> Ilia Alshanetsky >> CIO/CSO >> Centah Inc. >> > > > Ilia, > > -the fact that APC is well maintained is not a strong argument because the > other php opcode caches are well-maintained too. > Well, better or worse, that's the question. Do you by any chance have any > numbers to compare that would prove your argument? > > -the license is compatible? Well, let's move into php core everything that > has a compatible license! So it is not an agurment either. > (the opposite would be a strong arument because nothing with incompatible > license could be added) > > -most people do not use caches? To me it's not exactly correct. Did you hear > of XAMPP or WAMPP packages for Windows? Did you check the modules they > distribute? How many opcode caches do they deliver? At least three AFAIK. > That's Windows. About BSD - did you try to compile php from ports on BSD* > alike systems? Didn't you notice APC among the options? As of Linux, APC is > a module officially included with all major distributions. What would change > for the end-user if you move APC into trunk? From these perspectives -- very > little to nothing. > > -p.4 reminds me Microsoft's policy. The next step would be to create a trick > in the API that will prevent the others from working, but APC :) > > It's my understanding that "people do not use opcode caches" not > because they don't really use it, but because you are not aware of it :) > People who are aware of opcode caches do really use them, not necessarily > "the state of art and mainentance" APC. They mostly use eaccelerator and > xcache, successors of Dmitry Stogov's turck mmcache. > Who are not aware of opcode caches won't use them anyway until you FORCE > them to use it. But you're not FORCING, right? > > If you move APC into php trunk, nothing will really change: only name of the > module would lose its *pecl* part in the name and size of sources will > increase and... > Now a bit more serious moment: > Since APC modifies behaviour of php core and it comes side-by-side with php > core (from the trunk!), it's stability can't be left over. The release > manager won't be able to release any further version of PHP without knowing > for sure that APC is still compatible with the other changes and it works, > and php works with cached opcodes, so the testers will have to run all tests > at least twice, and do this under php SAPI that works with APC using shared > memory, which is not the case if command-line php is used AFAIK. > > From these perspectives, the benefits are not sensible, while negative > impact is obvious. > > If you want people to be more aware of APC and use it more frequently, why > not to add visiblity to APC, why not to write articles, show benefits in PHP > conferences, etc. In other words, why not to go by a usual way? > > just my 2c > -jv > > PS while some people are fighting for core of their projects to be as small > as possible, php people are going by their own way: removing mysql extension > that most people are using, and replacing it with APC that a very few would > like to use... That's pity and funny. > > > > -- > 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 2010/6/21 Stas Malyshev : > Hi! > > Speaking of which - does apc work for Windows? Last time I checked (more > than a year ago) it was extremely unstable. Was it fixed? What about other > popular PHP platforms? Me and Pierre put quite some work into getting APC to perform much better on Windows, and I think its well on its way getting there. -- regards, Kalle Sommer Nielsen ka...@php.net -- 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:86a0c51a-e6f7-48f2-a065-eabe74c6a...@prohost.org... > Several reasons: > > 1) APC is well maintained, by the same people who work on PHP. > > 2) The license does not preclude it's inclusion into the base version. > > 3) most people don't use any opcode cashes, which is not ideal when it > comes to PHP. > > 4) apc inclusion does not prevent alternatives from existing... > > Ilia Alshanetsky > CIO/CSO > Centah Inc. > Ilia, -the fact that APC is well maintained is not a strong argument because the other php opcode caches are well-maintained too. Well, better or worse, that's the question. Do you by any chance have any numbers to compare that would prove your argument? -the license is compatible? Well, let's move into php core everything that has a compatible license! So it is not an agurment either. (the opposite would be a strong arument because nothing with incompatible license could be added) -most people do not use caches? To me it's not exactly correct. Did you hear of XAMPP or WAMPP packages for Windows? Did you check the modules they distribute? How many opcode caches do they deliver? At least three AFAIK. That's Windows. About BSD - did you try to compile php from ports on BSD* alike systems? Didn't you notice APC among the options? As of Linux, APC is a module officially included with all major distributions. What would change for the end-user if you move APC into trunk? From these perspectives -- very little to nothing. -p.4 reminds me Microsoft's policy. The next step would be to create a trick in the API that will prevent the others from working, but APC :) It's my understanding that "people do not use opcode caches" not because they don't really use it, but because you are not aware of it :) People who are aware of opcode caches do really use them, not necessarily "the state of art and mainentance" APC. They mostly use eaccelerator and xcache, successors of Dmitry Stogov's turck mmcache. Who are not aware of opcode caches won't use them anyway until you FORCE them to use it. But you're not FORCING, right? If you move APC into php trunk, nothing will really change: only name of the module would lose its *pecl* part in the name and size of sources will increase and... Now a bit more serious moment: Since APC modifies behaviour of php core and it comes side-by-side with php core (from the trunk!), it's stability can't be left over. The release manager won't be able to release any further version of PHP without knowing for sure that APC is still compatible with the other changes and it works, and php works with cached opcodes, so the testers will have to run all tests at least twice, and do this under php SAPI that works with APC using shared memory, which is not the case if command-line php is used AFAIK. >From these perspectives, the benefits are not sensible, while negative impact is obvious. If you want people to be more aware of APC and use it more frequently, why not to add visiblity to APC, why not to write articles, show benefits in PHP conferences, etc. In other words, why not to go by a usual way? just my 2c -jv PS while some people are fighting for core of their projects to be as small as possible, php people are going by their own way: removing mysql extension that most people are using, and replacing it with APC that a very few would like to use... That's pity and funny. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
On 6/20/10 2:32 PM, Lester Caine wrote: > Rasmus Lerdorf wrote: >> On 6/20/10 2:05 PM, Lester Caine wrote: >>> Rasmus Lerdorf wrote: On 6/20/10 1:21 PM, Lester Caine wrote: > ( Foregot to change address again :( ) > Ilia Alshanetsky wrote: >> What are your views on including APC in the core, or reasons not to? > > Dictatorship? > Optional module which have well used alternatives should not be proced > on by default! Probably more people use alternatives and have for > years? pecl has been around for years. Nobody else has submitted an opcode cache to pecl. We certainly would not have rejected any such submission, and we still won't. >>> >>> Well eaccelerator has served me well for years on both Windows and Linux >>> and has been listed on wikipedia for years before APC was added ;) Just >>> because people don't like restrictive source management does not mean >>> good code is not available. >> >> No, it is not enough to just have source code. The developers need to >> play along as well. > > ? eaccelerator is being actively developed, and builds are available for > more versions of windows setup than PHP itself currently supports so the > developers of it are playing along much better then PHP core developers. > And a number of alternatives have also been listed by others. So the > question has to be "Why should APC be given special treatment?" Is it > any better than the currently available alternatives or is it still > playing catchup much like PDO? But they haven't made any attempts to add it to pecl nor release it under a license that would even make it possible to include in PHP. That's what I meant by playing along. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
APC has certain effects on the code that are far from obvious, and enabling it by default would significantly complicate the average user's learning curve. Can you elaborate? What "average user"-facing features are non-obvious? We should document them if nothing else. S -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
Hi! Sure, but that's win32 only Speaking of which - does apc work for Windows? Last time I checked (more than a year ago) it was extremely unstable. Was it fixed? What about other popular PHP platforms? -- 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] APC in trunk
Hi! 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. I do not think it is a very good idea. APC has certain effects on the code that are far from obvious, and enabling it by default would significantly complicate the average user's learning curve. -- 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] APC in trunk
Ilia Alshanetsky wrote: Sure, but that's win32 only Does that matter at present? http://www.nexdot.net/blog/2010/02/09/wincache-apache-and-a-pretty-graph/ My only objection to bundling yet another package into the core distribution is that it should be removable as well. eaccelerator works for me so I see no reason to change from it any time soon, and the performance figures I've been seeing support that position like MySQL probably as many people don't use it as do, so lets keep the core to what is needed, rather than what is optionally replaceable? -- 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
Several reasons: 1) APC is well maintained, by the same people who work on PHP. 2) The license does not preclude it's inclusion into the base version. 3) most people don't use any opcode cashes, which is not ideal when it comes to PHP. 4) apc inclusion does not prevent alternatives from existing... Ilia Alshanetsky CIO/CSO Centah Inc. On 2010-06-20, at 17:32, Lester Caine wrote: Rasmus Lerdorf wrote: On 6/20/10 2:05 PM, Lester Caine wrote: Rasmus Lerdorf wrote: On 6/20/10 1:21 PM, Lester Caine wrote: ( Foregot to change address again :( ) Ilia Alshanetsky wrote: What are your views on including APC in the core, or reasons not to? Dictatorship? Optional module which have well used alternatives should not be proced on by default! Probably more people use alternatives and have for years? pecl has been around for years. Nobody else has submitted an opcode cache to pecl. We certainly would not have rejected any such submission, and we still won't. Well eaccelerator has served me well for years on both Windows and Linux and has been listed on wikipedia for years before APC was added ;) Just because people don't like restrictive source management does not mean good code is not available. No, it is not enough to just have source code. The developers need to play along as well. ? eaccelerator is being actively developed, and builds are available for more versions of windows setup than PHP itself currently supports so the developers of it are playing along much better then PHP core developers. And a number of alternatives have also been listed by others. So the question has to be "Why should APC be given special treatment?" Is it any better than the currently available alternatives or is it still playing catchup much like PDO? Perhaps a poll on what people are actually using in production? -- 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
Sure, but that's win32 only Ilia Alshanetsky CIO/CSO Centah Inc. On 2010-06-20, at 16:54, Derick Rethans wrote: On Sun, 20 Jun 2010, Rasmus Lerdorf wrote: On 6/20/10 1:21 PM, Lester Caine wrote: ( Foregot to change address again :( ) Ilia Alshanetsky wrote: What are your views on including APC in the core, or reasons not to? Dictatorship? Optional module which have well used alternatives should not be proced on by default! Probably more people use alternatives and have for years? pecl has been around for years. Nobody else has submitted an opcode cache to pecl. We certainly would not have rejected any such submission, and we still won't. Actually, there is another one: wincache. 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
hi, On Sun, Jun 20, 2010 at 11:32 PM, Lester Caine wrote: > Perhaps a poll on what people are actually using in production? The very large majority of the users I met use APC or Zend Cache solutions. However the point here is that as long as the extension is not php.net, they won't and can't be considered for inclusion. Now, about eaccelarator, it is GPL, it is a no-go with PHP. 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: On 6/20/10 2:05 PM, Lester Caine wrote: Rasmus Lerdorf wrote: On 6/20/10 1:21 PM, Lester Caine wrote: ( Foregot to change address again :( ) Ilia Alshanetsky wrote: What are your views on including APC in the core, or reasons not to? Dictatorship? Optional module which have well used alternatives should not be proced on by default! Probably more people use alternatives and have for years? pecl has been around for years. Nobody else has submitted an opcode cache to pecl. We certainly would not have rejected any such submission, and we still won't. Well eaccelerator has served me well for years on both Windows and Linux and has been listed on wikipedia for years before APC was added ;) Just because people don't like restrictive source management does not mean good code is not available. No, it is not enough to just have source code. The developers need to play along as well. ? eaccelerator is being actively developed, and builds are available for more versions of windows setup than PHP itself currently supports so the developers of it are playing along much better then PHP core developers. And a number of alternatives have also been listed by others. So the question has to be "Why should APC be given special treatment?" Is it any better than the currently available alternatives or is it still playing catchup much like PDO? Perhaps a poll on what people are actually using in production? -- 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 6/20/10 2:05 PM, Lester Caine wrote: > Rasmus Lerdorf wrote: >> On 6/20/10 1:21 PM, Lester Caine wrote: >>> ( Foregot to change address again :( ) >>> Ilia Alshanetsky wrote: What are your views on including APC in the core, or reasons not to? >>> >>> Dictatorship? >>> Optional module which have well used alternatives should not be proced >>> on by default! Probably more people use alternatives and have for years? >> >> pecl has been around for years. Nobody else has submitted an opcode >> cache to pecl. We certainly would not have rejected any such >> submission, and we still won't. > > Well eaccelerator has served me well for years on both Windows and Linux > and has been listed on wikipedia for years before APC was added ;) Just > because people don't like restrictive source management does not mean > good code is not available. No, it is not enough to just have source code. The developers need to play along as well. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
Perhaps by adding it to core the original reasons for alternatives will be reduced and the things that make those special could be implemented into apc? On Jun 20, 2010, at 1:56 PM, Ferenc Kovacs wrote: > On Sun, Jun 20, 2010 at 10:39 PM, Lukas Kahwe Smith > wrote: > >> >> On 20.06.2010, at 22:21, Lester Caine wrote: >> >>> ( Foregot to change address again :( ) >>> Ilia Alshanetsky wrote: What are your views on including APC in the core, or reasons not to? >>> >>> Dictatorship? >>> Optional module which have well used alternatives should not be proced on >> by default! Probably more people use alternatives and have for years? >> >> >> probably not actually .. my guess is that the vast majority of users do not >> use any byte code cache today. this could be our effort to reduce co2 >> emissions world wide. >> > > Are you sure? > Usually installing an opcode cache is the first optimalization effort for > every php project. > I'ts easy, it's transparent, and can give a vast amount of performance > boost, so > - shared hosting providers install it, because they can oversell more > - ppl who can run dedicated server/vps usually knowledgeable enough to > install it right away > > > >> >> +1 on adding apc to trunk >> +0 about enabling apc by default .. or rather undecided at this point. >> >> > I prefer xcache, but I think that its better adding apc to the core, than > nothing at all. > Why should this be disabled by default? > > I never had any problem using xcache. Maybe that it has no gain if you only > use php for cli or cgi. > > Tyrael -- 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: On 6/20/10 1:21 PM, Lester Caine wrote: ( Foregot to change address again :( ) Ilia Alshanetsky wrote: What are your views on including APC in the core, or reasons not to? Dictatorship? Optional module which have well used alternatives should not be proced on by default! Probably more people use alternatives and have for years? pecl has been around for years. Nobody else has submitted an opcode cache to pecl. We certainly would not have rejected any such submission, and we still won't. Well eaccelerator has served me well for years on both Windows and Linux and has been listed on wikipedia for years before APC was added ;) Just because people don't like restrictive source management does not mean good code is not available. -- 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 Sun, 20 Jun 2010, 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. I would like to add it as well; but not turn it on by default. Not because it wouldn't be good, but more because it requires (a bit of) configuration. 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] APC in trunk
On Sun, Jun 20, 2010 at 10:39 PM, Lukas Kahwe Smith wrote: > > On 20.06.2010, at 22:21, Lester Caine wrote: > > > ( Foregot to change address again :( ) > > Ilia Alshanetsky wrote: > >> What are your views on including APC in the core, or reasons not to? > > > > Dictatorship? > > Optional module which have well used alternatives should not be proced on > by default! Probably more people use alternatives and have for years? > > > probably not actually .. my guess is that the vast majority of users do not > use any byte code cache today. this could be our effort to reduce co2 > emissions world wide. > Are you sure? Usually installing an opcode cache is the first optimalization effort for every php project. I'ts easy, it's transparent, and can give a vast amount of performance boost, so - shared hosting providers install it, because they can oversell more - ppl who can run dedicated server/vps usually knowledgeable enough to install it right away > > +1 on adding apc to trunk > +0 about enabling apc by default .. or rather undecided at this point. > > I prefer xcache, but I think that its better adding apc to the core, than nothing at all. Why should this be disabled by default? I never had any problem using xcache. Maybe that it has no gain if you only use php for cli or cgi. Tyrael
Re: [PHP-DEV] APC in trunk
On Sun, 20 Jun 2010, Rasmus Lerdorf wrote: > On 6/20/10 1:21 PM, Lester Caine wrote: > > ( Foregot to change address again :( ) > > Ilia Alshanetsky wrote: > >> What are your views on including APC in the core, or reasons not to? > > > > Dictatorship? > > Optional module which have well used alternatives should not be proced > > on by default! Probably more people use alternatives and have for years? > > pecl has been around for years. Nobody else has submitted an opcode > cache to pecl. We certainly would not have rejected any such > submission, and we still won't. Actually, there is another one: wincache. 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] APC in trunk
On 6/20/10 1:21 PM, Lester Caine wrote: > ( Foregot to change address again :( ) > Ilia Alshanetsky wrote: >> What are your views on including APC in the core, or reasons not to? > > Dictatorship? > Optional module which have well used alternatives should not be proced > on by default! Probably more people use alternatives and have for years? pecl has been around for years. Nobody else has submitted an opcode cache to pecl. We certainly would not have rejected any such submission, and we still won't. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
+1 as Lukas, on adding but not enabled by default. On Jun 20, 2010, at 4:39 PM, Lukas Kahwe Smith wrote: > > On 20.06.2010, at 22:21, Lester Caine wrote: > >> ( Foregot to change address again :( ) >> Ilia Alshanetsky wrote: >>> What are your views on including APC in the core, or reasons not to? >> >> Dictatorship? >> Optional module which have well used alternatives should not be proced on by >> default! Probably more people use alternatives and have for years? > > > probably not actually .. my guess is that the vast majority of users do not > use any byte code cache today. this could be our effort to reduce co2 > emissions world wide. > > +1 on adding apc to trunk > +0 about enabling apc by default .. or rather undecided at this point. > > regards, > Lukas Kahwe Smith > m...@pooteeweet.org > > > > > -- > 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
On 20.06.2010, at 22:21, Lester Caine wrote: > ( Foregot to change address again :( ) > Ilia Alshanetsky wrote: >> What are your views on including APC in the core, or reasons not to? > > Dictatorship? > Optional module which have well used alternatives should not be proced on by > default! Probably more people use alternatives and have for years? probably not actually .. my guess is that the vast majority of users do not use any byte code cache today. this could be our effort to reduce co2 emissions world wide. +1 on adding apc to trunk +0 about enabling apc by default .. or rather undecided at this point. 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
( Foregot to change address again :( ) Ilia Alshanetsky wrote: What are your views on including APC in the core, or reasons not to? Dictatorship? Optional module which have well used alternatives should not be proced on by default! Probably more people use alternatives and have for years? -- 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] Performance problem with php
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 Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Remove sqlite2 from trunk
On Fri, Jun 18, 2010 at 7:50 PM, Jonathan Bond-Caron wrote: > SQLITE_API int sqlite3_busy_timeout(sqlite3*, int ms); > > b) No persistent connections > > Any reason why it wasn't migrated from sqlite.c? It is now in trunk. 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
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 On Sat, Jun 19, 2010 at 9:23 AM, Kalle Sommer Nielsen wrote: > Greetings > > As the process for trunk grows, I think we should consider which > extensions we will move in and out of the core, this thread however is > solely about moving APC into the core. > > As original proposed and agreed on the PDM in Paris, was to include > APC in PHP6, and not turn it on by default. I think it will benefit > both us and the community if we move APC into the core (trunk, 5.4). > APC is one of the most popular extensions at PECL and many core devs > also work on APC. > > Currently the only issue I see by putting APC into the core is the CS, > as APC uses spaces instead of tabs. > > Another thing we might want to look at is whether we should support > 5.2, or simply upgrade APC's version and break backwards compatibility > so we don't have a layer of checks for macros that wasn't available in > previous version, perhaps only require 5.3+ within the APC code, this > however is not really a question of including APC in the core, but > rather a per extension discussion ;-) > > What are your views on including APC in the core, or reasons not to? > > -- > regards, > > Kalle Sommer Nielsen > ka...@php.net > > -- > 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
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Remove sqlite2 from trunk
On 20.06.2010, at 12:01, Ulf Wendel wrote: > Johannes Schlüter schrieb: >> On Sat, 2010-06-19 at 12:45 +0200, Sebastian Bergmann wrote: >>> Am 19.06.2010 11:33, schrieb Patrick ALLAERT: What are the possible actions/alternatives? >>> I think this was already mentioned: add a BC layer to ext/mysqli so >>> that the "new" extension supports the old mysql_* functions. This would >>> rid us off the old ext/mysql code without breaking code that relies on >>> it. >> ... while such a wrapper has about the same amount of code as the >> classic mysql extension (... which is in most parts a simple wrapper >> over library functions...) Or in other words: Such a wrapper doesn't >> have real benefits. > > And any wrapper which is there by default won't change anything. People will > continue to use the old API. You need to move the masses or create facts by > removing ext/mysql. The latter is quite crazy considering how popular > ext/mysql is. Its popularity is somewhat understandable: its old and the API > is very phpish in a classical non PJAVA sense. > > One of the few things that could be done is adding a note to each and every > ext/mysql docs page stating that one shall use ext/mysqli instead and give > examples how to do it. well couldnt the compat layer be written in PHP? i think this will send a fairly clear message. finally IIRC there was a mysql->mysqli conversion script that could be prominently placed in the docs. and of course we can add deprecation notices. 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] Performance problem with php
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("/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
Re: [PHP-DEV] Remove sqlite2 from trunk
Johannes Schlüter schrieb: On Sat, 2010-06-19 at 12:45 +0200, Sebastian Bergmann wrote: Am 19.06.2010 11:33, schrieb Patrick ALLAERT: What are the possible actions/alternatives? I think this was already mentioned: add a BC layer to ext/mysqli so that the "new" extension supports the old mysql_* functions. This would rid us off the old ext/mysql code without breaking code that relies on it. ... while such a wrapper has about the same amount of code as the classic mysql extension (... which is in most parts a simple wrapper over library functions...) Or in other words: Such a wrapper doesn't have real benefits. And any wrapper which is there by default won't change anything. People will continue to use the old API. You need to move the masses or create facts by removing ext/mysql. The latter is quite crazy considering how popular ext/mysql is. Its popularity is somewhat understandable: its old and the API is very phpish in a classical non PJAVA sense. One of the few things that could be done is adding a note to each and every ext/mysql docs page stating that one shall use ext/mysqli instead and give examples how to do it. Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Performance problem with php
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 the
directories in the include path.
but as far as I can see in the trace, this isn't the case.
Tyrael
On Sun, Jun 20, 2010 at 11:44 AM, Vincenzo D'Amore wrote:
> 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_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
> >> 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/s
Re: [PHP-DEV] Performance problem with php
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_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
>> 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("/usr", {st_mode=S_IFDIR|0755, st_size=4
Re: [PHP-DEV] Performance problem with php
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 version: Apache/2.2.11 (Unix) Server built: Jan 8 2009 09:27:22 Server's Module Magic Number: 20051115:21 Server loaded: APR 1.2.7, APR-Util 1.2.7 Compiled using: APR 1.2.7, APR-Util 1.2.7 Architecture: 64-bit Server MPM: Prefork threaded: no forked: yes (variable process count) Server compiled with -D APACHE_MPM_DIR="server/mpm/prefork" -D APR_HAS_SENDFILE -D APR_HAS_MMAP -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled) -D APR_USE_SYSVSEM_SERIALIZE -D APR_USE_PTHREAD_SERIALIZE -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT -D APR_HAS_OTHER_CHILD -D AP_HAVE_RELIABLE_PIPED_LOGS -D DYNAMIC_MODULE_LIMIT=128 -D HTTPD_ROOT="/etc/httpd" -D SUEXEC_BIN="/usr/sbin/suexec" -D DEFAULT_PIDLOG="logs/httpd.pid" -D DEFAULT_SCOREBOARD="logs/apache_runtime_status" -D DEFAULT_LOCKFILE="logs/accept.lock" -D DEFAULT_ERRORLOG="logs/error_log" -D AP_TYPES_CONFIG_FILE="conf/mime.types" -D SERVER_CONFIG_FILE="conf/httpd.conf" # cat /proc/version Linux version 2.6.18-028stab062.3 (r...@rhel5-64-build) (gcc version 4.1.2 20070626 (Red Hat 4.1.2-14)) #1 SMP Thu Mar 26 14:46:38 MSK 2009 On Sun, Jun 20, 2010 at 9:11 AM, Alexey Zakhlestin wrote: > > 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 sequence of > tentative > > httpd/mod_php5 does in order to read an php page. > > let's start with the basics. > > what version of php is this? > what version of apache (and which mpm) is this? > what OS is this? > > -- > Alexey Zakhlestin > http://www.milkfarmsoft.com/ > > > > > -- 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
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 lstat calls.
Tyrael
On Sun, Jun 20, 2010 at 9:26 AM, Dinh wrote:
> 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
> > 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
> >
> >
> ls
Re: [PHP-DEV] Performance problem with php
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
> 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("/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,
> s
Re: [PHP-DEV] Performance problem with php
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 sequence of tentative > httpd/mod_php5 does in order to read an php page. let's start with the basics. what version of php is this? what version of apache (and which mpm) is this? what OS is this? -- Alexey Zakhlestin http://www.milkfarmsoft.com/ smime.p7s Description: S/MIME cryptographic signature
