There's a lot of confysion about Python's threading model and - for example - GIL impact on performance of Python apps.
That's why you should be very careful when diagnosing threading-performance problems in Python. Googling things or asking around can lead you to wrong conclusions. It's better to test things by yourself.
Here is an example of such problem: performance problems with django runserver development server mode. Documentation clearly states that this mode shouldn't be used on production server, and mentions that this method is not that much audited and reviewed for security and performance.
However, it forgets to mention that runserver mode is completely single-threaded. It processes one request at a time. If you have multiple elements on each page (for example many CSS files, or some dynamic JavaScript elements) then your pages will load very long. Any long-running operation (for example - waiting for database output after expensive query) will completely freeze your application and other clients will have to wait after database finishes it's calculations.
There's simple way to test it: create django application with simple view that
returns static text.
You won't even need any models for that. Add a single time.sleep(20) before
final return statement in your view.
Then run your django with python manage.py runserver 127.0.0.1:8080
and open (as quickly as you can) your view in
two tabs. Then watch how long does it take for tabs to load. First
one will load after 20 seconds, meaning that first request was
received and processed as soon you entered url in your browser. But the second
one will load after almost 40 seconds, because processing of second request started
after first request was finished. On trully multithreaded application there's no problem
with two threads sleeping (or waiting for data on socket).
Someone might tell you that Python's GIL or database driver code makes it practically single-threaded. Well, this is a common myth that GIL really matters or is practically visible. It's very hard to see GIL-related problems in reallife. Basically, GIL might be described without going into details as a performance problem on multiprocessor machines. It's usually invisible on single-processor machines and it's very likely that it won't be visible on your multi-processor machine if there are any other processes on it.
But GIL is so famous, that everybody who knows about it must always share their knowlege and blame almost everything on it.
So, if you really think you might be getting into GIL-related problem, please save yourself some time and test it properly.