title: "Thank You, Steadfast"
date: 2021-05-18T23:33:29-04:00
description: "" # Leave blank to use the auto summary
images: [] # Leave empty to default to the Pidgin logo In a [
recent post](
{{<ref "/post/digital-ocean-sponsorship">}}) 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](
https://www.steadfast.net), 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](
https://trac.edgewall.org) 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](
https://httpd.apache.org/),
then moved to FastCGI in Apache. Guidance eventually became to run FastCGI in
[
Lighttpd](
https://www.lighttpd.net/), 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](
https://www.postgresql.org/). We
did end up making a number of tweaks to the database, all in the name of trying
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
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
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!
