![]() |
|
||||||||
|
|||||||||
|
|
|
|
|
|||||||||||
| Offline Нет границ, любое препятствия можно преодолеть! © Паркур Профиль Журнал Группа: Эксперт ![]() Сообщений: 474 Пользователь №: 17068 На форуме: Репутация: нет Трезвый : 22 года, 11 месяцев, 3 дня |
Содержание.
Потом в голове возник вопрос: а правильный ли выбор я сделал. Стал искать сравнительные тесты в интернете и ничего стоящего не нашел. Даже странно стало: оптимизаторы phpсуществуют не первый год, а сравнений никто не проводил. Даже если кто их и делал, то в поисковых системах они погребены под горами мусора. Рассмотрев список бесплатно доступных систем, составил следующий список: eAccelerator, APC, XCache и Memcache. Первые три умеют кэшировать скомпилированные php-файлы, eAccelerator и APC имеют оптимизаторы кода, Memcache же является отдельным кэширующим сервером и к phpимеет отношение только тем, что для работы с ним существует php-модуль.
По API больше понравился eAccelerator. API простое - только самое нужное, но есть и такие возможности, которых нет у других - функции блокировки ключа. Документация неудобная, но информация понятна и есть толковые примеры. Он также лучше и удобнее в настройках. Позволяет отдельно управлять хранением ключей, сессий и данных (скомпилированного кода и пользовательских данных). Методы хранения: только в разделяемой памяти, в памяти и на диске одновременно, в памяти с вытеснением на диск и только на диске. Легко и прозрачно можно отделить ключи каждого виртуального сервера в системе, чтобы не было лишних дырок в безопасности и пересечения ключей, установкой уникального значения параметра eaccelerator.name_space для каждого виртуального сервера. Переписал код club.shelek.ru на работу с кэшем: среднее время генерации страницы всего 4-5 мс против 90-120 без кэша. Против ожидания, что нагрузка на процессор и память возрастет, наблюдаю, наоборот, снижение за счет меньшей нагрузки на базу данных. Посмотрим, как он покажет себя при длительной эксплуатации. APC http://www.php.net/apc APC очень обилен в настройках. Пока я предпочел не крутить настройки, а пользоваться значениями по умолчанию. API очень маленькое. Интересная функция - сохранение массива и восстановление его как набора констант. Редкая по нужности функция. XCache http://xcache.lighttpd.net/wiki/XcacheApi После eAccelrator и APC XCache ничем хорошим не удивил. Отвратительная документация по API без единого комментария (я назвал ее "черный квадрат"), хотя для базовых функций даны примеры, и то хорошо. API простое. Из особенностей: возможность выполнять инкремент и декремент числового значения в кэше и функция проверки наличия ключа в кэше без пересылки самого значения. Настроек довольно мало. Удивило то, что кэширование по умолчанию разрешено, но размер используемой памяти и максимальные размеры пользовательских объектов равны нулю, что по документации означает "запрещено". Memcache http://www.php.net/memcache Memcache минималистичен в настройках, так как настройки управления кэшированием находятся на стороне сервера memcached. API у него посложнее, чем у первых трех систем, и поддерживает работу в процедурном и ООП способах. Из особенностей: помимо функции установки значения по ключу есть возможность добавить ключ, только если его еще нет, и перезаписать, только если он уже есть. Может иметь несколько кэширующих серверов: как на том же хосте, так и на других. Как я понял, суть Memcache - в использовании ресурсов других хостов. По моему мнению, это несколько устарело: если ресурсов одного хоста не хватает, то лучше найти другой способ распределить нагрузку, чем коммуникация по TCP с кэширующими серверами на других хостах, что вносит существенную задержку. Тем не менее, Memcache в сети упоминается часто, из чего делаю вывод о его популярности и включаю в список тестируемых систем.
Условия тестов: Версии программ: Лимит времени работы скрипта был убран, память, выделяемая процессу, - 200МБ (сначала было 16, но об этом чуть позже). Время измерялось php-функцией microtime(true) с точностью до микросекунд. Работу с кэш-системами обеспечивал класс, написанный несколькими днями ранее.
Для тестов были созданы 4 файла:
Содержимое каждого файла представляет собой сериализованный массив, заполненный случайными значениями. Размеры их, как видите, приблизительно равны 1МБ, 100кБ, 10кБ и 1кБ. В каждом тесте каждая система тестировалась с каждым из этих файлов.Тесты.
Для большей наглядности я добавил к тестируемым кэш-системам еще и простое чтение файла. В первом тесте их было два:
Я подумал, что если размеры тестовых данных уменьшаются в десять раз от файла к файлу, то и число повторов тестовой операции стоит повышать в десять раз при переходе к следующему файлу. Для файла "Тест 1" было выполнено 10 повторов. Соответственно, для файла "Тест 4" - 10000. Результаты тестирования представлены в таблице. Время - в секундах.
В графическом виде это выглядит так: (IMG:http://s57.radikal.ru/i155/0904/f8/106d379ef675.png) Сначала протестировал работу с файлами, eAccelerator, APC и Memcache, а когда перешел к XCache, то скрипт стал аварийно завершаться. В логах Апача было сообщение о нехватке памяти. Увеличил размер с 16 до 32 МБ и повторил эксперимент: опять падение. 128 МБ - тоже. 192 - опять. На 200 МБ скрипт отработал до конца без ошибок. Вот такой вот он - XCache. Пришлось проводить тест для всех систем заново, с едиными условиями. При этом время работы всех систем, кроме Memcache, серьезно сократилось: в 1.5-2 раза. Видимо, за счет уменьшения работ по сборке мусора. Поразила скорость APC: в 2-4 раза медленнее, чем работа с файлами. Memcache тоже оказался не на высоте. eAccelerator, похоже, даже не заметил разницу: что 1 МБ, что 1 кБ, что 10 циклов, что 10000.Тест второй. Многократное чтение.
Результаты представлены в таблице. Время - в секундах.
Графическое представление, к сожалению, менее наглядно - цирфы говорят здесь лучше. (IMG:http://s54.radikal.ru/i146/0904/b3/5d41a561a444.png) На больших объемах хорошо видно, кто первый, а кто отстающий. На малых размерах разница не столь велика. Лидеры, по-прежнему, eAccelerator и XCache, APC и Memcache работают чуть быстрее, чем работа с файлом (надо понимать, что файл считывался не с диска, т.к. Linux кэширует файловые операции). Что интересно, здесь у XCache тоже были проблемы с нехваткой памяти, поэтому опять было выделено 200 МБ на процесс.Тест третий. В погоне за реальностью.
Для этого сначала запускался скрипт, который считывал все четыре файла и помещал их в кэш с разными ключами. Потом многократно запускался скрипт, который производил считывание из кэша всех четырех блоков данных и замер времени на каждое чтение. Точность замеров очень плохая. Порой результат был - ноль. Еще я подметил, что после рестарта Апача первые 5-7 замеров для всех систем были большими, а потом сокращались в 2-3 раза. Чтобы компенсировать этот эффект, результаты первых 10 запусков я отбрасывал, а следующих 10 - записывал и потом усреднял. Все равно результаты приблизительные. Я оцениваю их точность - плюс-минус 10%. Результат показан в таблице. Время - в микросекундах.
Чтобы графическое представление не было таким же неинтересным, как и во втором тесте, убрал полных аутсайдеров: работу с файлами и Memcache. (IMG:http://s42.radikal.ru/i097/0904/d9/4ce20dac17cf.png) В лидерах, по-прежнему, eAccelerator и XCache. Даже помня о точности замеров, не приходится сомневаться, что APC работает в несколько раз медленнее, чем eAccelerator, а XCache плохо переваривает большие объемы данных.Заключение.
Это сообщение отредактировал PandoraBox2007 - 26.04.2009 - 19:45 |
||||||||||
|
|
|
| Offline Новичок Профиль Журнал Группа: Пользователь Сообщений: 48 Пользователь №: 1672 На форуме: Репутация: нет |
Супер! Большое спасибо! Остались ещё люди способные грамотно анализировать информацию. Статья пришлась очень кстати. Для оптимизации кода недавно выбрал eAccelerator, теперь ещё и убедился в хороших качествах его системы кэширования.
|
|
|
| Offline Здесь живет Профиль Журнал Группа: Эксперт ** ![]() Сообщений: 1778 Пользователь №: 5568 На форуме: Репутация: +1/-0 |
Остались ещё люди способные
|
|
|
|
| Offline Новичок Профиль Журнал Группа: Пользователь Сообщений: 48 Пользователь №: 1672 На форуме: Репутация: нет |
Я думал это его родная аналитика. Выложите пожалуйста ссылку откуда скопипастено, а то в таком виде обвинения голословны.
|
|
|
| Offline Здесь живет Профиль Журнал Группа: Эксперт ** ![]() Сообщений: 1778 Пользователь №: 5568 На форуме: Репутация: +1/-0 |
Кузя, я не собираюсь никому ничего доказывать :)
найти источник можно за три секунды. гуглить умеешь? |
|
|
| Offline Местный житель Профиль Журнал Группа: Форумчанин ![]() Сообщений: 192 Пользователь №: 16368 На форуме: Репутация: нет |
а что такого что статья скопирована??? с таким же успехом пусть все матиматику придумывают заново не*рен копировать чужиет труды :D
|
|
|
| Offline Здесь живет Профиль Журнал Группа: Эксперт ** ![]() Сообщений: 1778 Пользователь №: 5568 На форуме: Репутация: +1/-0 |
с таким же успехом я начну копипаситить сюда серию самоучителей по программированию, а страницы форума навечно в сапплименты вылетят... ктомуже принято делиться чужой информацией не посредством копипаста, а посредством предоставления ссылки.
на счет математики: а что, на всех математических форумах копипастятся труды по математике? |
|
|
| Offline Местный житель Профиль Журнал Группа: Форумчанин ![]() Сообщений: 192 Пользователь №: 16368 На форуме: Репутация: нет |
вы неврно меня поняли, а спорить на эту тему я ненамерен.
|
|
|||
| Offline уже не-квадратный Эксперт Профиль Журнал Группа: Эксперт *** ![]() Сообщений: 5161 Пользователь №: 4190 На форуме: Репутация: +15/-0 |
Согласен целиком и полностью! Норма - это дать ссылку и к ней краткое описание, либо небольшой кусочек текста из статьи. Чтобы было понятно, о чем идет речь. |
||
|
|||||
| Offline Местный житель Профиль Журнал Группа: Форумчанин ![]() Сообщений: 192 Пользователь №: 16368 На форуме: Репутация: нет |
Согласен целиком и полностью! Норма - это дать ссылку и к ней краткое описание, либо небольшой кусочек текста из статьи. Чтобы было понятно, о чем идет речь. |