Мне интересно узнать следующие показатели для каждого экземпляра memcached:
У меня есть чувство, что настоящим узким местом будут соединения, но я хотел бы получить информацию от людей, которые установили memcached на своих сайтах.
У меня есть веб-сайт, который за месяц просматривают сотни миллионов страниц. Он распространяется на несколько веб-серверов. Первоначально сайт был написан с использованием кэшированной схемы на основе файлов, которая не использовалась пулом веб-серверов; каждый веб-сервер поддерживает свою кэшированную копию каждой страницы.
По понятным причинам мы переходим на memcached. Мы без проблем преобразовали наши страницы с низким трафиком, но более динамичные (также известные как «страницы с более низким коэффициентом попадания в кеш»). Теперь мы переходим к нашим страницам с более высоким трафиком, но более статичным (также известным как «страницы, которые должны иметь более высокие показатели попадания в кеш»). Сначала мы преобразовали те, которые имеют наименьший трафик, и уже видели скачок с 3,5 тыс. GET в секунду в среднем до 11 тыс. GET в секунду. В среднем в любой момент времени мы видим от 400 до 600 активных подключений. В нашем файле конфигурации ограничение на количество подключений установлено на 4 КБ.
Учитывая, что у нас все еще есть страницы с наибольшим трафиком, которые нужно реализовать, это казалось подходящим временем для исследования допустимых диапазонов и верхних пределов для memcached. Таким образом, мы можем определить, нужно ли нам расширяться до дополнительных экземпляров memcached, прежде чем перемещать части нашего сайта с наибольшим трафиком в memcached. Я понимаю наше использование сейчас не повод для беспокойства, но я хотел бы знать, когда это будет, и хотел бы знать это заранее.
Возможно, лучший способ взглянуть на это - увидеть ваше ограничение производительности при взаимодействии с memcached. Некоторые сценарии для определения среднего времени ответа в течение вашего обычного дня будут хорошим началом.
По вашему основному вопросу:
Я думаю, что в целом количество одновременных действий (получение / установка) будет зависеть от конфигурации вашего оборудования, поэтому любые ответы на это будут субъективными. Я думаю, что нужно найти лучший способ измерить успех относительно вашей собственной среды, чтобы сразу перейти к делу. Как уже отмечалось, стресс-тестирование, естественно, очень важно в этом процессе.
Ура
По моему опыту, количество одновременных подключений важнее, чем количество GET / SET. Я смотрю на исторический график Cacti прямо сейчас, на графике указано, что экземпляр memcached получил около 4 млн обращений в секунду при максимальной (2,8 млн GET и 1,2 млн SET). Я сомневаюсь, что эти цифры реальны. В любом случае они были достигнуты с использованием только одного активного соединения. Проблема заключалась в том, что когда я проводил стресс-тестирование этой установки с помощью инструмента нагрузочного тестирования веб-сайта, memcached начал загружать процессор со скоростью всего около 2–3 тыс. Обращений в секунду. Мне пришлось построить ферму кешей памяти для распределения нагрузки. Как видите, существует нелинейная зависимость между количеством одновременных подключений и количеством обращений в секунду, которые может обрабатывать memcached. Memcached, кажется, начинает быстро ухудшаться при определенном количестве одновременных подключений, вам действительно нужно провести стресс-тест вашей установки, чтобы определить это критическое число.
Не существует волшебной формулы для прогнозирования емкости - вам нужно сделать это путем экспериментов и численного анализа.
мы уже видели скачок с 3,5 тыс. GET в секунду в среднем до 11 тыс. GET в секунду.
Если вы говорите, что это результат внедрения изменения, это означает, что вы ранее теряли 2/3 своего трафика из-за проблем с производительностью?
Хотя эти показатели позволяют предположить, что вы сможете обслуживать больший объем трафика с меньшим количеством оборудования, вы измерили влияние на время отклика? Используете подходящее сетевое моделирование?
Вам необходимо спланировать архитектуру, которая позволит вам контролировать, что и где выполняется кэширование - вы хотите иметь возможность легко распределять нагрузку между несколькими экземплярами memcached с некоторой возможностью аварийного переключения. Это становится очень сложным, очень быстро - это одна из причин, по которой я предпочитаю оставлять memcached на крайний случай - и никогда не для внешнего кеша. Другая причина заключается в том, что там, где я его тестировал, есть незначительный выигрыш по сравнению с другими методами обмена данными (обратные прокси-серверы на передней панели, хорошая настройка в середине и распределенное общее хранилище на задней стороне). Но я прекрасно понимаю, что архитектура должна отражать компоненты, используемые для построения системы - мой опыт в основном связан с системами типа LAMP среднего размера - но модель с разделенным уровнем сервера приложений сильно отличается.