Я отвечаю за хостинг PHP-приложения, большого и медленного, но легко масштабируемого. Приложение полностью статично, и требуется дисковое хранилище с возможностью записи. Мы профилировали приложение, и, по-видимому, основное узкое место связано с загрузкой приложения, а не с работой, которую оно выполняет. Приложение не нагружает процессор, хотя и использует изрядное количество памяти (подумайте о Magento).
В настоящее время мы распространяем его, имея ряд серверов с одинаковыми файлами PHP на жестком диске и балансировщиком нагрузки перед ними. Легко, но дорого.
Я читал о RAM-диски и преимущества ввода-вывода, которые они предлагают, и мне было интересно, подходят ли они для приложений PHP.
Поскольку приложения PHP загружаются с диска для каждого запроса и часто включают множество разных файлов (в отличие от хранения в памяти, как в случае с Java-приложением), я полагаю, что производительность диска может быть серьезным узким местом.
Может ли размещение файлов PHP на RAM-диске и использование точки монтирования в качестве корневого каталога документов Apache обеспечить повышение производительности? Сценарий запуска может создать RAM-диск, а затем скопировать файлы (простые текстовые и небольшие) из постоянного места на временный RAM-диск.
Имеет ли это смысл, или я должен просто доверять ядру Linux, чтобы оно само кэшировало соответствующие файлы в памяти?
Нет, виртуальный диск действительно повредит PHP (в сочетании с лучшими решениями, такими как ускоритель PHP).
Лучший способ повысить производительность PHP - использовать ускоритель PHP. Это модули, которые подключаются к веб-движку (например, apache httpd) и кэшируют скомпилированный байт-код сценариев PHP. Этот кеш затем сохраняется в оперативной памяти. В результате будущие вызовы сценария PHP вообще не поступают на диск, предварительно скомпилированный байтовый код извлекается из кеша. Это означает, что вы ничего не получите от использования ramdisk, а вместо этого потребляете ramdisk, который можно было бы использовать в другом месте.
В зависимости от вашего дистрибутива и того, какой движок веб-сервера вы используете, вероятно, у вас уже работает ускоритель PHP.
.
Вот две хорошие статьи в Википедии на эту тему:
Ускоритель PHP
Список ускорителей PHP
Я был бы склонен думать, что если у вас есть машина с достаточным объемом оперативной памяти, кэш диска ОС будет работать так же хорошо при кэшировании соответствующего контента (если не лучше, потому что он не будет кэшировать файлы, которые не used), но вы должны протестировать его на тестовом сервере, убедившись, что вы действительно слишком сильно ударяете по диску (с помощью sar).
Самая большая проблема PHP заключается в том, что для каждого запроса интерпретатор должен
С участием APC вы можете пропустить все шаги и сразу перейти к выполнению. Если у вас есть проблемы с производительностью, особенно после того, как вы заметили упомянутые вами результаты профилирования, установите и настройте APC. Вы будете удивлены, какой прирост производительности вы получите.
Я столкнулся с проблемой оптимизации большого набора вики для Howtopedia организация; после пресс-релизов газетные сообщения систематически доводили нагрузку на систему до 100%. Настройка APC всего с 25 МБ кеш-памяти снизила нагрузку на систему до менее 5%. Дополнительная базовая настройка до менее 1%.
В то же время, поскольку большая часть шагов 1-3 представляет собой задержку, время отклика пользователей значительно улучшилось.
Еще несколько советов по описываемому вами сценарию:
Нет, не будет, если оперативная память уже является узким местом.