5 ms·

If it wasn't for Haskell's IHP framework then Django, Ruby on Rails and CakePHP would be fighting to come dead last in the techempower composite benchmark https

If it wasn't for Haskell's IHP framework then Django, Ruby on Rails and CakePHP would be fighting to come dead last in the techempower composite benchmark https://www.techempower.com/benchmarks/#section=data-r20&hw=ph&test=composite https://www.techempower.com/benchmarks/#section=data-r20&hw=... Django, RoR - they're almost 2 orders of magnitude behind the fastest frameworks on the composite test and they're an order of magnitude behind the majority of Java / Go - i was going to say C# here but i see asp.net is much faster than the surprisingly homogenous performing "usual suspects" of enterprise web frameworks. And yet, if i had to launch a site tomorrow, it'd be Django i'd reach for - and with zero hesitation. Instagram, Youtube, Github, Facebook, Dropbox etc. etc. all launched on these "slowest of the slow" stacks and then optimised. Did anyone start out on a lithium (c++) or actix (rust) or other incredibly high performance stack? This is all a big diversion anyway, I think these benchmarks measure the wrong thing entirely. Instead - show me some measure of how easy & cheap it will be for me to change or add a behaviour to my site 3 years down the road if i've stuck to the prescribed idiomatic approach.

brianwawok 6y ago
Some of it may be B2B vs B2C, and volume of usage. I am B2B. My server costs are like 1% of my revenue using Django. Okay, I could shrink this by 95% by using raw C.. but who cares? Now if I were an image hosting CDN and Django bill was 50% of my revenue.. it might be a different story. I think it's the classic right tool for the right job story..
- kasey_junk 6y ago
  You are a veteran performance software engineer, besides your entrepreneurial bona fides. What is the number you start migrating off django? What is the number you wished you’d picked something else? Is there a value to Django you could have got with a different Lang without the downside?
travisjungroth 6y ago
I’m tempted to go FastAPI over Django on my next project, even though I’ve been a big Django user. A little more performance and a little less coupling, and maybe you can survive longer as a Python monolith. Then convert to Rust/Go/something in the unlikely event of wild success.
- maxs 6y ago
  Why do you think it reduces coupling? You can use Django apps to have decoupled Django services that all run in the same gunicorn webserver
  - travisjungroth 6y ago
    I mean less logical coupling inside the app. It's more in the family of a collection of libraries versus a batteries included framework. I'm considering that may be the best of both worlds. I never really liked the recreating the universe feeling of Flask.
- Daishiman 6y ago
  Why? The FastAPI library ecosystem is anemic. Django is fast enough. You'll be spending at most a fraction of an FTE salary in hosting even with the best of success, and if it comes to more than that, you'll be likely paying for a DBA or for an improved caching strategy for performance.
  - travisjungroth 6y ago
    > The FastAPI library ecosystem is anemic. That's kinda the point. If your business is making webapps for clients, the fact that you can pip install django-half-the-feature is awesome. What you trade for that is a big dependency tree whose packages sometimes snake their way through your whole codebase, since it's all Django anyway. FastAPI is its own thing, but it's also heavily based on some other big libraries that also have their own support. And anyway, what I was saying about performance and decoupling are probably just rationalizations. I focus on writing APIs, and that looks nicer to do in FastAPI than how I've done it in Django. I also really like type hinting, and that's a big part of things. Right now, I'd just like to write more Python and less Django.
    - ryanisnan 6y ago
      The biggest challenge I encountered when doing this exact thing was once you get beyond bootstrapping the project, and start implementing your first feature. Great, you need an ORM, what do you choose? Now you need a serializer, what do you choose? What about validation, what do you choose? Authentication, what do you choose? A lot of these questions are boring and are not worth spending time thinking about. Almost all choices will leave you with some amount of headaches though (as will choosing Django). The question to me boils down to... what questions am I interested in solving?
