[ic] JavaScript Ajax library choice

Mike Heins 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.

-- 
Mike Heins
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 mailing list