In theory, you could also dump the build artifacts to a GH Pages repo and host it from there, although I don't know if you would run up against any of the usage limits[0]. The immediate problem I see with that approach, though, is that I have no idea how any of the dynamic stuff (e.g. search) would be replaced. A question: there's a DB schema in there. Does the site still use a DB? [0] https://help.github.com/articles/what-is-github-pages/#usage-limits On Wed, Feb 1, 2017 at 10:36 PM, Eric Wong <e@xxxxxxxxx> wrote: > Jeff King <peff@xxxxxxxx> wrote: >> With the caveat that I know very little about web hosting, $230/mo >> sounds like an awful lot for what is essentially a static web site. > > Yes, that's a lot. > > Fwiw, that covers a year of low-end VPS hosting for the main > public-inbox.org/git machine + mail host > (~1GB git objects + ~3GB Xapian index). > >> The site does see a lot of hits, but most of the content is a few basic >> web pages, and copies of other static content that is updated >> only occasionally (manpage content, lists of downloads, etc). The biggest >> dynamic component is the site search, I think. > > Maybe optimize search if that's slowest, first. public-inbox > uses per-host Xapian indexes so there's no extra network latency > and it seems to work well. But maybe you don't get FS write > access without full VPS access on Heroku... > > nginx handles static content easily, and since it looks like you > guys use unicorn[*] for running the Ruby part. I really hope > nginx is in front of unicorn, since (AFAIK) Heroku doesn't put > nginx in front of it by default. > > > [*] I wrote and maintain unicorn; and have not yet recommended > any reverse proxy besides nginx to buffer for it. > However, having varnish or any other caching layer in > between nginx and unicorn is great, too. I dunno how Heroku > (or any proprietary deployment systems) handle it, though. > >> I do wonder if there's room for improvement either: >> >> - by measuring and optimizing the Heroku deploy. I have no idea about >> scaling Rails or Heroku apps. Do we really need three expensive >> dynos, or a $50/mo database plan? I'm not even sure what to measure, >> or how. There are some analytics on the site, but I don't have >> access to them (I could probably dig around for access if there was >> somebody who actually knew how to do something productive with >> them). > > I track down the most expensive requests in per-request timing > logs and work on profiling + optimizations from there... > Nothing fancy and no relying on proprietary tools like NewRelic. > > I also watch for queueing in listen socket backlog (with > raindrops <https://raindrops-demo.bogomips.org/> or ss(8) to > notice overloading. Again, I don't know how much visibility > you have with Heroku. > >> - by moving to a simpler model. I wonder if we could build the site >> once and then deploy a more static variant of it to a cheaper >> hosting platform. I'm not really sure what our options would be, how >> much work it would take to do the conversion, and if we'd lose any >> functionality. > > *shrug* That'd be more work, at least. I'd figure out what's > slow, first. > > Fwiw, Varnish definitely helps public-inbox when slammed by > HN/Reddit traffic. It's great as long as you don't have > per-user data to invalidate, which seems to be the case for > git-scm. > >> If anybody is interested in tackling a project like this, let me know, >> and I can try to provide access to whatever parts are needed. > > While I'm not up-to-date with modern Rails or deployment stuff, > I'm available via email if you have any lower-level > Ruby/unicorn/nginx-related questions. I'm sure GitHub/GitLab > also has folks familiar with nginx+unicorn deployment on > bare metal or VPS who could also help.