Медленный Memcached: Средние 10 мс memcached 'добираются'

Первое, что приходит на ум: используете ли вы полное доменное имя / DNS для установления соединения с сервером кэша памяти или используете IP-адрес или локальный сокет?

Если вы используете используя имя хоста, вы можете потерять некоторое время при разрешении имен.

Попробуйте либо поместить полное доменное имя в файл / etc / hosts клиентов и серверов и перезапустить его, чтобы ничего не кэшировалось, либо измените ссылку на IP-адрес. , и посмотрите, не заметите ли вы улучшения.

Пока что мои исследования показывают, что 10 мс - это "медленно" . Под этим я подразумеваю, что сами документы кэша памяти ссылаются на суб 1 мс раз как «ожидаемые». Таким образом, время отклика, которое мы наблюдаем, на порядок ниже.

Чего ожидать от производительности: https://code.google.com/p/memcached/wiki/NewPerformance

"Вероятный виновниками "медленных ответов memcached являются (в грубом порядке вероятности):

1. плохой дизайн приложения (или ошибка)
2. перегрузка сети
3. подкачка
4. высокая загрузка ЦП из приложений-со-арендаторов
5. достижение какого-то максимального количества соединений
6. постоянные межсетевые экраны
7. неверные конфигурации TCP

Я решил почти все из них следующим образом:

1. Согласно memcached-top ( https://code.google.com/p/memcache-top / ) мы получаем примерно такое же время подключения от нашего приложения, что и при запуске brutis ( https://code.google.com/p/brutis/ ) из те же самые серверы приложений.
2. Время отклика остается неизменным в течение дня, несмотря на то, что наша система имеет четкое время пиковой нагрузки; время отклика никогда не бывает "резким", как можно было бы ожидать, если бы это было проблемой перегрузки. / sbin / sysctl -w net.ipv4.tcp_tw_reuse = 1 / sbin / sysctl -w net.ipv4.tcp_fin_timeout = 10

Без изменений.

Мы в основном не можем диагностировать эту проблему. Мы приближаемся к моменту «установить Redis» и надеемся, что он работает лучше.

Я заметил 2 вещи. Коэффициент попадания очень низкий, должен быть как можно ближе к 100 процентам. У вас есть более 200 МБ свободной памяти, которую вы можете использовать для memcached.

Я обнаружил, что запись происходит быстро, одиночное чтение - безумно медленное, а буферизованное чтение - очень-очень быстрое. Вам нужно выполнить буферизованное чтение с помощью get_many, передав массив ключей, которые вы хотите получить. Вот мой тест:

1. ЗАПИШИТЕ 100000 записывается (один за другим, но, вероятно, буферизуется за кулисами) за 0,42605304718 секунд, 234712 в секунду

2. ЧИТАТЬ 100000 с размером сегмента = 10000 читать (много) за 0,651949167252 секунды, 153386 в секунду

3. ЧИТАТЬ 100000 по одному читать (один) за 86,2907109261 секунду, 1158 в секунду

В моем случае я использую python с pymemcache.

Я только что выполнил очистку memcached, поэтому решил опубликовать пример вывода того, что, как мне кажется, работает. Новая реликвия сообщает о 10,4 мс, потраченных в memcached, поэтому я думаю, что это подсчет нескольких вызовов. Вы работаете на голом железе или виртуально, если вас волнует скорость, тогда виртуальный - не выход ( http://redis.io/topics/benchmarks )

memcache-top v0.6   (default port: 11211, color: on, refresh: 3 seconds)

    INSTANCE        USAGE   HIT %   CONN    TIME    EVICT/s READ/s  WRITE/s 
    app01:11211     0.5%    49.8%   2994    0.7ms   0.0 75.2K   378.5K  
    app02:11211     0.5%    51.7%   2992    0.7ms   0.0 76.5K   143.9K  
    app03:11211     1.0%    69.6%   1469    0.7ms   0.0 42.0K   161.3K  
    app04:11211     2.0%    52.6%   801 0.5ms   0.0 66.0K   415.9K  
    app05:11211     2.2%    52.5%   801 0.4ms   0.0 71.9K   171.2K  
    app06:11211     2.0%    66.4%   800 0.5ms   0.0 135.9K  180.4K  
    app07:11211     1.9%    52.0%   800 0.6ms   0.0 65.5K   482.4K  
    app08:11211     1.1%    87.1%   1469    0.7ms   0.0 59.3K   365.3K  
    db01:11211      1.0%    82.4%   1469    0.5ms   0.0 64.6K   155.4K  
    elastic01:11211     1.7%    69.9%   737 0.5ms   0.0 44.2K   128.8K  
    elastic02:11211     1.7%    65.0%   737 0.5ms   0.0 48.2K   155.8K  
    elastic03:11211     1.8%    68.3%   737 0.6ms   0.0 24.5K   115.7K  
    elastic04:11211     1.8%    69.5%   737 0.7ms   0.0 95.3K   158.0K  

    AVERAGE:        1.5%    64.4%   1272    0.6ms   0.0 66.9K   231.7K  

    TOTAL:      12.1GB/ 1.0TB       16.2K   7.6ms   0.0 869.1K  2.9M    
    (ctrl-c to quit.)

Проблема с django и memcached в том, что они устанавливают соединение при каждом запросе. Так что часть этого времени составляет время установки соединения.

Это зависит от того, какое связывание кэша памяти вы используете. Но вы можете поместить что-то подобное в ваш wsgi.py

# Fix django closing connection to memcached after every request (#11331)
from django.core.cache.backends.memcached import BaseMemcachedCache
BaseMemcachedCache.close = lambda self, **kwargs: None

В основном обезьяна исправляет обработчик закрытия, чтобы не закрывать.

Если это не сработает, замените свой класс memcached.

Я заметил в верхнем выводе, что вы используете пространство подкачки. Вам нужно заставить его перестать обмениваться местами. Своп убивает производительность memcached.