PhilanthropyJournal's response time improves from 30 seconds per page to sub second.

PhilanthropyJournal is one of the premier non-profit news sites, aggregating diverse news, events and job listings into a banner ad supported portal.

In order to manage the 3000+ news stories, PJ relied on a custom built content management system, or CMS. The CMS had been primarily built offshore by a small team of Russian programmers, which made communication about the business user's issues a challenge.

While the CMS managed the content fairly well, the web servers built all the end user requested stories and the front page on the fly out of the database, along with managing and tracking ad delivery. The results were greater than 30 second load times for the front page and the ability to scale to only a handful of concurrent users before pages began to time out. Every few days, the application would hang on the ISP's web servers, causing outages for PJ and all the other clients on the servers.

Because of the depth of experience hosting the 2000 Sydney Olympic Games for NBCOlympics.com, TitaniumSea was asked to look into the problem. After digging through hundreds of cross linked ASP pages, we quickly found that part of the problem was the web servers were processing huge amounts of code that had no relevance to the pages being displayed. Through discussions with the business users, we also found that the PJ staff was publishing 10 stories a day on average, and that it would be much more efficient to regenerate the front page when a story was pushed than to regenerate it on each user request.

Ad tracking was switched from dynamically updating the database on each ad served to utilizing the web server log files and processing ad views on a daily basis.

The results were the front page loaded in less than a second, compared to 30 seconds before, and news stories loaded in less than a second, compared to 10 seconds previously. The web site was able to handle close to 1000 concurrent users, up from a handful. Also, the frequent web server crashes were completely eliminated.

back to case studies