Why is Python Django 1.8.4 heavy on CP?

Question

Django

Good day everyone! or evenings! I started learning Django not long ago, and it was a surprise to me to see the load on the server, with such a small visit: 200-500 users
30-80 CP! (Hosting beget CPU`S: 56 * Intel(R) Xeon(R) CPU E5-2697 v3 @ 2.60GHz)
No caching per visit 0.3CP!
I set up caching of the entire site,
in view I set up a cache for each view
in models I update the cache using signals
The result did not satisfy me at all ~ 0.15CP per visit, this is also a lot if the attendance is from 200-500 unique visitors per day cpu = (250 people) * (0.15 time spent by one percent) = 37! with an allowable per day of 65. And this is if you configure the cache manually, if you use cache-macine, django-redis with all the goodies, then only the speed of returning the content increases, while the load remains the same as without the cache
The load on the database is almost missing
Here are my settings and connected apps:

INSTALLED_APPS = [
    'cmksite',
    'suit',
    'ckeditor',
    'filebrowser',
    'django.contrib.auth',
    'django.contrib.admin',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    'debug_toolbar',
]

MIDDLEWARE_CLASSES = [
    'django.middleware.cache.UpdateCacheMiddleware',
    'django.middleware.security.SecurityMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'debug_toolbar.middleware.DebugToolbarMiddleware',#debug
    'django.contrib.auth.middleware.SessionAuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    'django.middleware.clickjacking.XFrameOptionsMiddleware',
    'django.middleware.cache.FetchFromCacheMiddleware',
]

TEMPLATES = [
    {
        'BACKEND': 'django.template.backends.django.DjangoTemplates',
        'DIRS': [
                os.path.join(BASE_DIR, 'templates'),
                os.path.join(BASE_DIR, 'cmksite/templates'),
                'Django.template.loaders.filesystem.Loader',
                'django.template.loaders.app_directories.Loader',
        ],
        'APP_DIRS': True,
        'OPTIONS': {
            'context_processors': [
                'django.template.context_processors.debug',
                'django.template.context_processors.request',
                'django.core.context_processors.request',
                'django.contrib.auth.context_processors.auth',
                'django.contrib.messages.context_processors.messages',
                'django.core.context_processors.media',
            ],
        },
    },
]
CACHE_MIDDLEWARE_SECONDS = 86400
CACHES = {
    'default': {
    'BACKEND': 'django.core.cache.backends.filebased.FileBasedCache',
    'LOCATION': os.path.join(BASE_DIR, 'mem_cache'),
     'MAX_ENTRIES': 5000,
    },
}
CACHE_MACHINE_USE_REDIS = True #http://niwinz.github.io/django-redis/latest/
REDIS_BACKEND = 'redis://localhost:6379'

I use WSGI and Apace
This is my first project on django, and if you take the same WORDPRESS without caching per day with the same load, a maximum of 3 CP.
Tell me what's the problem?

Answer 1

1) I have never used FileBasedCache, but I am almost sure that it should be thrown away. The cache should be fast, not slightly faster than the base (besides, compete with the base). Install memcached (or Redis)
2) Install nginx instead of Apache
3) Do you distribute statics with Apache?
4)

I use WSGI

this is great, but obvious. What are you using as your web server? uWSGI or Gunicorn?
My blog is running on Raspberry Pi version 1 (which is 700 MHz and one core) and can handle up to 25 requests per second. I'm not talking about DO (the very first tariff for 5 bucks with one core), where ab issues ~ 140-170 requests per second on more or less static sites.

Answer 2

First, look in the logs for what queries you have to the database:
Optimize queries:
select_related

Answer 3

Some strange reasoning. At least pull ab , see how much RPS gives out, whether the percentage is loaded at the same time. Then figure out what slows you down, the base or templates.

Answer 4

most likely the case is in uWSGI if you are talking about it. Recently had an experience setting it up for a php project. on a hundred threads CPU1: Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz (Cores 8)
Memory: 64157 MB + SSD
so on 100 threads ab all cores are 100%
, despite the fact that the cmska cached everything maliciously. And the download is on the web server.
php-fpm with a similar configuration kept something around 350 and the percentage did not choke.
And yes, nginx distributed the statics.
I wrote to them on github, they sent them to hell ... They said it was unrepresentative.