Pull to refresh

Comments 6

Memcache обычно используют как самое быстрое ключ-значение сетевое хранилище.
На сколько выросли задержки и разброс времени ответа при использовании mcrouter?
Что происходит с приложением во время падения mcrouter?
Какова задержка восстановления?

Развернутого и полномасштабного нагрузочного тестирования мы не проводили. В тестах на стенде, приближенном к боевым условиям, различий между mcrouter+memcached и plain memcached выявлено не было. Количество запросов при этом практически на 2 порядка превышало то, что выдает приложение в своей повседневной работе. Для сравнительного тестирования производительности нужно использовать другой подход и инструменты. Возможно опишу это в своей следующей статье.

У нас было два варианта использования mcrouter:
  • StatefulSet из нескольких реплик. В таком случае запросы к mcrouter-ам равномерно балансируются средствами kubernetes, а в случае падения реплик они будут автоматически исключены из балансировки. Конечно, это происходит не мгновенно и часть запросов может пропасть.
  • sidecar-контейнер в pod с PHP — даст zero latency при обращении к mcrouter, общий localhost ведь. Но в данном случае нужна корректная liveness проба у основного приложения, чтобы в случае падения контейнера mcrouter трафик с pod-a снимался.
отчего не tarantool c memcached wrapper и репликацией? imho, самое простое и доступное решение.
Спасибо, мы не обратили внимания, но обязательно посмотрим на tarantool. Но пока, на первый взгляд последнему коммиту в репозитории github.com/tarantool/memcached скоро стукнет год, а внизу README красуется предупреждение: «This rock is in early beta». Хотелось придерживаться поверенных решений.
у меня уже полтора года живёт, но к «несчастью» кластер тарантула ни разу не упал, поэтому теста в бою не было, а ручное переключение не считается. + там мониторинг через экспортёр, удобно.
UFO just landed and posted this here
Sign up to leave a comment.