Производительность OpenVZ VPS, приглашаю обсудить мою статью о оптимизации производительности |
Здравствуйте, гость ( Вход | Регистрация )
Настоящие Правила Раздела являются дополннением к Общим Правилам Конференции. В случаях противоречий отдельных пунктов, действуют Правила Раздела.
Производительность OpenVZ VPS, приглашаю обсудить мою статью о оптимизации производительности |
BarsMonster |
13.04.2010, 07:28
Сообщение
#1
|
Группа: Старые пользователи Сообщений: 56 Регистрация: 06.04.2009 Пользователь №: 9,321 Репутация: 192 |
Приглашаю обсудить мою статью об оптимизации и тестировании производительности OpenVZ (в тексте статьи есть и реф и не-реф ссылки на хостера).
Краткое содержание: ulimit -s 1024. Apache2 mpm-prefork 4 процесса максимум, mod_php+APC. MySQL - конфиг на 160Мб памяти, на 16 коннектов максимум (больше и не понадобится по идее). Nginx - ничего особенного. Все это работает под OpenVZ на 0.5Гб памяти с еще небольшой кучкой дополнительных вещей занимает 330-350Мб памяти _независимо_ от нагрузки. Мои PHP сайты отдаются 600-170 запросов в секунду, PHPBB3 - 17. Статика - 3.8Кб файл - 1424 запроса в секунду, 45Кб файл - 638 запросов в секунду (это при том, что я не настроил отдачу статики nginx-ом напрямую) - тест был из Германии на сервер в Москве. Что на ваш взгляд можно подкрутить, особенно в MySQL для PHPBB(т.к. он "тормозит" сильнее всего)? Насколько это надежно, или я что-то упускаю? |
eSupport.org.ua |
17.04.2010, 13:03
Сообщение
#2
|
Одесский сисадмин Группа: Старые пользователи Сообщений: 5,200 Регистрация: 18.11.2004 Из: Одесса Пользователь №: 823 Репутация: 263 |
mod_php быстрее
php-fpm легче |
BarsMonster |
17.04.2010, 14:53
Сообщение
#3
|
Группа: Старые пользователи Сообщений: 56 Регистрация: 06.04.2009 Пользователь №: 9,321 Репутация: 192 |
|
different |
17.04.2010, 17:25
Сообщение
#4
|
Группа: Старые пользователи Сообщений: 804 Регистрация: 29.06.2008 Из: Народный комиссариат виртуальных дел Пользователь №: 7,738 Репутация: 210 |
Следовательно, если памяти хватает, Apache+nginx не в топку? Задача-то какая? Если задача выполнять минимум запросов в минимум времени на 1 запрос - mod_php. Если задача выполнять максимум запросов одновременно - php-fpm. Иными словами - не путайте производительность и скорость исполнения. (IMG:style_emoticons/default/wink.gif) |
BarsMonster |
17.04.2010, 17:36
Сообщение
#5
|
Группа: Старые пользователи Сообщений: 56 Регистрация: 06.04.2009 Пользователь №: 9,321 Репутация: 192 |
Задача-то какая? Если задача выполнять минимум запросов в минимум времени на 1 запрос - mod_php. Если задача выполнять максимум запросов одновременно - php-fpm. Иными словами - не путайте производительность и скорость исполнения. (IMG:style_emoticons/default/wink.gif) Лично мне не вполне понятно, как могут 50 процессов быть быстрее 5, если у нас одно физическое ядро (по крайней мере пока процессы не блокируются медленным I/O). От бОльшого кол-ва процессов только потери на лишние переключение контекста и сброс L1/L2 кешей... Опять же, ab не тестирует "латентность" - он долбит во много потоков, и фактически тестируется именно производительность. |
different |
17.04.2010, 19:14
Сообщение
#6
|
Группа: Старые пользователи Сообщений: 804 Регистрация: 29.06.2008 Из: Народный комиссариат виртуальных дел Пользователь №: 7,738 Репутация: 210 |
Лично мне не вполне понятно, как могут 50 процессов быть быстрее 5, если у нас одно физическое ядро (по крайней мере пока процессы не блокируются медленным I/O). От бОльшого кол-ва процессов только потери на лишние переключение контекста и сброс L1/L2 кешей... Опять же, ab не тестирует "латентность" - он долбит во много потоков, и фактически тестируется именно производительность. Э. Причем здесь потоки? Есть mod_php. На единичном запросе он быстрее, чем php-fpm (не всегда, но сейчас это не важно). Но потребляет ресурсов X. Есть php-fpm. На единичном запросе он медленнее, чем mod_php, но потребляет ресурсов X-0.5 (цифра с потолка). Соответственно, пока X*(количество_потоков)<totalresouce - mod_php будет таки быстрее. Когда X*(количество_потоков)=>totalresouce - возникнет нехватка ресурсов. Соответственно, новые запросы не будут обрабатываться\будут вставать в очередь\сервер начнет свопить и все станет грустно. Засчет этого на равном железе смогут обслуживаться 50 запросов в минуту mod_php или 100 запросов в минуту php-fpm. Следовательно, время от момента принятия запроса до его исполнения на таком сервере при числе запросов >50 будет наименьшим в варианте с php_fpm, хотя чистое время отработки PHP в этой ситуации у mod_php - меньше. (IMG:style_emoticons/default/smile.gif) Все цифры - с потолка и для демонстрации логики. Цитата Лично мне не вполне понятно, как могут 50 процессов быть быстрее 5, если у нас одно физическое ядро (по крайней мере пока процессы не блокируются медленным I/O). От бОльшого кол-ва процессов только потери на лишние переключение контекста и сброс L1/L2 кешей... Что вы хотите этим сказать? Помимо процессора есть и другие ресурсы, если что. Это было бы верно в идеальной ситуации, когда каждый поток использует только CPU, а сети, памяти и I\O у нас нет вообще. Пример. У нас жесткое ограничение на 4 конкурентных запроса. Пришли 4 человека. Они сидят через GPRS. Им нужно отдать 1МБ информации. Пока они ее сосут (медленно) приходит пятый. Он вынужден ждать в очереди, пока хотя-бы один из четырех отвалится и "уступит место". Соответственно, свои данные он получит гораздо позже, чем получил бы при 5 разрешенных конкурентах. Так? Так. Хотя количество физических ядер у нас не поменялось. Аналогично произойдет, если один поток пишет на диск (к примеру) или дергает медленную базу, а другим потокам это не нужно, они отдают картинки. И т.д. и т.п. Смотреть надо профиль конкретной нагрузки. Вообще, вы тестируете что-то сферическое и в вакууме, как я уже и говорил. |
Текстовая версия | Сейчас: 24.04.2024, 13:35 |