On May 19, 2006, at 6:02 PM, bradley taylor wrote: > There's definitely a trade off of performance for configuration > simplicity/maintainability. The rewrites certainly have a negative > impact on performance, but the ability to "config and forget" is > pretty appealing for a lot of deployments.
Yes, agreed. > If you don't use Rails page caching One question here is where one does the caching. On web servers? In a cache module in your switches/routers? Dedicated edge of network caches? RAM caches on dedicated load-balancers (this is generally where we let caching happen)? When it comes to caching on web servers I think the issue really of cached versus dynamic is speed of ramp-up to a steady state. When you get a big enough bump of traffic, can you respond without getting so far behind that you can't recover? The usual question I ask is whether the application and web is already up and humming, and if so, can it saturate the network connection? > and you don't mind occasionally adding additional > ProxyPass directives for application specific assets, then proxying > is the way to go. Modifying the Apache conf to add a file_column or > reloading a new conf to support Capistrano's disable_web is kind of a > drag (and an annoyance for automated deployment/configuration). Yes, luckily rails applications are pretty standard, a single ProxyPass /images ! is sufficient for all sites. And while mod_rewrite versus mod_proxy to do the proxying itself are mutually exclusive, I thought you could combine other aspects/functions. I forget (because I typically don't combine them) is it really the case the a series of mod_rewrite rules are ignored when followed by proxy pass directives? > It would be nice to have some good benchmarks on various > deployments and > graph the relationship between simplicity, features, and performance. > Unfortunately, I tend to quickly loose productive development hours > when I get sucked into the parallel universe that is httperf and > Apache configuration tweaking. It probably wouldn't be much different. We've been doing quite of a bit of tracing through the stack with dtrace (dtrace in Kernel SSL, mod_dtrace in apache2, dtrace providers in ruby, dtrace providers in postgresql etc) and the rewriting process in apache isn't too heavy for most common rewrites (mod_security is a heavier module). > What we, the Mongrel Nation, need is a front-end with the simplicity > of Pound combined with Lighty's static performance, good caching > support, and select Apache features . Seems like quite an opportunity > for an enterprising C/C++ developer... If someone has specific ideas about this (I do) and would interested in being employed doing it, let me know. - J _______________________________________________ Mongrel-users mailing list [email protected] http://rubyforge.org/mailman/listinfo/mongrel-users
