pidgin/nest

Parents 488431cb1973
Children 280e21ae8fda
A first pass at a blog post thanking Steadfast Networks for their generous
hosting over the past several years. Included is a bit of a history lesson on
how we ended up on Steadfast and how we used the server they provided us.

Testing Done:
Ran hugo server locally and verified the post appeared as expected.

Reviewed at https://reviews.imfreedom.org/r/660/
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/hugo/content/post/thank-you-steadfast.md Thu May 20 00:42:23 2021 -0500
@@ -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!