Roughly 2000 blogs running on a $7/month dyno
Bear Blog (https://bearblog.dev) has just hit 2000 blogs.
Due to the optimization of DB calls, the text-only content (no static files) and Cloudflare's awesome CDN, my single Heroku dyno is running at only 31% capacity.
Full stack: - Django/python running on a Hobby dyno - All HTML content is generated using Django templates - Postgres also on a Hobby dyno - Cloudflare CDN (free) - Sendgrid for confirmation emails - LetsEncrypt SSL certs
Thought this may be interesting :)
64 comments
[ 17.1 ms ] story [ 1302 ms ] threadJust ship on heroku and you're done.
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.
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.
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.
I was taking this into account in my figures.
It’s the rate of requests it can handle that matters, which may explain why I’m getting an “Application error” page at the moment
Hugged to death already.
"leopards eating my face" - HermanMartinus
Also down for me currently.. interested to know which resource was exhausted :)
Unless it's a hobby site offering a free service, which this seems to be.
Projects like this are awesome, and the barrier to making them should be low — gatekeeping by the community like this project needs to have a five nines SLA is frankly counterproductive.
Thanks :)
Seriously, there’s been literally hundreds of blog-hosting websites. If you really thought none of them were backed by a DB, I’m not sure what to say. It’s not like “optimizing DB calls” is an original idea. It’s probably something 50% of all software engineers have spent some time on. Whether one works for google, facebook, amazon, apple or microsoft, I can guarantee you that if they’ve been on the job for long enough, at some point in their career they had to “optimize expensive calls”
Now, I don’t want to just be an asshole. I think it’s really cool to start something from scratch and push it out there. I, for one, never really got myself to do it. And I think the grit is harder to acquire than the technical skills. Just be careful of not overestimating your real skills, it can be a great turn-off for any half-competent professional who might be considering joining you in a future venture
(It didn't crash though, but it's also not 2k blog instances. It runs on the cheapest digital ocean offering)
It looks like it's back up now.
If I get into blogging again I might try this.