In a recent post we talked about our current infrastructure hosting sponsorship, but we’ve had another hosting provider that has provided us a dedicated physical server for almost nine years. That provider is Steadfast Networks, who has been a silent but very important piece of our infrastructure.
In June 2012, a now-retired Pidgin developer who worked for Steadfast talked to his boss and secured us a dedicated physical server for free. The server was equipped with a quad-core Intel Core 2 Duo Q6600 2.4 GHz CPU, 8 GB RAM, and dual 250 GB SATA hard disks. Today these specs seem very modest, and even at the time they weren’t exactly the “top of the line,” but they were very impressive to a project whose existing infrastructure consisted of two virtual private servers with wildly inconsistent and underwhelming performance. After configuring the server to use the hard drives in a software RAID-1 array (Linux md), we moved our Trac issue tracking and wiki management system to this generously provided server.
When we first started using Trac in 2007, it displayed relatively reasonable performance. We were running it in an OpenVZ container-based virtual private server kindly donated by another hosting provider that is no longer in the hosting business. As the volume of traffic, ticket creation, wiki edits, and ticket comment activity on Trac grew, we began running into performance issues. At first, we ran Trac with mod_python in Apache, then moved to FastCGI in Apache. Guidance eventually became to run FastCGI in Lighttpd, so we did this for quite some time. As guidance later changed again, we migrated back to Apache, this time with WSGI. We also made a number of changes to the database that stored all the Trac data, which landed pretty quickly in PostgreSQL. We did end up making a number of tweaks to the database, all in the name of trying to improve performance.
So where does Steadfast come into that history exactly? Well, in June 2012, as we said earlier, but to be more specific, we had already made a bunch of the PostgreSQL database tweaks and were running Trac in Lighttpd with FastCGI at the time. And the move from the virtual private server to the real physical box was hugely beneficial to us.
Pretty much every instance of Trac that was Internet-accessible inevitably became a target for spammers. The spammers would flood tickets with comments containing lots of links to various websites with the goal of taking advantage of search indexing crawling the Trac content. In addition to needing to go back through all the added comments and delete the spam, we eventually reached a point where we had to implement anti-spam measures. The longer this battle went on, the harder it was for the virtual server to keep up. We could never have continued to run Trac with the influx of spam if Steadfast had not provided the physical server to us.
Equally important to us was the bandwidth Steadfast provided. They provided us a 100 megabit port and never limited our traffic. We never fully utilized that bandwidth for more than a few seconds at a time, but having it available was a huge benefit to us. The amount of traffic our Trac instance saw, plus the e-mail traffic Trac generated, was to us a substantial amount–an average of a few megabits per second for a lot of our time on that server. Admittedly, this would have been essentially nothing in the face of all the other traffic Steadfast handled, but it was major to us.
In the end, we were hosted on Steadfast’s network for just short of 9 years. If we had paid for this hosting out of pocket, it would have cost us several thousand dollars in that time. Thank you, Steadfast Networks, for being such a great host to us for so long!