If the hundreds of megabytes of flat text are relatively static (only changing once a week, say, or not at all), then the best thing would be to figure out how to structure it into something other than a flat text file -- either a dbm file as suggested by Zaxo, or a relational database.

If you're parsing through something like a log file that changes (grows) continuously, you could still consider creating "digests" at regular intervals that would not be flat text (i.e. searching/indexing would be relatively quick and properly focused from the user's perspective), so that a separate cron job handles the heavy lifting, and produces a derived data set that allows the browser interaction to rely on a simple/quick task.

In any case, having each browser connection produce its own distinct summary web page shouldn't be a problem -- just apply a file name convention that makes it easy for yesterday's html files to be deleted at noon or whatever.