Блог

В настоящее время у нас есть сайт, который выполняет множество вызовов api с нашего родительского сайта для получения сведений о пользователе и других данных. Мы планируем кэшировать все детали на нашей стороне. Я планирую использовать memcache для этого. поскольку это живой сайт, и поэтому мы ожидаем увеличения трафика в ближайшие дни (не то чтобы как FB, но опять же, мой сервер тоже на них не похож ;)) поэтому мне нужно ваше мнение, с какими проблемами мы можем столкнуться, если перейдем на memcache, и ваши мнения расходятся, почему бы нам не пойти на это. Любая другая альтернатива также поможет.

https://github.com/steveyen/community-site/blob/master/db_doc/main/WhyNotMemcached.wiki

Memcached — это потрясающе! Но не для каждой ситуации…

• У вас есть объекты размером более 1 МБ.
  • Memcached не предназначен для больших носителей и потоковой передачи огромных двоичных объектов.
  • Рассмотрим другие решения, такие как:http://www.danga.com/mogilefs
• У вас есть ключи размером более 250 символов.
  • Если да, возможно, вы делаете что-то неправильно?
  • И, смотрите это обсуждение списка рассылки о размере ключа для предложений.
• Ваш хостинг-провайдер не позволит вам запускать memcached.
  • Если вы используете виртуальный частный сервер низкого уровня (часть компьютера), технологии виртуализации, такие как vmware или xen, могут оказаться неподходящим местом для запуска memcached. Memcached действительно хочет захватить и контролировать часть памяти — если эта память выгружается операционной системой или гипервизором, производительность падает. Однако использование виртуализации просто для упрощения развертывания в выделенных блоках — это нормально.
• Вы работаете в небезопасной среде.
  • Помните, что любой может просто подключиться по telnet к любому серверу memcached. Если вы используете общую систему, будьте осторожны!
• Вы хотите постоянства. Или базу данных.
  • Если вы действительно просто хотите, чтобы у memcached был интерфейс SQL, то вам, вероятно, нужно пересмотреть свое понимание кэширования и memcached.

Сначала вы должны реализовать общий уровень кэширования для вызовов API. Затем в пределах домена уровня кэширования вы можете изменить стратегию, которую вы хотите использовать. Если затем вы увидите, что memcache не подходит, вы действительно можете переключиться (и / или протестировать, как это работает по сравнению с другими серверными системами).

Еще лучше то, что вы можете сначала довольно легко закодировать эту сборку для файловой системы (которая также имеет несколько бэкэндов) без необходимости полагаться на другого демона, так что уже приступайте к кэшированию — вероятно, файловой системы уже достаточно для ваших нужд кэширования?

Memcache работает быстро, но он также может использовать много памяти, если вы хотите извлечь из него максимальную пользу. Всякий раз, когда вы нажимаете на диск для ввода-вывода, вы увеличиваете задержку вашего приложения. Извлеките элементы, к которым часто обращаются, и поместите их в memcache. Для моих крупномасштабных развертываний мы кэшируем сеансы там, потому что база данных работает медленно, как и хранилище сеансов файловой системы.

Рекомендуется добавить в свой стек APC. Он кэширует PHP-файлы и уменьшает общее использование памяти на страницу.

Альтернатива: Redis

Очевидно, что Memcached ограничен доступной памятью и начнет удалять данные при достижении пороговых значений памяти. Возможно, вы захотите посмотреть на redis, который работает так же быстро (быстрее в некоторых тестах), как memcached, но позволяет использовать как энергозависимые, так и энергонезависимые ключи, более сложные структуры данных и возможность использования виртуальной памяти для записи на диск значений наименее недавно использованных ключей (LRU).