Hacker News Reader

Comment by shakna | Hacker News Reader

Those numbers sound... Single-threaded. Like they're using the development runserver instead of uwsgi or gunicorn.

A $10/month VM might only have a single thread anyway. Some providers like lightsail are really slow too.

You can run multiple OS threads (gunicorn workers) on one VM thread so the workers don’t have to wait for each others request to finish though, right?

And if you pay $10/month for a single threaded machine, you’re overpaying by a lot.

True, but in this case with SQLite, there's unlikely to be much of a difference because there isn't the spare time available when waiting for a separate database server. I don't know what providers are good for a $10/month instance these days.

Most of the time you're hitting SQLite, you're just reading from it, and so it doesn't hold anything up.

How are you spending any non-negligible time reading from SQLite at 12 requests per second though? That would mean you’re spending something like 50 ms per request on reading from SQLite.

For a cheap VM, I'd still be expecting in the range of 500-1000 connections a second. Green threads are cheap, even with a single processor.

For a half-decent VM, I'd be expecting multi-thousand.

Single figures a second, is choked to a single connection at a time.

The $5/month VM I rent has 2 CPUs. And you want to overcommit because of IO blocking.

Anyway, more than a decade ago my django servers could handle close to 10 requests per second on each thread.

Development runserver has been multithreaded by default for over a decade. I think you need to go back to major version 1 to see it single-threaded by default. Maybe affected by the GIL though.

Pretty sure it still defaults to no threading [0], and just uses the plain WSGIServer instead of the threaded mixin.

[0] https://github.com/django/django/blob/main/django/core/serve...

Also, they may be serving static files through Django. Otherwise, it's really, really low.

Reply on news.ycombinator.com