Perrin Harkins wrote:
>
> > I do feel that compile time matters, but really with 60 seconds
> > and high MaxRequestsPerChild, these systems are getting plenty
> > of compiling caching.
>
> The thing is, if mod_caucho takes 5 seconds the first time it hits each
> template, but is the fastest afterwards, these numbers don't give a very
> accurate picture of that. Most people expect a hit on the first access.
>
I get it, but I don't like it... why should an app get to spend
( hypothetically ) 60 seconds compiling a template into highly optimized
assembly at runtime, and not have to show this cost in the benchmark.
I'd be willing to run a test for longer, or run it multiple times,
but to entirely throw out the compilation phase results just seems
wrong to me. I'd like to see some middle ground here.
> No need for anything that fancy. I'd say just run the test once as a primer
> and throw away the results, like you were doing before. It could be for 10
> seconds instead of 60.
>
Another reason not to throw out the results is that it represents
a legitimate web request as part of the apps life cycle. There
might be some user sitting at the end of that 5 second delay.
But then if we talk about throwing out highs & lows this starts
to sound almost scientific. Like run 10 time slices, throw
out the highest & lowest times?
> I wouldn't worry about them interacting so much, but I did suggest running
> multiple times and averaging. I think it helps smooth out random bad runs,
> which do happen now and then.
>
> Any numbers on the new Apache::ASP CGI mode?
>
Horrid. Won't set up a benchmark yet, but its something like
3 hits/sec on my system compared with mod_cgi CGI.pm which is
11 hits/sec. ASP won't be optimized for mod_cgi type execution
any time soon, which would require not loading in all the code
per request which it does now for best mod_perl use.
--Josh
