Блог ищущего программиста

Быстрый memcached для python и django

memcachedТак получилось, что нагрузка на VDS выросла. Django кушает ресурсов достаточно хорошо. И я переехал на новый. Памяти в нем оказалось 8Гб, что позволило хорошо развернуться. Для разгрузки я раньше использовал memcached и самую распространенную библиотеку для него — pylibmc — типовая связка, которая описывается везде. Но как-то для кэширования разовых запросов производительность его по сравнению с кэшем mariaDB меня не устраивала. Запрос из кэша БД выполнялся 0.1-0.5мс (десяток записей), а из мемкэша 0.7-1. Это я замерил полноценно, подключив New Relic — замечательное средство мониторинга, но стоит достаточно дорого. Правда есть триальные 2 недели, которыми я и воспользовался.

Итак. по теме:

Я конечно понимал, что проблема медлительности мемкеша в необходимости постоянных соединений. И решил поискать модуль с пулом. Он нашелся довольно быстро — django-memcached-pool. И базируется он на umemcache. Вот так все просто оказалось. Самое удивительное, что на русском языке я информации не нашел. Замена модулей дала ускорение memcached до 0.05-0.2мс на тех же данных, что вполне хорошо. Хотя может все это прирост umemcache, так как все на одном сервере.

Подключается все как обычно:

pip install django-memcached-pool

А в конфигурации джанго-проекта нужно указать:

CACHES = {
'default': {
'BACKEND': 'memcachepool.cache.UMemcacheCache',
'LOCATION': '127.0.0.1:11211',
'OPTIONS': {
'MAX_POOL_SIZE': 100,
'BLACKLIST_TIME': 20,
'SOCKET_TIMEOUT': 5,
'MAX_ITEM_SIZE': 1000*100,
}
}
}

Когда все устаканилось, я посмотрел на графики. Memcache уже не так выигрывал mysql. Разница в основном за счет запросов с JOINами и некешированных у последнего. На pylibmc среднее было 0.7мс. Пик ближе к концу — это Cron-задание, нагружающее процессор на максимум. Да и БД подгружает тоже. В итоге использую memcache для разгрузки БД, так как ее время доступа зависит от большего количества факторов. После кэширования части данных, провалов Apdex (процент запросов, укладывающихся в лимит) стало намного меньше.mariaDB (mysql) vs memcached

Все же основания нагрузка в django на БД и шаблонизатор. Значит, самое основное действие — увеличение количества ядер. Можно конечно заменить шаблонизатор на jinja, но не особо хочется этого делать. И переписать основные запросы без использования ORM. Если будет не лень, проверю прирост.django-нагрузка: код и БД
К слову, пробовал levelDB. Синтетический тест показал почти 100к записей и 350к чтений в секунду. Правда она файловая и не многопоточная. Но для одной задачи, где нужно хранить и обновлять много миллионов записей, а затем получать по ним сводку, вполне подошла. ОЗУ для этой цели не подходит, так как первичное заполнение очень долгое. Пробовал Redis, опять же, почему-то у меня он оказался медленнее mysql. Memcache не подходит в силу того, что это кэш. С тарантулом опять какие-то проблемы с адаптером для питона. Разбираться не стал, отложил до лучших времен. Другие Key-Value пока не пробовал.

Опубликовал 1st Май 2014.
Размещено в MySQL, Web, Инструменты.
.

Ранее в этой же рубрике:




Оставить комментарий или два

33 - здесь у нас SQL запросов.
0,039891 - время на генерацию страницы.