Wiki source for Traffic2004
====2004 Traffic Notes====
Our peak of traffic was the day before election day, Nov. 1, when we did 95.32 GB upstream, with the month totaling 313.21 GB, both numbers exceeding what we thought were our optimistic expectations of ~30 GB/~200 GB. Fortunately, two months before the election we had deployed two load balanced web servers backed by a single database server, all Dual Xeon, 1 GB boxes, which were able to handle the load for the most part. We still had periods when our data pages were unavailable, due to mysql indexing issues. Monitoring could have been better coordinated, with datapipe made aware that specific inside pages needed to return content (_test.php), rather than just making sure that the requisite daemons were up and running.
We used caching on database queries - mysql use_cache option - and caching of object code via php_accelerator. Replication data was tunneled to hotline on the live database server, which helped reduce the database load by skipping the redundant writes, but it was still a high maintenance couple of weeks, just manageable by one person. Most of the time was spent on keeping the mysql's indexes optimized and repaired, and deleting inactive data, in other words tuning and tweaking past the last minute. Web source was rsynced between the two web servers.
We had daily tape backups of the live sites via datapipe's sure-admin service, plus firewall with the load balancing. During traffic spikes, prowling the log files for abuses (cut + uniq) showed mostly legitimate traffic with a couple hosts scraping content, easily dealt with (ipfw).
(This information is now collected and stored in [[https://files.votesmart.io/f/20623553 /public/Google Analytics/]])
----
CategoryITInfo
Our peak of traffic was the day before election day, Nov. 1, when we did 95.32 GB upstream, with the month totaling 313.21 GB, both numbers exceeding what we thought were our optimistic expectations of ~30 GB/~200 GB. Fortunately, two months before the election we had deployed two load balanced web servers backed by a single database server, all Dual Xeon, 1 GB boxes, which were able to handle the load for the most part. We still had periods when our data pages were unavailable, due to mysql indexing issues. Monitoring could have been better coordinated, with datapipe made aware that specific inside pages needed to return content (_test.php), rather than just making sure that the requisite daemons were up and running.
We used caching on database queries - mysql use_cache option - and caching of object code via php_accelerator. Replication data was tunneled to hotline on the live database server, which helped reduce the database load by skipping the redundant writes, but it was still a high maintenance couple of weeks, just manageable by one person. Most of the time was spent on keeping the mysql's indexes optimized and repaired, and deleting inactive data, in other words tuning and tweaking past the last minute. Web source was rsynced between the two web servers.
We had daily tape backups of the live sites via datapipe's sure-admin service, plus firewall with the load balancing. During traffic spikes, prowling the log files for abuses (cut + uniq) showed mostly legitimate traffic with a couple hosts scraping content, easily dealt with (ipfw).
(This information is now collected and stored in [[https://files.votesmart.io/f/20623553 /public/Google Analytics/]])
----
CategoryITInfo
