On Wed, Nov 18, 2015 at 1:58 PM, Michal Karm <michal.baba...@gmail.com> wrote:
>
> the patch suggested by Yenn [1][2] did not help the performance
> results in any substantial capacity. The difference between having and not
> having
>
> if (uri.port && uri.port == ap_proxy_port_of_scheme(uri.scheme)) {
> uri.port = 0;
> }
>
> in proxy_util.c is still at least 30% performance loss, gain respectively.
The code above is load time only (i.e. not per request), so it's not
this particular ap_proxy_port_of_scheme() which eats cycles, but
rather the fact that the proxy worker URL (name) is now canonicalized
at startup (not including the port if it is well known) and thus when
that URL is parsed/used at runtime (per request) in
ap_proxy_determine_connection(), the backend's port needs to be
determined using ap_proxy_port_of_scheme().
I thought this latter call was the culprit for the increased cycles,
but it seems not (the new version should be quite more efficient than
the previous code to find a know port associated to a scheme).
So I'm a bit lost here...
Can you confirm that reverting this only commit (r1650655) from 2.4.17
fixes the performance loss?
Also, which proxy module(s) is(are) used, http/ajp/...?
How are the backends ports declared in ProxyPass/BalancerMember
directives, using the default port for the scheme (ie. 80/443 for
http/s, 8009 for ajp, ...) or with a custom port or else no port at
all?
Regards,
Yann.
