From your quoted text:

"...unless the data is already in the read-ahead buffer."

So what's happening here is you perl script is faster that the NFS fill ( not suprising ) and so is emptying out the buffer on each read. Subsequent reads are issued before the read-ahead has time to fill the buffer. At least in a perfect world this what 'may' be happening, unless your NFS client is broken somehow. Try putting a sleep in your script and look at iostat to see if the NFS read sizes increases. I had actually though earlier of putting sleep in the code to ease the burden on the network but dismissed it as not addressing the NFS driver buffering issue, but from the text provided it seems that your driver implementation over-responds to multiple requests and so might respond to a slowing of the request rate.

I don't recall if you've stated anywhere whether your script reads the file sequentially. If so have you tried somethine like:

cat "filename" > script
[download]

In order to buffer the reads. ( You may need an enhanced version of cat to avoid memory thrashing with this method.)

Should you still decide to pursue modification of perl it would seem that this is the kind of thing for which IO layers was implemented. One would make a copy of the appropriate layer, change the name, then modify the buffer size. Switching to a larger read buffer would then simply require a use statement in your code.