http://habrahabr.ru/blogs/php/37257/Наткнулся на обсуждение. К сожалению, включиться туда не могу - сервер заявляет, что регистрацию временно не разрешает. Потому пишу здесь.
Я уже указывал, что тесты далеки от реальной работы, и говорю это еще раз. Смысл тестов прост: выяснить скорость работы отдельных операций с кешом - записи и считывания. Замер времени работы всего скрипта не даст точную информацию, т.к. свою лепту внесут TCP, Apache, загрузка (пусть и предкомпилированного) кода и прочие процессы обработки запроса и ответа как на сервере, так и на клиенте.
Про утилиту ab вкурсе, но в данном случае утилита оказалась малополезна, т.к., во-первых, меряет в миллисекундах, а мой третий тест (единственный, годный для ab) отрабатывает много быстрее, во-вторых, утилита меряет полное время выполнения скрипта, а не отдельные операции, скорость которых меня интересовала. В общем, ничем microtime() не хуже, чем ab.
Сторонние тесты после отрыл. Их просто не было в рунете - они нашлись только на англоязычных сайтах и датировались 2002..2006 годами, что не совсем свежо, да, к тому же, там тестировалось скорость исполнения кода - оптимизация, а не кеширования данных. Кстати, там APC не был лидером - лидеры Zend и eAccelerator (или его предшественник - turck-memcache).
Т.ч. критика понятна, но не достаточно обоснована.
Пусть все искусственно, но зато есть некоторые сведения, которых иначе было бы не узнать. Это любовь XCache к оперативке, существенная зависимость скорости APC от объема данных и завидно ровная характеристика eAccelerator (интересно, чем это достигается и чем за это придется платить).
Насчет serialize/unserialize. eAccelerator занимается этим (автоматом упаковывает и распаковывает кешируемые данные в формат serialize()), а еще он сжимает данные в памяти. Если бы все было так плохо, как говорят, то был бы он аутсайдером. Используется ли штатный алгоритм PHP, или у акселератора он свой - можно проверить - по косвенным признакам типа восстановления объекта (и вызов метода __wakeup).
