On 2016-06-10 07:12, Per Jessen wrote:
Dave Howorth wrote:
On Thu, 2016-06-09 at 23:15 +0200, Per Jessen wrote:
Anton Aylward wrote: from the caching that PHP may or may not be doing between
HTTP invocations (probably not, this is a connectionless protocol remember) there should be inode and pathname caching done by the kernel.
Yeah, that is an interesting point.
What cacheing can the kernel do? The filesystem is multi-hosted (at least in possibility) yes?
It's multipath'ed yes, but there's only one copy (as seen from the running system). The system sees a SCSI disk, that's all.
I was mistaken - I didn't understand how iSCSI worked; thought it allowed dual simultaneous connections.
So surely the kernel has to go right back to the filesystem every time to make sure it gets current state information.
What atime setting does the filesystem have? Anything other than noatime will definitely require the kernel to go right back to the disk blocks at least some of the time.
Umm, /srv/www is not mounted with noatime, maybe that needs testing too. Seems like a reasonable thing for a webserver.
There's some difference between the production server versus the test server and development machine that is causing the problem (in the sense of making bad behaviour unacceptable - lots of lstats taking a very long time - apparently over 250 µs each). I'm just trying to thing of things that might affect the timing. I take it reorganizing the paths or using a ramfs cache are not sensible for whatever reason? Have you got anywhere with enquiries to processwire or PHP? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org