DLag: Brim.ru, тем что Xen ничем кроме низкой производительности не примечателен.
DLag, ваша маниакальное упорство во лжи просто поражает. Его бы направить на что-нибудь разумное, могли бы миллионером стать :)
Впрочем, вы уже подтвердили ранее, что ни на что большее, чем безответственная болтовня, вы не способны. Даже задачка на 500 рублей, посильная любому специалисту, оказалась для вас неподъемной.
Но я уверен, вы и дальше будете тратить свое время впустую и продолжать писать чушь о вещах, в которых слабо разбираетесь, вместо того, чтобы заняться реальной работой.
cvss добавил 24.01.2010 в 00:29
netwind: а сколько дисковых операций в секунду гарантирует клиенту это ваше решение ? нисколько? одно лишь честное слово, что тииипа мониторинг и отсутствие оверселла. собственный винчестер можно протестировать и быть уверенным в том, что он всегда покажет ту же производительность, что и при критическом тесте.
предложение небезынтересное.
Это достаточно редкий случай для VDS, когда требования к дисковому IO настолько непропорционально большие по сравнению к RAM и CPU, что требуют отдельного диска. Был, например, экзотический запрос на VDS с 256 Мб ОЗУ для размещения там поисковой машины, с индексом объемом около 120 Гб. У автора была достаточно хорошо аргументированная позиция, что больше ОЗУ все-равно не нужно, так как пути поиска размазаны равномерно по всему индексу и радикальный прирост в скорости был бы только дла ОЗУ от 16 Гб. Но это была именно экзотика и, возможно, не очень удачное решение для работы с данными.
А для большинства типовых задач, веб-сайтов, увеличение ОЗУ за ту же цену, что и подключение отдельного диска, даст больший прирост в производительности. Конечно, если не считать случаи, когда дисковый IO уже просажен какими-нибудь соседями по серверу.
Andreyka: cvss - apache+mod_php весит больше по ресурсам чем nginx+php-fpm, даже если прикрыть apache nginx'ом. Ибо между mod_php и nginx есть некоторая тормозная сущность - apache ;).
Это я и сам писал. Сейчас комментарий вам я не про это писал, а про бэклоги апача, которые ничем не хуже бэклогов php-fpm.
Как я понял, вы уже разобрались с вашим противопоставлением php-fpm, работающего на тредах и apache/mod_php, который форкается на каждый запрос к php. С тем, что и первое, и второе - ошибка, миф, вы уже не спорите. Так?
Andreyka: В префорке один запрос в еденицу времени обрабатывается одним процессом - я говорил именно это.
А остальные лежат себе в беклоге и тихо ждут как будет свободен процесс.
Кстати - их лучше складывать в беклог фронтенда ящитаю ;)
Andkreyka, каждый php-fpm тоже обрабатывает запросы последовательно. Точно также, как apache/mod_php в prefork.
DLag: Для запроса форк не делается если есть свободные треды или достигнут лимит тредов.
Честно говоря поражаюсь вам. Столько россказней о профессионализме, а такие вещи пишете.
DLag, вот уж вам в этом никого упрекать не стоит :). Как пишет Ноам Хомский, ханжа (лицемер) — это тот, кто прикладывает к другим стандарты, которые отказывается применять к себе.
Pilat: Да нет, всё правильно. Кэш - это не обязательно shared memory, иногда это просто файлы. А иногда акселератора нет вообще - по объективным причинам.
Но мы же не будем на практике, ориентируясь на повышение скосроти, выбирать самое худшее с точки зрения производительности решение :)
В рассматриваемом случае используется DLE - непонятно, как оно будет ускоряться. Подозреваю что слабо.
Pilat: Выделенные пункты - это те самые загрузки файлов, либо со скриптами, либо с опкодом. Акселератор ускоряет компиляцию, но не ускоряет загрузку этих файлов. Вот как раз фаза загрузки файлов и оказывает существенное влияние на производительность, по сравнению с "прослойке между приемом HTTP-запроса и стартом скрипта" это влияние практически полностью должно нивелировать преимущества от php-fpm прослойки, и чем более навороченная система, тем сильнее это должно быть заметно.
Про акселератор неправильно. Акселератор: 1) загружает файл (с php-кодом), 2) компилирует в оп-код, 3) сохраняет в кэш (например, shared memory), 4) отдает интерпретатора оп-код. При повторных попытках php загрузить этот файл, акселератор сразу выполняет шаг 4 и загрузка файла ускоряется, так как шаг 1 (загрузка файла) просто отсутствует.
А в целом, все верно, чем больше времени находится на стороне php - выполнение программы, запросы к БД, тем меньше разница. Для вордпресса без кэширования с кучей модулей разница станет практически незаметной. Но для быстрых движков или более специализированных случаев (счетчики, баннерные крутилки), при использовании к тому же кэширования промежуточных данных в memcached или shared memory, разница составляет до 20% плюс некоторая экономия памяти. Не так уж много, но "бесплатно".
Разница между mod_php и FastCGI в том, что FastCGI грузит один раз код и много раз его использует.
Нет, это неверно. Грузить один раз код - в смысле, executably binary file, это разница между FastCGI и CGI. Т.е. PHP-CGI каждый раз грузит интерпретатор PHP, а у PHP-FastCGI интерпретатор загружается один раз. Но сами php-файлы загружаются и интерпретируются одинаково и в PHP-CGI, и в PHP-FastCGI, и в mod_php. Кэширование загрузки файлов входит в задачу акселераторов типа eaccelerator и zend optimizer, только кэшируются не сами файлы, а уже компилированный опкод.
CMS из сотен модулей на загрузку файлов тратит кучу времени, именно это даёт прирост в случае fastcgi+perl. php-fpm как-бы fastcgi+php, но не fastcgi на самом деле, как подозревают некоторые, поэтому серьёзного прироста не должно быть.
Работу перловых скриптов в fastcgi не нужно смешивать с PHP, там совершенно разного уровня подход. Когда разрабочик пишет перловый скрипт для fastcgi, он может сделать и прелоад нужных файлов, и инициализацию различных тяжелых структур данных и прочее, что можно вынести из цикла обработки каждого запроса. В случае с PHP, разработчику безразлично, будет ли его исполнять php-fastcgi или mod_php, так как выполнение php-скрипта будет идти одинаково в обоих случаях. Разница только в той самой прослойке между приемом HTTP-запроса и стартом скрипта, про которую я писал раньше.
cvss добавил 25.12.2009 в 12:28
Andreyka: nginx перед apache мало что даст, ибо сама суть apache - делать отдельный процесс на каждый вызов
Это не так. В prefork один процесс может обработать последовательно сколько угодно вызовов к php-скриптам (число выполненных запросов можно ограничить в конфиге). Он не будет делать отдельный процесс (fork) на каждый вызов. PHP-FPM в этом аспекте работает точно также - каждый воркер может последовательно обработать сколько угодно вызовов.
Более того, у PHP-FPM в разработке и планах на релиз находится реализация prefork модели apache, для динамического регулирования числа рабочих процессов в зависимости от нагрузки, так как статическое число воркеров - это недостаток.
Ну и, на самом деле nginx перед apache дает все :) Как любой другой HTTP-акселератор. Даже без кэширования, а только снятием на себя передачи данных клиентам.
Pilat: Всё-таки такие тесты смысла не имеют - они меряют фигню. Надо что-то осмысленное пускать, в реальности 500 ответов в секунду не будет, а будет 10 и совсем другие причины начнут работать, например открытия файлов.
Тесты меряют ровно то, что у них написано в заголовке - оверхед на различные методы вызова 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-шного кода.
topmedia: Во многом согласен. Про дисковый кеш скажу так - ни одна операционка не будет увеличивать дисковый кеш в ущерб активному процессу. Тем более, что гостевая ОС тоже занимается кешированием и старается минимизировать обращения к диску.
Вы правы, в ущерб активному процессу не будет. Но если mysqld спит 10 минут, потому что в это время запросов к базе не было, у него уйдут из кэша все открытые таблицы, и сам процесс легко вытеснится в свап.
В OpenVZ госевая ОС - это на самом деле не ОС. Ядро там только одно - ядро хоста. В контейнерах только user-space приложения. Соответственно, вся политика кэширования определяется ядром и VPSы на кэширование прямо влиять не могут, только косвенно, различными ухищрениями.
P.S. в юниксах дисковый кеш не относится к ресурсам ядра?
Технически, дисковый кэш - ресурс ядра. Но участок памяти из кэша может мэппиться в виртуальную память одного или нескольких процессов. Например, фрагмент shared library. И в этот момент уже терминологически трудно назвать его ресурсом ядра, так ядро не может его просто так взять и освободить.
Brim.ru, тем что Xen ничем кроме низкой производительности не примечателен.
DLag, ваша маниакальное упорство во лжи просто поражает. Его бы направить на что-нибудь разумное, могли бы миллионером стать :)
Впрочем, вы уже подтвердили ранее, что ни на что большее, чем безответственная болтовня, вы не способны. Даже задачка на 500 рублей, посильная любому специалисту, оказалась для вас неподъемной.
Но я уверен, вы и дальше будете тратить свое время впустую и продолжать писать чушь о вещах, в которых слабо разбираетесь, вместо того, чтобы заняться реальной работой.
cvss добавил 24.01.2010 в 00:29
а сколько дисковых операций в секунду гарантирует клиенту это ваше решение ? нисколько? одно лишь честное слово, что тииипа мониторинг и отсутствие оверселла.
собственный винчестер можно протестировать и быть уверенным в том, что он всегда покажет ту же производительность, что и при критическом тесте.
предложение небезынтересное.
Это достаточно редкий случай для VDS, когда требования к дисковому IO настолько непропорционально большие по сравнению к RAM и CPU, что требуют отдельного диска. Был, например, экзотический запрос на VDS с 256 Мб ОЗУ для размещения там поисковой машины, с индексом объемом около 120 Гб. У автора была достаточно хорошо аргументированная позиция, что больше ОЗУ все-равно не нужно, так как пути поиска размазаны равномерно по всему индексу и радикальный прирост в скорости был бы только дла ОЗУ от 16 Гб. Но это была именно экзотика и, возможно, не очень удачное решение для работы с данными.
А для большинства типовых задач, веб-сайтов, увеличение ОЗУ за ту же цену, что и подключение отдельного диска, даст больший прирост в производительности. Конечно, если не считать случаи, когда дисковый IO уже просажен какими-нибудь соседями по серверу.
cvss - apache+mod_php весит больше по ресурсам чем nginx+php-fpm, даже если прикрыть apache nginx'ом. Ибо между mod_php и nginx есть некоторая тормозная сущность - apache ;).
Это я и сам писал. Сейчас комментарий вам я не про это писал, а про бэклоги апача, которые ничем не хуже бэклогов php-fpm.
Как я понял, вы уже разобрались с вашим противопоставлением php-fpm, работающего на тредах и apache/mod_php, который форкается на каждый запрос к php. С тем, что и первое, и второе - ошибка, миф, вы уже не спорите. Так?
В префорке один запрос в еденицу времени обрабатывается одним процессом - я говорил именно это.
А остальные лежат себе в беклоге и тихо ждут как будет свободен процесс.
Кстати - их лучше складывать в беклог фронтенда ящитаю ;)
Andkreyka, каждый php-fpm тоже обрабатывает запросы последовательно. Точно также, как apache/mod_php в prefork.
Для запроса форк не делается если есть свободные треды или достигнут лимит тредов.
Честно говоря поражаюсь вам.
Столько россказней о профессионализме, а такие вещи пишете.
DLag, вот уж вам в этом никого упрекать не стоит :). Как пишет Ноам Хомский, ханжа (лицемер) — это тот, кто прикладывает к другим стандарты, которые отказывается применять к себе.
Да нет, всё правильно. Кэш - это не обязательно shared memory, иногда это просто файлы. А иногда акселератора нет вообще - по объективным причинам.
Но мы же не будем на практике, ориентируясь на повышение скосроти, выбирать самое худшее с точки зрения производительности решение :)
В рассматриваемом случае используется DLE - непонятно, как оно будет ускоряться. Подозреваю что слабо.
Согласен.
Выделенные пункты - это те самые загрузки файлов, либо со скриптами, либо с опкодом. Акселератор ускоряет компиляцию, но не ускоряет загрузку этих файлов. Вот как раз фаза загрузки файлов и оказывает существенное влияние на производительность, по сравнению с "прослойке между приемом HTTP-запроса и стартом скрипта" это влияние практически полностью должно нивелировать преимущества от php-fpm прослойки, и чем более навороченная система, тем сильнее это должно быть заметно.
Про акселератор неправильно. Акселератор: 1) загружает файл (с php-кодом), 2) компилирует в оп-код, 3) сохраняет в кэш (например, shared memory), 4) отдает интерпретатора оп-код. При повторных попытках php загрузить этот файл, акселератор сразу выполняет шаг 4 и загрузка файла ускоряется, так как шаг 1 (загрузка файла) просто отсутствует.
А в целом, все верно, чем больше времени находится на стороне php - выполнение программы, запросы к БД, тем меньше разница. Для вордпресса без кэширования с кучей модулей разница станет практически незаметной. Но для быстрых движков или более специализированных случаев (счетчики, баннерные крутилки), при использовании к тому же кэширования промежуточных данных в memcached или shared memory, разница составляет до 20% плюс некоторая экономия памяти. Не так уж много, но "бесплатно".
Разница между mod_php и FastCGI в том, что FastCGI грузит один раз код и много раз его использует.
Нет, это неверно. Грузить один раз код - в смысле, executably binary file, это разница между FastCGI и CGI. Т.е. PHP-CGI каждый раз грузит интерпретатор PHP, а у PHP-FastCGI интерпретатор загружается один раз. Но сами php-файлы загружаются и интерпретируются одинаково и в PHP-CGI, и в PHP-FastCGI, и в mod_php. Кэширование загрузки файлов входит в задачу акселераторов типа eaccelerator и zend optimizer, только кэшируются не сами файлы, а уже компилированный опкод.
CMS из сотен модулей на загрузку файлов тратит кучу времени, именно это даёт прирост в случае fastcgi+perl. php-fpm как-бы fastcgi+php, но не fastcgi на самом деле, как подозревают некоторые, поэтому серьёзного прироста не должно быть.
Работу перловых скриптов в fastcgi не нужно смешивать с PHP, там совершенно разного уровня подход. Когда разрабочик пишет перловый скрипт для fastcgi, он может сделать и прелоад нужных файлов, и инициализацию различных тяжелых структур данных и прочее, что можно вынести из цикла обработки каждого запроса. В случае с PHP, разработчику безразлично, будет ли его исполнять php-fastcgi или mod_php, так как выполнение php-скрипта будет идти одинаково в обоих случаях. Разница только в той самой прослойке между приемом HTTP-запроса и стартом скрипта, про которую я писал раньше.
cvss добавил 25.12.2009 в 12:28
nginx перед apache мало что даст, ибо сама суть apache - делать отдельный процесс на каждый вызов
Это не так. В prefork один процесс может обработать последовательно сколько угодно вызовов к php-скриптам (число выполненных запросов можно ограничить в конфиге). Он не будет делать отдельный процесс (fork) на каждый вызов. PHP-FPM в этом аспекте работает точно также - каждый воркер может последовательно обработать сколько угодно вызовов.
Более того, у PHP-FPM в разработке и планах на релиз находится реализация prefork модели apache, для динамического регулирования числа рабочих процессов в зависимости от нагрузки, так как статическое число воркеров - это недостаток.
Ну и, на самом деле nginx перед apache дает все :) Как любой другой HTTP-акселератор. Даже без кэширования, а только снятием на себя передачи данных клиентам.
Всё-таки такие тесты смысла не имеют - они меряют фигню. Надо что-то осмысленное пускать, в реальности 500 ответов в секунду не будет, а будет 10 и совсем другие причины начнут работать, например открытия файлов.
Тесты меряют ровно то, что у них написано в заголовке - оверхед на различные методы вызова 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)
Вполне совпадает с теорией.
Во многом согласен. Про дисковый кеш скажу так - ни одна операционка не будет увеличивать дисковый кеш в ущерб активному процессу. Тем более, что гостевая ОС тоже занимается кешированием и старается минимизировать обращения к диску.
Вы правы, в ущерб активному процессу не будет. Но если mysqld спит 10 минут, потому что в это время запросов к базе не было, у него уйдут из кэша все открытые таблицы, и сам процесс легко вытеснится в свап.
В OpenVZ госевая ОС - это на самом деле не ОС. Ядро там только одно - ядро хоста. В контейнерах только user-space приложения. Соответственно, вся политика кэширования определяется ядром и VPSы на кэширование прямо влиять не могут, только косвенно, различными ухищрениями.
Технически, дисковый кэш - ресурс ядра. Но участок памяти из кэша может мэппиться в виртуальную память одного или нескольких процессов. Например, фрагмент shared library. И в этот момент уже терминологически трудно назвать его ресурсом ядра, так ядро не может его просто так взять и освободить.