5 ms·

It's been sitting at about 300k pageviews a month, which is not that much considering. If there are high-profile blogs running I may have to consider upgrading.

chrismorgan 6y ago
That’s an average of about one request every 8 seconds. That that should be 31% capacity, I find alarming: it’d suggest that each page view is consuming more than two seconds of available system resources, which… wow. (My interpretation of your stated “31% capacity” could be way off base, but if I try to be as generous as I can imagine, this figure would still be comfortably within a decimal order of magnitude.) I would expect something fairly basic with no obvious errors to be able to cope with ten times this load with perfect equanimity, and something that claimed to be pretty efficient while still being Django/Postgres to support at least a hundred times this load, perhaps even a thousand; and if it behaved like a static site generator and produced stuff nginx could serve directly, it’d probably handle between ten and a hundred thousand times the load. (I say all this with no knowledge of the performance/load characteristics of Heroku, but assuming that each Hobby dyno is roughly equivalent to the average $5/month VPS. I could be completely wrong.) These figures I’m estimating also assume that all requests make it to the origin server; if you add Cloudflare to the mix and set your caching properly—and this site should be extremely amenable to aggressive caching—you should be able to drastically reduce the number of requests that make it to the origin server, especially on popular articles. In short: these numbers aren’t adding up to me, so I suspect that either I’ve misunderstood or misinterpreted something, or there’s some simple low-hanging performance fruit to pick, some simple misconfiguration of e.g. template or data caching or DB connection pooling or something.
- mping 6y ago
  You know that joke, Bill Gates walks into a bar and suddenly everyone's average worth is >1Million? Hehehe. My guess is that 300k pvs mostly follow daylight probably on North America only. So you probably have peaks around 21-23 and almost nothing between 01-08am. And of course, if you write it in C these numbers look awful, but I'd say for run-of-the-mill django they are quite good. I'm willing to bet most django sites you find on heroku free tier don't handle this kind of pressure.
  - chrismorgan 6y ago
    I included that very matter in the order of magnitude flexibility, since I’m not sure what “31% capacity” actually means. Even being as generous as I can imagine, that’s still each request consuming over 200ms of system resources, which for something like this would be terrible. It’s some years since I’ve done any Django, but I remember measuring a fairly simple django CMS installation (which is waaaay more complex than this) in 2013 taking 50–80ms to serve most pages, with the slowest page averaging something like 180ms; my recollection is that I took those measurements before doing any deliberate performance tuning (I don’t think I’d put the cached template loader in yet—it wasn’t in the default config back then—and I think it may have even not been doing connection pooling). Given the scope of this app, I figure it should be doing one or two simple and well-indexed SELECT queries only, and maybe an INSERT or UPDATE for analytics, but nothing more with its database. I would think 20ms should be oodles of time to do everything even in Django.
- neurostimulant 6y ago
  Traffics are peaky. On sites that I manage, the traffic peaks at around afternoon, about 4x higher than the traffic at around midnight. Also, pageviews doesn't includes static assets, which can be as large as 100 static files per pageview on an unoptimized website. 31% capacity during peak is believable to me.
  - chrismorgan 6y ago
    For this particular site, it has no JavaScript and all CSS is inline. Each page load is three requests: one for the HTML, one for a simple behavioural analytics tracker: <style> body:hover { background: url("/hit/12345"); } </style> And one more because the author was careless with the URLs, and /hit/12345 does a 301 → /hit/12345/ which is the actual thing. I was taking this into account in my figures.

chrismorgan 6y ago

That’s an average of about one request every 8 seconds. That that should be 31% capacity, I find alarming: it’d suggest that each page view is consuming more than two seconds of available system resources, which… wow. (My interpretation of your stated “31% capacity” could be way off base, but if I try to be as generous as I can imagine, this figure would still be comfortably within a decimal order of magnitude.) I would expect something fairly basic with no obvious errors to be able to cope with ten times this load with perfect equanimity, and something that claimed to be pretty efficient while still being Django/Postgres to support at least a hundred times this load, perhaps even a thousand; and if it behaved like a static site generator and produced stuff nginx could serve directly, it’d probably handle between ten and a hundred thousand times the load. (I say all this with no knowledge of the performance/load characteristics of Heroku, but assuming that each Hobby dyno is roughly equivalent to the average $5/month VPS. I could be completely wrong.) These figures I’m estimating also assume that all requests make it to the origin server; if you add Cloudflare to the mix and set your caching properly—and this site should be extremely amenable to aggressive caching—you should be able to drastically reduce the number of requests that make it to the origin server, especially on popular articles. In short: these numbers aren’t adding up to me, so I suspect that either I’ve misunderstood or misinterpreted something, or there’s some simple low-hanging performance fruit to pick, some simple misconfiguration of e.g. template or data caching or DB connection pooling or something.

mping 6y ago
You know that joke, Bill Gates walks into a bar and suddenly everyone's average worth is >1Million? Hehehe. My guess is that 300k pvs mostly follow daylight probably on North America only. So you probably have peaks around 21-23 and almost nothing between 01-08am. And of course, if you write it in C these numbers look awful, but I'd say for run-of-the-mill django they are quite good. I'm willing to bet most django sites you find on heroku free tier don't handle this kind of pressure.
- chrismorgan 6y ago
  I included that very matter in the order of magnitude flexibility, since I’m not sure what “31% capacity” actually means. Even being as generous as I can imagine, that’s still each request consuming over 200ms of system resources, which for something like this would be terrible. It’s some years since I’ve done any Django, but I remember measuring a fairly simple django CMS installation (which is waaaay more complex than this) in 2013 taking 50–80ms to serve most pages, with the slowest page averaging something like 180ms; my recollection is that I took those measurements before doing any deliberate performance tuning (I don’t think I’d put the cached template loader in yet—it wasn’t in the default config back then—and I think it may have even not been doing connection pooling). Given the scope of this app, I figure it should be doing one or two simple and well-indexed SELECT queries only, and maybe an INSERT or UPDATE for analytics, but nothing more with its database. I would think 20ms should be oodles of time to do everything even in Django.
neurostimulant 6y ago
Traffics are peaky. On sites that I manage, the traffic peaks at around afternoon, about 4x higher than the traffic at around midnight. Also, pageviews doesn't includes static assets, which can be as large as 100 static files per pageview on an unoptimized website. 31% capacity during peak is believable to me.
- chrismorgan 6y ago
  For this particular site, it has no JavaScript and all CSS is inline. Each page load is three requests: one for the HTML, one for a simple behavioural analytics tracker: <style> body:hover { background: url("/hit/12345"); } </style> And one more because the author was careless with the URLs, and /hit/12345 does a 301 → /hit/12345/ which is the actual thing. I was taking this into account in my figures.