On Thu, Dec 3, 2015 at 8:59 AM, Jim Jagielski <[email protected]> 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
