3 ms·

yes, database and specifically disk i/o is usually our bottleneck. I use newrelic and I can see the time taken of the database vs python. slow page events are

yes, database and specifically disk i/o is usually our bottleneck. I use newrelic and I can see the time taken of the database vs python. slow page events are almost always caused by database bottlenecks. edit: actually the fact that a django response needs to block for the database means that overall concurrency is a serious bottleneck. again, due to database. but it doesn't need to be a bottleneck if the requests didn't have to block. a more modern architecture like scala play! or node.js can serve other trivial requests while the database is still working. with django I have had to have two servers (8 CPU, 12 processes) so that nobody is blocked (eg. for just a trivial serve from cache) just because a few too many requests are needing more database objects for the page they are serving. so this is a django architecture issue.

mattrobenolt 13y ago
We run many more than 12 processes per server. That's how you can get around that. :) But that's frankly more of a Python architecture problem than Django. Django is compatible with coroutine libraries like gevent, just most of the ecosystem is not compatible, so that makes things difficult at the size we're at. Realistically though, this isn't a problem for us and if things are done right, shouldn't be a problem for you either. Just use more processes and you'll be fine unless you're running out of RAM or something.
- deleted 13y ago
  [deleted]
- crucialfelix 13y ago
  how many CPUS and how many processes per machine ? I guess I used to run 8 on a 4 CPU machine. I tried 9-12 processes but it always tripped over itself. > unless you're running out of RAM or something. yep, on the new machines I run 6 just to keep the total memory down. and that also sucks: having to use lots of memory just to get concurrency.
  - mattrobenolt 13y ago
    We run 40 processes on each with 16 cores and 24G of RAM.
hardwaresofton 13y ago
Disk I/O I can definitely believe, but not every request from the DB goes to disk right? especially for in-memory databases Also, I can NEVER explain evented servers adequately when people ask me about them. Especially how an evented server like twisted or tornado or gunicorn work when run from inside python (struggling w/ the GIL). But yes, I didn't even consider that -- all the stuff is synchronous! Amazing that they can handle so many requests with little to no hiccups
- crucialfelix 13y ago
  The issue is that while many requests are very fast to serve from cache, they can get blocked if your limited number of workers get caught handling long ones. If an admin is using a rarely used and inefficient page, or a few too many people are uploading lots of images at once. I have 400 real estate agents, and if they happen to all want to edit their listings at the same time then the customers get frozen out. Varnish would help here.

mattrobenolt 13y ago

We run many more than 12 processes per server. That's how you can get around that. :) But that's frankly more of a Python architecture problem than Django. Django is compatible with coroutine libraries like gevent, just most of the ecosystem is not compatible, so that makes things difficult at the size we're at. Realistically though, this isn't a problem for us and if things are done right, shouldn't be a problem for you either. Just use more processes and you'll be fine unless you're running out of RAM or something.

deleted 13y ago
[deleted]
crucialfelix 13y ago
how many CPUS and how many processes per machine ? I guess I used to run 8 on a 4 CPU machine. I tried 9-12 processes but it always tripped over itself. > unless you're running out of RAM or something. yep, on the new machines I run 6 just to keep the total memory down. and that also sucks: having to use lots of memory just to get concurrency.
- mattrobenolt 13y ago
  We run 40 processes on each with 16 cores and 24G of RAM.

hardwaresofton 13y ago

Disk I/O I can definitely believe, but not every request from the DB goes to disk right? especially for in-memory databases Also, I can NEVER explain evented servers adequately when people ask me about them. Especially how an evented server like twisted or tornado or gunicorn work when run from inside python (struggling w/ the GIL). But yes, I didn't even consider that -- all the stuff is synchronous! Amazing that they can handle so many requests with little to no hiccups

crucialfelix 13y ago
The issue is that while many requests are very fast to serve from cache, they can get blocked if your limited number of workers get caught handling long ones. If an admin is using a rarely used and inefficient page, or a few too many people are uploading lots of images at once. I have 400 real estate agents, and if they happen to all want to edit their listings at the same time then the customers get frozen out. Varnish would help here.