Re: PHP causing high number of NFS getattr operations?

On 19/02/13 20:32, Stas Malyshev wrote:

Hi!

and IIRC mwiki does 4 of these on a page render. Here a pattern based on (@include($file) == 1) is more cache-friendly.

This goes back to the fact that @ does not really disable errors - it only disables reporting of the errors, but the whole message is generated and goes all the cycle up to the actual error reporting before being suppressed. I've tried to address this problem a number of times but looks like there's really no way to do it without sacrificing some parts of current error reporting such as track_errors. Yup, in this scenario we're trading off two things. What the pattern is saying is if the source file exists then compile it. However, if the file exists, in say 90+% of the cases, and the code is often cached then the file_exists check generates I/O that isn't needed if the file is already APC (or O+ / xcache) cached. Yup if the file is missing then the error is generated and trapped in the reporting cycle, but the final result is that the result is false and the false==1 fails. Other than the wasted cycles in running up this stack, there aren't any other side-effects that I am aware of. Are there any?

Yes, this is an overhead, but it is small beer compared to doing a getattr() RPC across the server room fabric to a NAS server backend.

So in summary, this is largely avoidable but unfortunately I don't think that we can persuade the dev team to address this issue, even if I gave them the solution as a patch :-(

Could you explain what you're talking about here? The fact that you are engaging in this dialogue is great and I really appreciate it. What I am still trying to work out is how to interact with you guys in a way that is mutually productive. I did make the mistake of choosing the mainstay stable version iN live prod systems use -- 5.3 -- to take this whole issue apart and I guess that the dev team regards this as history.

I guess that I should bite the bullet and switch to 5.5. I've been working on an evaluatorfork of APC optimized for CLI/GCI which tackles a lot of these issues head on and performs reasonable well, but I realise that this is a dead-end and will never get deployed, but I am currently considering regressing some of this technology into 5.5 and O+. Are you interested in a version of O+ which supports all SAPIs? In architectural terms I feel that having a universal cache option is important. It changes the mindset from something which is only used in niche performance use cases to a standard option. It also means that the cache can be stress tested by the entire php test suite. However, to do some of this you don't start with a patch, but with an RFC informed by evidence, and that's my real reason for doing this demonstrator. //Terry