> 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.
> if we wanted to do away with compile
> time entirely, we'd make sure that each system got to precompile
> all its templates like Apache::RegistryLoader, Apache::ASP->Loader()
> & Embperl's Execute() in the parent httpd.
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.
> compile time is a very real problem for some
> types of apps like large web sites, and there is an increased
> burden on optimizing each benchmark, which implies an expertise
> in the development environment that many users may not
> have normally. I have been trying for more out of box benchmarks,
> and not highly optimized benchmarks, using mostly the shipping
> config for a system.
I feel like allowing the templates to compile isn't tuning, just ignoring
startup costs.
> People have suggested before ( you? ) to do two runs, and
> average the results, and I think that this is a fair approach,
> and might be better than just doubling the test time because
> the systems might interact, better yet, do them in one order,
> and then reverse them, to average out sequential interactions
> of the tests on a system ( ??? )
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?
- Perrin
