FortKnox's Journal: /. Slow as Dirt

Man, slashdot is running like tar today!

I'd really like to know where the bottleneck is. Is it too many hits to the database, or something that J2EE technology would save (connection pooling, db caching, etc...)?

Has VA sold off some of the power-servers or bandwidth that once existed for OSDN??

Inquiring minds want to know!

Don't pay any attention to anything else...

[Liora]

... that this guy writes (well, it's good, but beware the links), but go to RealWorldStuff's journal [slashdot.org] for a possible explanation.

Re:Don't pay any attention to anything else...

[Com2Kid]

Oh look, Exodus died again what a surprise. . . .

seems that some large part of Exodus goes down every few months. . . . bleck.

How to improve /. performance

[Ars-Fartsica]

I can say with certainty that a Java setup of any kind would not be an improvement over their current setup. The Slashdot bottleck is most likely not the rendering software (mod_perl I think in their case) but the database.

Going to shared memory may provide performance improvements, but it involves a lot more custom coding, and can end up being brittle. Outside of that, you can go for RAID, clustering, or other partitioning solutions, or simply beef up to faster boxes with a shitload of RAM (like, over 2GB minimum).

On the outside, PHP with Zend or PHP Accelerator may be a slightly faster model than mod_perl.

Re:How to improve /. performance

[FortKnox]

If the DB is the problem, then EJB's are the solution. With connection pooling and DB caching (and using something like Weblogics clustering with EJBs), it would take the DB out of the bottleneck.

Re:How to improve /. performance

[Ars-Fartsica]

If they are using mod_perl, they already have db pooling available to them through the Apache::DBI package. I don't know how this compares to EJB pooling performance.