I'm convinced that modifying perl's block size would be a wasted effort. It would not change the size of the NFS requests to the server.

I disagree with your judgement. Please refer to the mtab string I posted further down. The rsize mount option is 32k, and was all along.

read and rsize match:

If the read buffer matches the NFS rsize mount option, then each read will incur 1 NFS request to the server with maximum possible efficiency.

read less than rsize:

A read with a buffer smaller than the rsize option cannot wait until the NFS buffer is filled - the NFS client will issue a request with however little was requested, unless the data is already in the read-ahead buffer. Again, each read will incur 1 NFS request, albeit less efficient by increasing the header to data ratio (more overhead).

read larger than rsize:

A read buffer larger than the rsize option will be split by your friendly VFS layer into however many NFS requests it takes to fulfill using rsize-sized chunks.

In my concrete example, this means that the 4k buffer employed by PerlIO will issue more NFS request than using a 32k buffer that matches my rsize mount option. Thus, increasing the buffer size in PerlIO is not wasted effort. Rather, any increase to 32k or beyond would result in a factor 8 less NFS requests. AFAI understood my admins, it is the sheer number of small NFS requests that slows the server to a crawl.

Careful testing will reveal the ideal buffer size. But both, the admins and I expect it to be at 32k or larger, not at 4k.