nginx не подходящий пример, так как для него именно увеличение памяти имеет решающее значение. Конечно, можно поставить nginx при тотальной нехватке памяти, но тогда не стоит удивляться падению производительности, которое возникает из-за того, что все временные файлы nginx лежат не в памяти, а пишутся на диск. И в случае с nginx выделение, скажем, 1 Гб памяти для его временных файлов, поможет больше, чем выделение для них отдельного диска.
Для проблемы просаживания дискового IO несколькими клиентами есть решения, но редко кто настолько этим заморачивается. Для большинства VDS-хостеров, соглашусь, ситуация распространенная. Впрочем, для последних тоже всегда остается возможность "мониторить" и отсаживать тяжелых на отдельные диски.
DLag, ваша маниакальное упорство во лжи просто поражает. Его бы направить на что-нибудь разумное, могли бы миллионером стать :)
Впрочем, вы уже подтвердили ранее, что ни на что большее, чем безответственная болтовня, вы не способны. Даже задачка на 500 рублей, посильная любому специалисту, оказалась для вас неподъемной.
Но я уверен, вы и дальше будете тратить свое время впустую и продолжать писать чушь о вещах, в которых слабо разбираетесь, вместо того, чтобы заняться реальной работой.
cvss добавил 24.01.2010 в 00:29
Это достаточно редкий случай для VDS, когда требования к дисковому IO настолько непропорционально большие по сравнению к RAM и CPU, что требуют отдельного диска. Был, например, экзотический запрос на VDS с 256 Мб ОЗУ для размещения там поисковой машины, с индексом объемом около 120 Гб. У автора была достаточно хорошо аргументированная позиция, что больше ОЗУ все-равно не нужно, так как пути поиска размазаны равномерно по всему индексу и радикальный прирост в скорости был бы только дла ОЗУ от 16 Гб. Но это была именно экзотика и, возможно, не очень удачное решение для работы с данными.
А для большинства типовых задач, веб-сайтов, увеличение ОЗУ за ту же цену, что и подключение отдельного диска, даст больший прирост в производительности. Конечно, если не считать случаи, когда дисковый IO уже просажен какими-нибудь соседями по серверу.
Это я и сам писал. Сейчас комментарий вам я не про это писал, а про бэклоги апача, которые ничем не хуже бэклогов php-fpm.
Как я понял, вы уже разобрались с вашим противопоставлением php-fpm, работающего на тредах и apache/mod_php, который форкается на каждый запрос к php. С тем, что и первое, и второе - ошибка, миф, вы уже не спорите. Так?
Andkreyka, каждый php-fpm тоже обрабатывает запросы последовательно. Точно также, как apache/mod_php в prefork.
DLag, вот уж вам в этом никого упрекать не стоит :). Как пишет Ноам Хомский, ханжа (лицемер) — это тот, кто прикладывает к другим стандарты, которые отказывается применять к себе.
Но мы же не будем на практике, ориентируясь на повышение скосроти, выбирать самое худшее с точки зрения производительности решение :)
Согласен.
Про акселератор неправильно. Акселератор: 1) загружает файл (с php-кодом), 2) компилирует в оп-код, 3) сохраняет в кэш (например, shared memory), 4) отдает интерпретатора оп-код. При повторных попытках php загрузить этот файл, акселератор сразу выполняет шаг 4 и загрузка файла ускоряется, так как шаг 1 (загрузка файла) просто отсутствует.
А в целом, все верно, чем больше времени находится на стороне php - выполнение программы, запросы к БД, тем меньше разница. Для вордпресса без кэширования с кучей модулей разница станет практически незаметной. Но для быстрых движков или более специализированных случаев (счетчики, баннерные крутилки), при использовании к тому же кэширования промежуточных данных в memcached или shared memory, разница составляет до 20% плюс некоторая экономия памяти. Не так уж много, но "бесплатно".
Нет, это неверно. Грузить один раз код - в смысле, executably binary file, это разница между FastCGI и CGI. Т.е. PHP-CGI каждый раз грузит интерпретатор PHP, а у PHP-FastCGI интерпретатор загружается один раз. Но сами php-файлы загружаются и интерпретируются одинаково и в PHP-CGI, и в PHP-FastCGI, и в mod_php. Кэширование загрузки файлов входит в задачу акселераторов типа eaccelerator и zend optimizer, только кэшируются не сами файлы, а уже компилированный опкод.
Работу перловых скриптов в fastcgi не нужно смешивать с PHP, там совершенно разного уровня подход. Когда разрабочик пишет перловый скрипт для fastcgi, он может сделать и прелоад нужных файлов, и инициализацию различных тяжелых структур данных и прочее, что можно вынести из цикла обработки каждого запроса. В случае с PHP, разработчику безразлично, будет ли его исполнять php-fastcgi или mod_php, так как выполнение php-скрипта будет идти одинаково в обоих случаях. Разница только в той самой прослойке между приемом HTTP-запроса и стартом скрипта, про которую я писал раньше.
cvss добавил 25.12.2009 в 12:28
Это не так. В prefork один процесс может обработать последовательно сколько угодно вызовов к php-скриптам (число выполненных запросов можно ограничить в конфиге). Он не будет делать отдельный процесс (fork) на каждый вызов. PHP-FPM в этом аспекте работает точно также - каждый воркер может последовательно обработать сколько угодно вызовов.
Более того, у PHP-FPM в разработке и планах на релиз находится реализация prefork модели apache, для динамического регулирования числа рабочих процессов в зависимости от нагрузки, так как статическое число воркеров - это недостаток.
Ну и, на самом деле nginx перед apache дает все :) Как любой другой HTTP-акселератор. Даже без кэширования, а только снятием на себя передачи данных клиентам.
Тесты меряют ровно то, что у них написано в заголовке - оверхед на различные методы вызова php-шного кода.
Но интересно, как по вашему влияет использование mod_php или php-fpm на открытие файлов - а интерпретатор и там, и там один и тот же. Если вы предполагаете, что там как-то по разному открываются файлы, или, например, запросы к базе другие строятся, то это ошибка.
Разница между mod_php и php-fpm только в той прослойке, которая начинается принимающим сокетом и заканчивается вызовом функции выполнения php-скрипта. И чем больше php-кода в тесте или операций, типа открытия файла, тем меньше разница в тестах и тем ближе она будет к статистической погрешности. Что закономерно.
Для трех VDS на True20 прогнал ab -n 10000 -c 100 на файл test.php, содержащий <? print($_SERVER['REMOTE_ADDR']); ?>. По сути, тестируется оверхед на различные методы вызова php-шного кода.
ОС: Debian 5.0
ядро: 2.6.26-2-xen-686
PHP: 5.2.6
Результаты:
1. nginx <-> apache/mod_php
Requests per second: 536.35 [#/sec] (mean)
2. nginx <-> php-fpm
Requests per second: 624.51 [#/sec] (mean)
3. apache/mod_php
Requests per second: 737.88 [#/sec] (mean)
Вполне совпадает с теорией.
