On Fri, May 9, 2008 at 4:17 PM, Brian Eaton <[EMAIL PROTECTED]> wrote:
> On Fri, May 9, 2008 at 2:34 PM, Chris Chabot <[EMAIL PROTECTED]> wrote: > > The main problem is the overhead of loading all the features javascript > > each request, this consumes tons of memory and takes loads of IO, > > so the overly obvious solution is to not do this anymore :) > <snip> > > I'll play a bit with how the cache is setup, and if loading the > javascript > > of disk, while caching the features xml and dependency graph is more > > efficient in the end, or see if i can't think of some other solutions.. > > > > If some other ideas bubble up for anyone, please let me know :-) > > (Warning: not a PHP user, likely to be speaking nonsense.) It sounds > like something you're doing is screwing up the kernel's I/O cache. > What you *really* want is for each process to read from a file and > stream to a socket. The kernel will do a good job of figuring out > that those files ought to be kept in memory, so the individual > processes don't pay for any disk I/O as they work. Because the files > are being streamed in chunks it doesn't take much memory per-process > either. > > Even better would be to have access to something like the sendfile > syscall, so you can skip user space entirely. Again, to make that > possible you'd need to write the file to disk to take advantage of the > kernel. It is not uncommon for the kernel to do a better job of > caching data from disk than an HTTP server can do. FYI, in PHP you can do this with http://us2.php.net/readfile. This reads the data directly from file and pipes it into the output stream. > > > About the 420 pages/sec vs 630 pages/sec number... what are you > counting as a page? Does each page load include the requests to > download the extra js, or are you assuming you get those for free? >
