Mailing List Archive

Process-level htaccess cache
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
Re: Process-level htaccess cache [ In reply to ]
Any reason this was based on the older 2.4.6 release?

On Thu, 13 Oct 2022 at 19:24, <as@php.net> wrote:

> 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
>
Re: Process-level htaccess cache [ In reply to ]
On Fri, Oct 14, 2022 at 11:12 AM Frank Gingras <thumbs@apache.org> wrote:

> Any reason this was based on the older 2.4.6 release?
>

We use 2.4.6 from CentOS 7. It has a ton of backports so the patch may
actually not apply cleanly to vanilla 2.4.6. Earlier I'd tested against
latest 2.4.x and the same perf savings applied. I can't find that version
of the patch at the moment. (This was several months ago.) I can quickly
port it if anyone wants to try it out.

Adam
Re: Process-level htaccess cache [ In reply to ]
On 14/10/2022 09:24, as@php.net wrote:

> 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

eh? you do realise 2.4.6 is 9 years old, we at 2.4.54 currently.

--
Regards,
Noel Butler

This Email, including attachments, may contain legally privileged
information, therefore at all times remains confidential and subject to
copyright protected under international law. You may not disseminate
this message without the authors express written authority to do so.
If you are not the intended recipient, please notify the sender then
delete all copies of this message including attachments immediately.
Confidentiality, copyright, and legal privilege are not waived or lost
by reason of the mistaken delivery of this message.