Кэш-память по сравнению с APC для единственного кэширования данных сайта сервера
Как объясняется в мой ответ на аналогичный вопрос , конкретная конструкция if(compile-time-false) освобождается от правил недостижимости как явный бэкдор. В этом случае компилятор рассматривает ваш break как достижимый из-за этого.
5 ответов
A quick Googling говорит, что APC в 5 раз быстрее Memcached.
По моему опыту, APC работает почти в 7-8 раз быстрее, чем Memcached ... но к memchached могут обращаться различные сервисы (например, если вы работаете в основном на Apache и делегируете некоторый трафик, например, статическое содержимое, например изображения или чистый). html, в другой веб-сервис, такой как lighttpd), который может быть действительно полезным, если не необходимым.
APC имеет меньше возможностей, чем memcached, и его легко использовать и оптимизировать, но это зависит от ваших потребностей.
Как вы упомянули, есть несколько разных аспектов кэширования. Возможно, я бы сосредоточился на следующих аспектах кэширования в вашем приложении php:
-
кэширование кода операции, которое кэширует скомпилированный байт-код сценариев php. Вы можете увидеть тест здесь (хотя и в более старой статье): http://itst.net/654-php-on-fire-three-opcode-caches-compared Примечание: я настоятельно рекомендую использовать кэширование кода операции .
-
Кэширование пользовательских данных - APC и другие делают это. Это будут ваши справочные данные или данные, которые довольно статичны и не часто меняются. Вы можете очищать кэш каждый день или запускать очистку кеша при изменении этих справочных данных. Это также настоятельно рекомендуется, поскольку обычно справочные данные используются часто и не часто меняются.
-
Кэширование SQL-запросов - я знаю, что Zend облегчает эту задачу с помощью простой настройки. Поскольку эти запросы не меняются, это еще один очевидный (как вы упомянули)
Дополнительные (если возможно):
-
кэширование html-страниц - очевидно, что кэширование статической страницы происходит быстрее, чем сгенерированной, и, как правило, это трудно сделать, поскольку большинство страниц в приложениях настолько динамичны. Стоит, если вы можете это сделать, хотя, если ваши запросы кэшируются, а ваш SQL прост, я бы не стал на этом фокусироваться.
-
кэширование результатов sql - лично я держусь от этого подальше. Я позволю базе данных делать свою работу и то, что она делает лучше всего, так как СУБД обычно имеет кеширование. Я могу кэшировать результаты для потока выполнения (т. Е. Я только что получил это, так что не делайте это снова), но я не намного выше этого.
Я успешно использовал APC и eAccelerator (мне лично нравится работать с APC, и он предполагал кэширование кода операции и кэширование пользовательских данных для моих справочных данных и запросов sql). Используйте XDebug для профилирования вашего кода.
Вы хотите сравнить хранилище ключей APC с Memcache, верно? Потому что APC также выполняет кеширование кода операции, а это совсем другое.
Что ж, на одной машине кэш-память APC k-v намного быстрее, чем memcache. Memcache обладает большей функциональностью, но предназначен для распределенных сред, в то время как APC работает только на отдельных серверах.
Недавно я провел тестирование, чтобы установить, а затем получить по 1 миллиону ключей в обоих, каждый ключ представлял собой последовательное целое число, а значения были 32-байтовой строкой.
По локальному хосту memcache может получать 12 тыс. Ключей / секунду в одном потоке. APC вернул 90K / секунду. Однако, если вы используете многопоточность или «multi_get» с memcache, это очень близко к производительности APC.
Тест выполнялся на скорости 1 Гб в секунду на slicehost.
Я использую IPB 3.1.4 с APC, он работает в два раза быстрее, чем без него.
Requests per second: 43.46 [#/sec] (mean)
Requests per second: 24.23 [#/sec] (mean)
Пока не тестируйте IPB с memcached
Почти невозможно точно предсказать, что будет быстрее. Я бы запустил тесты с обоими в среде разработки с похожими данными.
Когда производительность важна, всегда используйте профилировщик.