httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William A Rowe Jr <wr...@rowe-clan.net>
Subject Re: reverse proxy wishlist
Date Thu, 03 Dec 2015 16:09:08 GMT
On Thu, Dec 3, 2015 at 8:59 AM, Jim Jagielski <jim@jagunet.com> wrote:

>
> What would *you* like to see as new features or enhancements
> w/ mod_proxy, esp reverse proxy.


HTTP/2 support, of course :)  It will be interesting to be able to leverage
and compare a mod_proxy_serf vs a mod_proxy_http2 (nghttp2-based)
engine, as mentioned in another thread - multiple implementations
are always good for ferreting out protocol anomalies.

AIUI in the TLS age of HTTP, there is no forward proxy use case for
HTTP/2 that I can surmise, except as a CONNECT tunnel which 1.1
handled just fine already (AIUI that tunnel can then be a multiplexed
HTTP/2 conversation to the tunneled server.)  So this whole discussion
seems to revolve around reverse proxy backend connection. Windowing
might prove effective at reducing huge connection pools to app servers,
if they can be multiplexed over more heavily loaded fast TCP
connections.

My personal wish list is that we eliminate module bloat by coalescing
alternative "standard" implementations into a single module again in
2.next, and not just limited to lbmethod, but also the core socache
and slotmem providers. Most stock/core implementations shouldn't
change if a user wants to plug in 'yet another' option, but there is really
no excuse for us to map so many ldobjects and text pages into the
memory map of a given process, when the actual program text page
of each is a few hundred opcodes, max.

(You can submit that the user could want to replace the bytraffic
implementation, for example, but I'd counter that they can certainly
rebuild any mod_lbmethod_core module with the others still using
stock sources, and deploy their alternative, or they can give their
custom fork of a provide yet another provider name.)

I'm not asking anyone to coalesce these, though.  It was already
on my rather long list of 'nice to have' along with supporting multiple
conf mergers per module (effectively allowing 'multiple modules' to
be a single module and splitting our monstrous core server and dir
configs into related digestible pieces that rarely need to be merged,
and optimizing away modules with no conf merge at all).  And along
with cleaning up the httpd 2.next API, and i18n of error output
which I am continuing on first once the mod_ssl issues for mod_ftp
are resolved (my current project).

I was thinking about some
> sort of active backend monitoring, utilizing watchdog, which
> could also maybe, eventually, pull in performance and load
> data for the backend for a more accurate LB provider.
>

I had the impression there was some effort out there to create a
schema for backend servers to report load in a standardized way,
beyond heartbeat? But I've lost my references.

Last thought, you might want to share your question with users@?

Cheers,

Bill

Mime
View raw message