ericholscher 6y ago
We serve one of the largest sites on the internet (top 2,000 last time that alexa's top sites worked, 25k requests per minute) with Django and a tiny web server budget (~$1k/mo). We serve mostly static files, but all requests hit Django at least 2-3 times. If it works for us, it will work for you :)
Nextgrid 6y ago
Django (and pretty much any other framework) is usually "fast enough"; typically you'll hit the limits of your datastore first, and even if you reach the point where the framework becomes an issue it's trivial to scale horizontally due to its stateless nature.
- sethhochberg 6y ago
  Yup, same story on Ruby/Rails. Yes, its true that our median response times could be faster if we spent less time on Ruby CPU burn. But its also true that this improvement would still be a rounding error for many of our slowest requests, which are dominated by calls to databases, external services over HTTP, or both.
- throwaway189262 6y ago
  I hear this all the time but in most of our apps average query time is less than 5ms in postgres. And it scales with threads, so it's more like 30k queries per second. We have a single Postgres instance and serve thousands of requests per second. You're going to be scaling Django way before that.
khrbrt 6y ago
I've never used Django, but is it really that much easier to manage than a modern Java framework like SpringBoot or Quarkus? It's pretty fast to throw up a REST endpoint, and annotations have replaced much of the old boilerplate.
- sidlls 6y ago
  Yes, it really is. SpringBoot especially has so much unnecessary complexity built in. I'd dread having to debug any non-trivial application written using any of the most popular Java frameworks.
  - Daishiman 6y ago
    I've recently had to patch a site built on Spring Boot. Coming from Django, it's a disaster. Spring Boot basically attempts to turn Java from its statically compiled origins to an annotation-ladled mess full of runtime reflections and compiler pluginitis. If you're doing that, why not just go the whole hog and use an actually dynamic language and a framework that plays up the language's strengths instead of working _around_ it?
  - throwaway189262 6y ago
    Debugging Spring is easy if you know the framework well. That's true for any framework
    - sidlls 6y ago
      I don't find following stack traces through a bramble patch of annotation laden garbage calls and pointless abstractions to be a good fit for the word "easy." SpringBoot epitomizes the worst of the marriage between an OO fetishist and an enterprise "architect."
- bsder 6y ago
  I wanted to put together an API to open our front door from our phones. I spent way more time putting the phone app together than popping open a VPS, installing Django and the Django Rest Framework, and coding to handle the requests. Django is stupidly quick to do "standard" things. And Django's "standard" extends a long way. And Django understands a lot more about "standard" than you do until you've been coding your app for a while. Yes, Django and Python are a bit "boring" today. For those of us with a job to do rather than resumes to build, that's what we need.
collinmanderson 6y ago
Looking techempower's benchmark code, specifically the "dbs" and "update" functions (which are weighted highly), I think there's some optimization that could be done, like using .values() and .update() in more places. https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/frameworks/Python/django/hello/world/views.py https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast... Django ends up getting benchmarked against "uvicorn" which just uses raw sql, so yeah, of course raw sql is faster. Django has a raw sql option too, but they're not using it for the benchmark. https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/frameworks/Python/uvicorn/app.py https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast...
- throwaway189262 6y ago
  In Java at least, the massive Hibernate ORM is only about twice as slow as raw SQL. Which is still orders of magnitude faster than Django. The lack of performance is far deeper than ORM usage.

brianwawok 6y ago

Some of it may be B2B vs B2C, and volume of usage. I am B2B. My server costs are like 1% of my revenue using Django. Okay, I could shrink this by 95% by using raw C.. but who cares? Now if I were an image hosting CDN and Django bill was 50% of my revenue.. it might be a different story. I think it's the classic right tool for the right job story..

kasey_junk 6y ago
You are a veteran performance software engineer, besides your entrepreneurial bona fides. What is the number you start migrating off django? What is the number you wished you’d picked something else? Is there a value to Django you could have got with a different Lang without the downside?

travisjungroth 6y ago

I’m tempted to go FastAPI over Django on my next project, even though I’ve been a big Django user. A little more performance and a little less coupling, and maybe you can survive longer as a Python monolith. Then convert to Rust/Go/something in the unlikely event of wild success.

maxs 6y ago
Why do you think it reduces coupling? You can use Django apps to have decoupled Django services that all run in the same gunicorn webserver
- travisjungroth 6y ago
  I mean less logical coupling inside the app. It's more in the family of a collection of libraries versus a batteries included framework. I'm considering that may be the best of both worlds. I never really liked the recreating the universe feeling of Flask.
Daishiman 6y ago
Why? The FastAPI library ecosystem is anemic. Django is fast enough. You'll be spending at most a fraction of an FTE salary in hosting even with the best of success, and if it comes to more than that, you'll be likely paying for a DBA or for an improved caching strategy for performance.
- travisjungroth 6y ago
  > The FastAPI library ecosystem is anemic. That's kinda the point. If your business is making webapps for clients, the fact that you can pip install django-half-the-feature is awesome. What you trade for that is a big dependency tree whose packages sometimes snake their way through your whole codebase, since it's all Django anyway. FastAPI is its own thing, but it's also heavily based on some other big libraries that also have their own support. And anyway, what I was saying about performance and decoupling are probably just rationalizations. I focus on writing APIs, and that looks nicer to do in FastAPI than how I've done it in Django. I also really like type hinting, and that's a big part of things. Right now, I'd just like to write more Python and less Django.
  - ryanisnan 6y ago
    The biggest challenge I encountered when doing this exact thing was once you get beyond bootstrapping the project, and start implementing your first feature. Great, you need an ORM, what do you choose? Now you need a serializer, what do you choose? What about validation, what do you choose? Authentication, what do you choose? A lot of these questions are boring and are not worth spending time thinking about. Almost all choices will leave you with some amount of headaches though (as will choosing Django). The question to me boils down to... what questions am I interested in solving?

ericholscher 6y ago

We serve one of the largest sites on the internet (top 2,000 last time that alexa's top sites worked, 25k requests per minute) with Django and a tiny web server budget (~$1k/mo). We serve mostly static files, but all requests hit Django at least 2-3 times. If it works for us, it will work for you :)

Nextgrid 6y ago

Django (and pretty much any other framework) is usually "fast enough"; typically you'll hit the limits of your datastore first, and even if you reach the point where the framework becomes an issue it's trivial to scale horizontally due to its stateless nature.

sethhochberg 6y ago
Yup, same story on Ruby/Rails. Yes, its true that our median response times could be faster if we spent less time on Ruby CPU burn. But its also true that this improvement would still be a rounding error for many of our slowest requests, which are dominated by calls to databases, external services over HTTP, or both.
throwaway189262 6y ago
I hear this all the time but in most of our apps average query time is less than 5ms in postgres. And it scales with threads, so it's more like 30k queries per second. We have a single Postgres instance and serve thousands of requests per second. You're going to be scaling Django way before that.

khrbrt 6y ago

I've never used Django, but is it really that much easier to manage than a modern Java framework like SpringBoot or Quarkus? It's pretty fast to throw up a REST endpoint, and annotations have replaced much of the old boilerplate.

sidlls 6y ago
Yes, it really is. SpringBoot especially has so much unnecessary complexity built in. I'd dread having to debug any non-trivial application written using any of the most popular Java frameworks.
- Daishiman 6y ago
  I've recently had to patch a site built on Spring Boot. Coming from Django, it's a disaster. Spring Boot basically attempts to turn Java from its statically compiled origins to an annotation-ladled mess full of runtime reflections and compiler pluginitis. If you're doing that, why not just go the whole hog and use an actually dynamic language and a framework that plays up the language's strengths instead of working _around_ it?
- throwaway189262 6y ago
  Debugging Spring is easy if you know the framework well. That's true for any framework
  - sidlls 6y ago
    I don't find following stack traces through a bramble patch of annotation laden garbage calls and pointless abstractions to be a good fit for the word "easy." SpringBoot epitomizes the worst of the marriage between an OO fetishist and an enterprise "architect."
bsder 6y ago
I wanted to put together an API to open our front door from our phones. I spent way more time putting the phone app together than popping open a VPS, installing Django and the Django Rest Framework, and coding to handle the requests. Django is stupidly quick to do "standard" things. And Django's "standard" extends a long way. And Django understands a lot more about "standard" than you do until you've been coding your app for a while. Yes, Django and Python are a bit "boring" today. For those of us with a job to do rather than resumes to build, that's what we need.

collinmanderson 6y ago

Looking techempower's benchmark code, specifically the "dbs" and "update" functions (which are weighted highly), I think there's some optimization that could be done, like using .values() and .update() in more places. https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/frameworks/Python/django/hello/world/views.py https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast... Django ends up getting benchmarked against "uvicorn" which just uses raw sql, so yeah, of course raw sql is faster. Django has a raw sql option too, but they're not using it for the benchmark. https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/frameworks/Python/uvicorn/app.py https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast...

throwaway189262 6y ago
In Java at least, the massive Hibernate ORM is only about twice as slow as raw SQL. Which is still orders of magnitude faster than Django. The lack of performance is far deeper than ORM usage.