[tor-bugs] #32090 [Internal Services/Tor Sysadmin Team]: Blog status and where to go

[Tor Bug Tracker & Wiki]

#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):

 ah. i saw this ticket after replying in private by email, but i'll share
 that analysis here. ;)

 > TL;DR: I'd go with varnish still, and ask the next steps on that.
 >
 > The single bottleneck issue for Varnish could be a problem, but we do
 > have multiple locations for our servers and would be able to providing
 > multiple redundant servers without too much problems if that becomes an
 > issue. I would certainly advocate towards creating at least two
 > frontends to start with.
 >
 > As we discussed last week, we already have a (~free) contract with
 > Fastly, so if we want to go the "CDN" way, it would be a good
 > option. They say they don't log/track their users, but I'm not sure it
 > would be a great move in terms of "publicity". I'm also not quite sure I
 > trust Fastly with doing the right thing here, ultimately, nor do I feel
 > that the idea of putting all our eggs in the same basket to be safe. We
 > also run the chance of blowing our quota there eventually if we throw
 > everything in Fastly.
 >
 > I would assume CF is out of the question, and I don't know enough about
 > Netlify to speak about it...
 >
 > It would be useful to know a little more what "page loads" mean. The
 > 300k "visitors" and 1.5M "pages" figures are similar to what we see in
 > the dashboard, but in terms of server resources, actual raw numbers
 > (megabits per second or total gigabytes, and "hits" per second, as
 > oposed to pages) would be more useful to evaluate our capacity. What's a
 > "page" for example? Is that one page load, with all extra resources like
 > CSS and images? While that's useful for them because it's their primary
 > driver (because it's drupal fighting with PHP and the database to create
 > the page on the fly), for us at the caching layer, we don't care about
 > the type of content as much. :)
 >
 > Finally, I looked at Tome briefly. There were various modules like this
 > in Drupal's history, the one I knew about before today is called "boost"
 > but hasn't been ported to D8 it seems. Tome is interesting, as it does
 > allow the creation of a static site in front of drupal, and we could
 > then share it on the mirror system, but then it still means we need to
 > deal and pay with pantheon for the hosting, which still seems like an
 > expensive proposition for basically a glorified text editor. I'm not
 > sure how "just sending the comment links" would work in practice, but
 > maybe it can be done too.
 >
 > Anyways, Tome would take time and effort to setup, and since we are
 > still considering our long-term options here, I wouldn't advise for that
 > solution just yet and just start working more concretely on how to setup
 > the varnish frontends, provided we have confirmation on the
 > numbers. With a rough guesstimate, 1.5M "pages" is about 23Mbit/s on
 > average during the month, something we could probably absorb in the
 > existing infrastructure without too much troubel. But that's assuming
 > just the 5MB frontpage, having better numbers would help here
 > tremendously.
 >

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/32090#comment:2>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online