Hello,
I work on a LAMP stack at a large e-commerce company. We have big htaccess
files filled with mod_rewrite rules which are slow to parse. Moving these
routes into httpd.conf would be more efficient, but would require changing
our deployment strategy. Moving them into application code could also be
more efficient, but porting them would take a lot of effort. So we explored
optimizing httpd itself.
Patching[0] the existing htaccess cache to live at the process-level
instead of the request-level proved to be a significant win for us. We
expected to save a handful of millis across the board, but also got a nice
drop in CPU as well.
The patch is probably too hacky or specific to merge as-is. (How many
perf-sensitive Apache installations have huge htaccess files?) Perhaps a
cleaner alternative would be adding in the necessary hooks and rewriting
the patch as a module. Feedback encouraged.
Thanks,
Adam
[0] https://gist.github.com/adsr/d6360b5cd59c084d67adc5e8e6127695 applies
to 2.4.6
I work on a LAMP stack at a large e-commerce company. We have big htaccess
files filled with mod_rewrite rules which are slow to parse. Moving these
routes into httpd.conf would be more efficient, but would require changing
our deployment strategy. Moving them into application code could also be
more efficient, but porting them would take a lot of effort. So we explored
optimizing httpd itself.
Patching[0] the existing htaccess cache to live at the process-level
instead of the request-level proved to be a significant win for us. We
expected to save a handful of millis across the board, but also got a nice
drop in CPU as well.
The patch is probably too hacky or specific to merge as-is. (How many
perf-sensitive Apache installations have huge htaccess files?) Perhaps a
cleaner alternative would be adding in the necessary hooks and rewriting
the patch as a module. Feedback encouraged.
Thanks,
Adam
[0] https://gist.github.com/adsr/d6360b5cd59c084d67adc5e8e6127695 applies
to 2.4.6