On 11/17/2015 02:28 PM, Jim Jagielski wrote:
Agreed... if we should optimize, then focusing on ap_proxy_port_of_scheme(),
which is part of the actual API, is likely best.
On Nov 17, 2015, at 8:20 AM, Yann Ylavic <[email protected]> wrote:
On Tue, Nov 17, 2015 at 2:12 PM, Jim Jagielski <[email protected]> wrote:
I would propose that if the below is NOT the cause, then the
old version remain. There is a lot to be said for simplicity
and clarity.
There is still a (per request) call to ap_proxy_port_of_scheme() in
ap_proxy_determine_connection() we can't avoid (AFAICT), so it is
worth optimize it anyway IMO.
Plus, the whole reason for ap_proxy_port_of_scheme() was
to avoid the sorts of special numbers the below "hides"
in various locations.
Agreed, the optimization in ap_proxy_port_of_scheme() only is probably better.
Hi guys, FYI,
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 test case is having hundreds of different application contexts
being accessed by hundreds of concurrent clients.
Thanks for comments.
Cheers
[1]
http://mail-archives.apache.org/mod_mbox/httpd-dev/201511.mbox/%3CCAKQ1sVP-ZO%3DC8kUt_%2BtW7%2Bh5A%3DyjDuKhEE9ah9shF1xRQVciRw%40mail.gmail.com%3E
[2]
http://mail-archives.apache.org/mod_mbox/httpd-dev/201511.mbox/%3CCAKQ1sVO_-Shud7EXrCBn-KhjdPdNVk96Npwxeeb6Lk5n0TE1KA%40mail.gmail.com%3E
Michal Karm Babacek
--
Sent from my Hosaka Ono-Sendai Cyberspace 7
