Some controlled tests verify that NFS + stat is a part of this performance issue, but maybe not the whole problem.

First I created 5000 files in `vagrant/tmp/mtime` and dropped this into `/var/www/w/mtimes.php`:
```
<?php

chdir('/vagrant/tmp/mtime');
array_map('stat', scandir('.'));
```

I experimented with NFS [[ http://linux.die.net/man/5/nfs | mount options ]] dealing with the [[ http://docstore.mik.ua/orelly/networking_2ndEd/nfs/ch18_06.htm#nfs2-CHP-18-SECT-6.html | attribute cache ]] and requests to `mtimes.php`.

Using the default options the performance is variable depending on how long you wait between requests. Quick subsequent requests can preempt the default file attribute cache timeout (which is between 3 and 30 seconds, `acregmin`/`acregmax`), while waiting longer results in uncached results. The first two requests below show that the PHP `stat` calls resulted in NFS `getattr` calls to the server, while the final request was made quickly enough that it preempted the cache expiration (no `getattr` calls).

```
vagrant@mediawiki-vagrant:~$ nfsstat -m
/vagrant from 10.11.12.1:/Users/dduvall/Projects/mediawiki/vagrant
 Flags:	rw,noatime,vers=3,rsize=16384,wsize=16384,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=10.11.12.1,mountvers=3,mountport=629,mountproto=udp,local_lock=none,addr=10.11.12.1

vagrant@mediawiki-vagrant:~$ nfsstat -ncl | grep getattr
nfs v3 client      getattr:   775067
vagrant@mediawiki-vagrant:~$ time curl http://127.0.0.1/w/mtimes.php

real	0m2.750s
user	0m0.010s
sys	0m0.010s
vagrant@mediawiki-vagrant:~$ nfsstat -ncl | grep getattr
nfs v3 client      getattr:   780068
vagrant@mediawiki-vagrant:~$ time curl http://127.0.0.1/w/mtimes.php

real	0m4.228s
user	0m0.009s
sys	0m0.010s
vagrant@mediawiki-vagrant:~$ nfsstat -ncl | grep getattr
nfs v3 client      getattr:   785070
vagrant@mediawiki-vagrant:~$ time curl http://127.0.0.1/w/mtimes.php

real	0m0.249s
user	0m0.010s
sys	0m0.010s
vagrant@mediawiki-vagrant:~$ nfsstat -ncl | grep getattr
nfs v3 client      getattr:   785074
```

Using a fixed attribute cache timeout of 30 (`actimeo=30`) instead of the variable min/max, I was able to get the improved performance more reliably (after an initial warmup).

```
vagrant@mediawiki-vagrant:~$ nfsstat -m
/vagrant from 10.11.12.1:/Users/dduvall/Projects/mediawiki/vagrant
 Flags:	rw,noatime,vers=3,rsize=16384,wsize=16384,namlen=255,acregmin=30,acregmax=30,acdirmax=30,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=10.11.12.1,mountvers=3,mountport=629,mountproto=udp,local_lock=none,addr=10.11.12.1

vagrant@mediawiki-vagrant:~$ nfsstat -ncl | grep getattr
nfs v3 client      getattr:   790086
vagrant@mediawiki-vagrant:~$ time curl http://127.0.0.1/w/mtimes.php

real	0m2.695s
user	0m0.010s
sys	0m0.009s
vagrant@mediawiki-vagrant:~$ nfsstat -ncl | grep getattr
nfs v3 client      getattr:   795087
vagrant@mediawiki-vagrant:~$ time curl http://127.0.0.1/w/mtimes.php

real	0m0.240s
user	0m0.008s
sys	0m0.008s
vagrant@mediawiki-vagrant:~$ nfsstat -ncl | grep getattr
nfs v3 client      getattr:   795088
```

Anyway... upping the NFS attribute cache improves performance drastically in this controlled experiment (~ 90%). However, running the same experiment using the curl request that @Mattflaschen posted yields a lesser (but still significant) performance gain (~ 25%), and the overall request time is still an attrocious 4+ seconds for me.

```
vagrant@mediawiki-vagrant:~$ nfsstat -ncl | grep getattr
nfs v3 client      getattr:   804036
vagrant@mediawiki-vagrant:~$ time curl -s 'http://127.0.0.1:8080/w/load.php?debug=false&lang=en&modules=startup&only=scripts&skin=vector&*' > /dev/null

real	0m5.758s
user	0m0.010s
sys	0m0.011s
vagrant@mediawiki-vagrant:~$ nfsstat -ncl | grep getattr
nfs v3 client      getattr:   805076
vagrant@mediawiki-vagrant:~$ time curl -s 'http://127.0.0.1:8080/w/load.php?debug=false&lang=en&modules=startup&only=scripts&skin=vector&*' > /dev/null

real	0m4.270s
user	0m0.010s
sys	0m0.011s
vagrant@mediawiki-vagrant:~$ nfsstat -ncl | grep getattr
nfs v3 client      getattr:   805098
```