# HG changeset patch
# Node ID 32a647705402
# Parent  19933bb48ed5
diff --git a/hugo/content/post/thank-you-steadfast.md b/hugo/content/post/thank-you-steadfast.md
new file mode 100644
--- /dev/null
+++ b/hugo/content/post/thank-you-steadfast.md
@@ -0,0 +1,69 @@
+---
+title: "Thank You, Steadfast"
+date: 2021-05-18T23:33:29-04:00
+categories:
+  - blog
+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 were'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
+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!
