[tor-bugs] #32090 [Internal Services/Tor Sysadmin Team]: Blog status and where to go
Tor Bug Tracker & Wiki
blackhole at torproject.org
Tue Dec 10 18:46:29 UTC 2019
#32090: Blog status and where to go
-------------------------------------------------+---------------------
Reporter: hiro | Owner: tpa
Type: defect | Status: new
Priority: Medium | Milestone:
Component: Internal Services/Tor Sysadmin Team | Version:
Severity: Normal | Resolution:
Keywords: | Actual Points:
Parent ID: | Points:
Reviewer: | Sponsor:
-------------------------------------------------+---------------------
Comment (by anarcat):
Here's a summary of our status with the blog, a month after the cache went
online. Two main problems were identified with the blog:
1. Broken templates and long-term web development goals
2. Cost overrun issues
TL;DR:
1. fix templates in-house or Giant Rabbit, switch to static site
generator (Lektor?) and external commenting system (Discourse?) in the
mid-long term
2. cost overruns back under control (~500$?), but incomprehensible
billing makes this possibly uncertain, need to double-check
= Broken templates and web development
Ever since some change happened on the blog (an upgrade?), HTML templates
were broken, which is particularly visible in the comments section. Those
are not formatted properly and we want those fixed. We considered various
providers to outsource this consulting to and, coincidentally, consider
moving our hosting elsewhere. We had a quote from Koumbit.org which was
privately discussed.
For now, we will try to fix the blog where it is in the meantime, maybe
with the help of an existing Drupal provider (Giant Rabbit) instead of
starting a new business relationship. Something that we should consider is
that fixing the template might be expensive. Hiro is willing to make
another try adapting our styleguide to an updated bootstrap template.
In the long term, we want to move away from Drupal, towards a static site
generator for the content and something like Discourse for the comments in
the backend. The latter could be reused for other projects inside Tor,
particularly the support and community teams, among others. It was also
considered as an option for easier user onboarding for bug reporting when
compared to GitLab. The static site generator could be one we area already
using, like Lektor. This still has to be discussed further. We might
achieve the same level of WYSIWYG with a static site generator, without
the time and economical investment of running a giant framework like
drupal.
= Cost issues
The other problem that was identified in October was the cost overrun
issues. Around August or September, we passed the 300k visits per month
mark, which bumped us in another price range with Pantheon (~1k$/mth).
Their [https://pantheon.io/pricing-comparison pricing plan] seem to go as
follows, in terms of visits/month vs cost/month:
* small, 25k: 175$
* medium, 50k: 300$
* large, 150k: 600$
* extra-large, 300k: 1000$
(I'm ignoring the "basic" 50$/mth package because I'm going under the
assertion that's not accessible for us, because it's a high traffic site.)
Before the traffic bumps happened, we were billed 500$/mth for the site,
presumably a prefered rate over the official 600$/mth rate. We were bumped
from the "large" to the "extra-large" package first on september 27th,
then again on october 29th. Their billing system is ... a bit opaque to
me, but it seems we are now billed 500$/mth again. I honestly can't figure
out *what* is going on with the billing at this point, honestly. I would
love if Jon or someone else could go over those invoices and figure it
out.
But my theory right now is the caching system did its job and brought us
back to a "pre-crisis" level of billing, that is, the "large" billing
package. Indeed, that is what the "billing" section of the Pantheon
dashboard says. There's also this message in the "Workflow section:
> Changed site plan to "plan-performance_large-preferred-monthly-1"
> [matt's email address at panthon]
> Finished 40 minutes ago
So maybe we got someone at Pantheon to intervene for us?
We can clearly see a drop in the traffic on the backend in the Pantheon
stats:
[[Image(snap-2019.12.09-11.28.37.png, 700)]]
* October: 435k visits, 3.1M pages served
* November: 165k visits, 1M pages served
That's a 63% drop in visits and 68% drop in page served. It could still
get slightly better in December, as out hit ratio is actually better than
this, at 88%:
[[Image(snap-2019.12.09-11.30.12.png, 700)]]
The reason those ratios don't correspond exactly to each other is we have
different ways to count those statistics. Pantheon uses "visits" and
"pages", we use "hits". The distinction is that a "visitor" can hit
multiple "pages" in one "visit", and a page is made of multiple "hits". So
while we may keep many hits from going to the backend, we may not keep as
many "pages" as we want going there. I suspect it would be very hard to
remove the other 115k visits per month to get down to the medium package,
and I have not made more efforts to do so.
Also, as far as I can tell, this traffic hitting our own TPA
infrastructure is not affecting us in any significant way, neither in
terms of cost (traffic is not large enough to change billing
significantly) or performance (load is not big enough to affect the
server's overall performance).
So I consider the "cost" crisis to be over, but there might be more tricks
we could do to bring the hit ratio down. At this point, I consider the
cost tradeoff to not be worth it, however, as long as Pantheon doesn't
bump us back to the "extra large" cost grid.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/32090#comment:6>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list