Hi I am preparing the bof, thanks for your input!
see http://wiki.apache.org/apachecon/ when it's online again, I ll be on #schoolserver and might some help for anwering some question. time are not sure since i can't access their wiki. expected time: next wednessday 20:30 CET kind regards, Marten On Tue, 2008-04-01 at 12:34 -0400, Martin Langhoff wrote: > On Tue, Apr 1, 2008 at 12:03 PM, Aaron Huslage <[EMAIL PROTECTED]> wrote: > > > - We are running memory-hog-webapps based on mod_php and mod_python > > > in prefork mode... but we have very strict memory constraints. Any > > > hints on how to compile apache (on Fedora and Debian) so that the > > > memory is released to the OS pool rather than to the child process' > > > private 'free' pool? > > > > I don't think this is currently possible. > > With alternative mem handling libs it has *always* been possible, but > often unstable/unreliable on linux. Current apache programmers can - > hopefully - shed some light into the current situation as now we have > more alternatives. It may be that php and python are even ready for > threaded worker model. Or that dietlibc has a different malloc. Or > that someone has a special custom malloc we can use. > > Or perhaps FastCGI is the way -- hopefully not ;-) > > Note - I hate to speculate ahead. Hopefully the apache crowd will tell > us what the state of things is. > > > Another web server can probably do > > this (Lighttpd?), but that comes with its own issues. > > Exactly. And we lose what apache brings to the party. > > One way to be to run the CoDeeN code. I'm sure they would be willing to work > > with us, since I know they want to open source the code. > > ISTR jg telling me they are using a licensed proprietary proxy but I > could be wrong. Are you in contact with them? I would love to see them > around here :-) > > > Otherwise, running > > mod_proxy on the XS with no caching > > The majority of XSs will have a horrible connection - we _need_ very > smart caching working together with the upstream proxy as smartly as > humanely possible. > > > What needs to be configurable from mod_perl? What custom behaviours are we > > talking about, or is this just a general ask for future needs? > > We want > > - The caching and handling of 1.1 cache-headers to be solid. > > - The upstream proxy to be able to pass hints to the xs proxy of > files to prefetch. These hints would initially be of popular resouces > across schools and content we intend to "push" out, for example, for > sw or content updates. > > - For some content, we may even add a SHA1 as a "local etag" to stuff > that looks unchanging but doesn't carry etags, the upstream proxy can > then buffer the response and save retransmission if the SHA1s match. > This would allow us to workaround web apps that aren't cache-smart. As > long as we can do this quickly - before http times out - we can save a > ton of traffic. HTTP timeouts and other issues limit how much we can > do here, but even within those constraints, I think we can do a lot. > > mod_proxy circa 1.3.x was completely closed to mod_perl and didn't > even play well with other modules. It was excellent as a "standalone" > module but it did not respect the request phases, so you could not > combine it with authen/authz handlers from other modules. > > cheers, > > > > m -- Marten Vijn http://martenvijn.nl http://wifisoft.org http://opencommunitycamp.org _______________________________________________ Server-devel mailing list [email protected] http://lists.laptop.org/listinfo/server-devel
