Сколько памяти потребляют объекты в PHP и стоит ли использовать 64-битную версию?

На этот пост меня вдохновило исследование потребления памяти для моего текущего большого проекта на ZendFramework. Как обычно, по результатам исследования, я был шокирован нашей программистской самонадеянностью, которая нередко присутствует, когда мы пишем что-либо большое на PHP. Да и, наверное, не только на PHP.

Но обо всём по порядку.

Данная статья является логическим продолжением следующих статей:

• Работа с памятью (и всё же она есть)
• Насколько большие массивы (и значения) в PHP? (Подсказка: ОЧЕНЬ БОЛЬШИЕ)

Как будем измерять

Для начала определимся, как мы будем измерять «вес». Вот шаблон:

$startMemory = 0;
$startMemory = memory_get_usage();

// Измеряемое

echo (memory_get_usage() - $startMemory) . ' bytes' . PHP_EOL;

Такой шаблон подходит для измерения новой выделяемой памяти, то есть памяти под переменные. А вот измерить, сколько едят определения, то есть описания функций и классов, таким подходом нельзя, так как они заносятся в память до начала выполнения скрипта. Для того чтобы измерить определения, воспользуемся следующим шаблоном:

$startMemory = 0;
$startMemory = memory_get_usage();

// Измеряемое
include $testfile;

echo (memory_get_usage() - $startMemory - $include_overhead) . ' bytes' . PHP_EOL;

Где $include_overhead — сколько отжирает оператор include под свои внутренние нужды. В этой статье мы не будем изучать, как мы можем измерить $include_overhead. Замечу только, что размер пожираемой памяти зависит от 3 вещей:

• Длины абсолютного пути до файла
• Каким по счёту этот файл был включён (каждые 8, 16, 32, 64 и т.д. идёт дополнительное выделение под внутренние структуры)
• Заполненностью внутренних структур самого PHP, которые периодически довыделяют себе памяти на будущее.

Если кому-нибудь интересно разобраться в этом грубже, то можете изучить файл run.include-test.php, он очень хорошо иллюстрирует неравномерность пожирания памяти при include. Также отмечу, что во всех тестах ниже мы измеряем $include_overhead примерно, ибо нам нужны не точные значения а тенденция и различия между 32-хбитной и 64-битной версией.

Сколько весят «объекты»

Итак был написан TestSuite для автоматического запуска большого количества тестов. Все тесты запускались в VirtualBox для Ubuntu 12.04.1 LTS i386 и Ubuntu 12.04.1 LTS amd64. Версия PHP — 5.3.10, ZendFramework — 1.11.11. Команда для запуска в консоли:

php run.testsuite-without-accelerator.php

Дополнительно я сделал тест на своей машине с Gentoo amd64 для контроля. PHP-акселераторы при запуске из консоли не работают. Вот результаты:

Можно заметить, что сборка Gentoo потребляет на 10-20% меньше памяти, а в редких случаях экономия доходит до 50%. Видимо, размер внутренних структур зависит от оптимизаций для процессора. Для экперимента я пересобирал php с разными вариантами CFLAGS, но он от этого не стал потреблять больше. Видимо разница проявляется не из-за пересборки самого PHP, а из пересборки стандартных Сишных библиотек.

Как было отмечено выше, точно измерить $include_overhead сложно, поэтому если вы запустите данные тесты, то у вас могут получится так, что потребление памяти будет прыгать на 4, 8, 12, 16 байт, даже в тестах, которые должны потреблять одинаково. Не стоит акцентировать на этом внимания. Я запускал тесты в разном порядке и более-менее установил истинное потребление памяти.

Поговорим о тестах, связанных с ZendFramework. Загрузка определений классов Zend`а в память отжирает существенные ресурсы, тогда как ссылки на объекты уже потребляют не так много. Controller2 нужен, чтобы проверить, сколько будет отжирать аналогичный контроллер, если все промежуточные классы уже в памяти. Model2 создана для этих же целей.
В потенциале использование PHP акселератора сэкономит нам память на всех определениях, ибо они уже будут храниться в памяти. Давайте проверим это утверждение.

Тестирование акселераторов

Для тестирования был взят APC, и тесты запускались через web с помощью скрипта:

php run.testsuite-with-accelerator.php

Результаты приведены только тестов, где акселератор оказывает влияние:

Я также производил некоторые тесты с xcache и заметил 2 отличия от APC. Во-первых: xcache проигрывает (почти всегда) на 10-15% по экономии памяти. А во-вторых: xcache сразу отдаёт файлы из кеша, тогда как APC — только после повторного обращения. Хоть и бесполезное, но преимущество.

Сразу отмечу, в результатах разброс гораздо больше, чем при тестировании без акселератора, поскольку файлы не переименовывались и $include_overhead рассчитывался с большой ошибкой.

Как мы видим, акселератор хоть и экономит нам память для определений, но не полностью, поскольку PHP, видимо, переносит какие-то куски из кеша в текущую сессию.
Теперь перейдем от абстрактных тестов к вполне реальным.

Тестирование небольшого приложения на ZendFramework

Для тестирования было взято тестовое задание одного из наших программистов (Simple-blog): сервис коллективного блога с функциями: регистрации, авторизации, чтения списка постов, открытия поста и его комментирования. В конце index.php было написано:

echo memory_get_peak_usage();

чтобы проверить, какое максимальное количество памяти пожирал скрипт во время генерации страницы. Результаты:

Дополнительно проверялась сборка под Gentoo, он оказался на 25% эффективнее во всех тестах.

Выводы

• Если память дорогой ресурс (например VPS) и не особо нужны 64-битные числа, то есть смысл использовать 32-битную версию ОС. Выигрыш будет ~ в 1.8 раза.
• В ОС, в которых происходит заточка пакетов под текущую архитектуру можно дополнительно сэкономить 25% памяти.
• Ничто так не потребляет память в PHP, как тяжёлый фреймворк. Использование акселератора не спасает от поедания памяти тяжёлыми фреймворками. Возможно имеет смысл ознакомиться со следующим сравнением PHP фреймворков, чтобы выбрать для себя баланс популярности/производительности.
• Ситуацию, которая изображена на картинке для привлечения внимания, можно получить, если размер APC кеша окажется исчерпан. Этого добиться не сложно, если у вас много сайтов на одной машине, а вы установили APC, не проверяя хватит ли вам памяти. При этом статистика (apc.php) вам будет сообщать, что у вас есть ещё около 40% памяти, но ей особо не следует верить, ибо у APC плохой менеджер памяти и он просто не умеет использовать её эффективно. Лучше всегда обращайте внимание на hits и miss значения.

Кодяра

• Набор тестов
• Блог на ZendFramework

Автор: gnomeby

Источник