|
|
|
|
|
by rtpg
411 days ago
|
|
Regarding the slowness, I think it's super important when working with slow stuff like Django to have good SLOs in your head. "Home page should load under 2 seconds at P95", "reports should load under 10 seconds at P99", "this background task should take under 30 seconds at P99". Having these targets (and, frankly, remembering in the B2B space is that the status quo is _so slow_) can let you set performance objectives without chasing milliseconds that you don't need to. Django has a lot of intrinsic slowness to it, "easy" DB access patterns often lead to heavy messes, but if at the end of the day most customers are getting served under some benchmark you can reap the advantages of the tooling without sweating perf too much. And when you set these SLOs, you can then push for even tighter ones as you figure out your problem space! In the B2B space companies get away with _so much_ sluggish behavior, if you're better than the median that's already improving things. |
|
Things we did: careful about N+1 queries, caching where obvious, API calls/emails/etc running in background queues.
Things we didn’t do: use a fast templating language (we used Django’s built in one and it was often our bottleneck), removing all database queries (we just had Postgres <2ms latency away), renormalising data (we were highly relational for most things).
Django is perfectly performant enough for almost all use cases, and insanely fast to develop with.