Maybe reading larger chunks of the file will help.

{
  local $/ = \4096; # adjust as appropriate
  print while <FILE>;
}
[download]

Since you invite any suggestions ... how about formatting the file itself and letting the web server handle opening and printing it? You could set up a cron job to add the font tag to the large file instead of trying to do so dynamically each request. Also, since you did not supply an example of what your 5 meg file looks like, are you really sure that whitespace is going to be handled the way you think it is?

L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)

This is just a plain text log file with lines like this one


13:53:32,12-27-2004,Joe Bow,Toronto Travel .,ref_333,SSHTEST###12345##
+#00000000000000, 9
[download]

So based on that (typical?) line of log data, let's say it's 90 bytes/line, so a 5 MB file will be close to 56,000 lines of text.

Now, what does the person looking at the browser intend to do with this display? Is the user looking for something in particular? Maybe just the oldest log entries, or just the newest ones, or just the ones that have some particular properties?

If you figure out what the client needs to do with this information, you should focus on providing the particular subset of the log file that will directly support that task, so that you deliver an appropriate quantity of data, instead of delivering all the data.

The appropriate quantity for manual inspection in a browser display will probably be a lot less than 5 MB (hopefully closer to 50 KB); then your task is to write the correct kind of filter that will deliver just that subset of data, and if the filter runs reasonably fast on the server, the slowness problem at the browser end will go probably away.

If the client needs a complete download of the log file, then set it up as an ftp transfer to the client's local disk, instead of sending it to the browser display.

If the file is no longer being modified, you could gzip/zip it and offer that as an alternative if the browser supports compressed content (it will be in the accept part of the incoming request headers).

You should get really good compression rates with plain text.

If the file is still being modified then your choices for compression are a bit limited. Compressing on the fly *may* work but I wouldn't be surprised if the compressor needed to keep the file *as-is* while it ran. That opens up a whole new can of worms naturally :)

HTH, S

Perhaps buffering your I/O will help, e.g.:

# ***** Display selected log file to the screen ***** #
#=comment
my @buffer = "<font face='Verdana, Arial, Helvetica, sans-serif' size=
+\"2\" color=\"#000000\">";
open( FILE, "< $directory/$file" ) or die "Can't open $directory/$file
+ : $!";

push @buffer, <FILE>;
close FILE;
push @buffer, "</font>";
print @buffer;
#=cut
[download]

..if it happens to be Apache, and you DO have administrative control - then you might want to consider mod_deflate. I've used it before and seen significant performance improvments - particulary with pages that are mostly text.

HTH,
Darren :)