mike at perusion.com
Sat Apr 4 17:46:15 UTC 2009
Quoting Jon Jensen (jon at endpoint.com):
> On Sat, 4 Apr 2009, Mike Heins wrote:
> > There is a significant territory between the large massively- accessed
> > site and the site with so little traffic it doesn't matter what you do.
> > Interchange has only a few sites with backcountry.com traffic and we are
> > never going to generalize solutions for them.
> > But there are many sites with between 50,000 and 500,000 visitors per
> > month. During peak access times it does matter what they are doing, as
> > much for perceived performance as system load.
> Yes, that's true, but even the lightly-trafficked sites can have huge
> bursts of traffic from Digg, Twitter, or whatever, and being able to
> withstand it gracefully makes the difference between a lot of new users
> and a temporarily down website.
Yup. And there are the robot crawls, too, which can get ugly if
you don't pay attention to them.
> Premature optimization is expensive and often misguided, but not
> optimizing at all leads to unhappy surprises.
As we have discovered. The PreFork method turned out to be one of the
biggest wins, as did mv_tmp_session. Plus lots of memory is an optimization
in a class by itself. 8-)
> I'm not telling you anything you don't know here. Maybe what I'm trying to
> say is that at least some of the lessons of the very highly-trafficked
> sites can be applied to the benefit of the less-trafficked sites as well.
> > That's the whole point. The servlet isn't Interchange-based, but uses
> > the data written by Interchange on session initiation.
> What do you mean by "servlet"? Something like a minimal mod_perl handler
> that hits the database? Or a standalone CGI? Anything like that is fine,
> but would complicate the architecture and is exactly what I'd expect for a
> highly-trafficked site.
Yes, that's what I mean. It would complicate the architecture somewhat,
to be sure. It may not be the right thing to do. It would be nice to
be able to do it relatively painlessly in a standard fashion.
> For the less-busy sites, Interchange in PreFork mode is a great general
> solution that works well for Ajax requests too. Reducing the number of
> database requests, reducing the size of the session (or eliminating
> session usage entirely for some Ajax requests by passing authentication in
> the URL or POST body), etc. can improve performance without requiring a
> whole new architecture.
> > Those can benefit from some level of efficiency that allows them to
> > Ajax-enable their sites.
> So that's the crux: I don't know why you're assuming Interchange in
> PreFork mode with appropriate optimizations is unsuitable. It's definitely
> working for several very different sites I'm familiar with. But I guess
> you must have already determined it just won't work for one of your
> applications? Even if you add an additional app server or two?
No, I haven't determined that at all. In fact, I have a couple of
200,000 visitor sites that easily run on one not-so-beefy server. But
the optimizations aren't there in a standardized way. If you use
mv_tmp_session you have no security, and if you use sessions you have no
optimization. We use mv_tmp_session along with Autoload and custom
cookie settings for our optimizations, but it is a hack all the way.
Perusion -- Expert Interchange Consulting http://www.perusion.com/
phone +1.765.328.4479 <mike at perusion.com>
Being against torture ought to be sort of a bipartisan thing.
-- Karl Lehenbauer
More information about the interchange-users