Sonne Опубликовано 4 марта, 2013 · Жалоба Ну вот у меня это не так. Привожу пример жручего сайта. Drupal с посещаемостью ~4k уников в сутки. Ничего не тормозит. 3 воркера отдают и статику и динамику. В вашем пример три, ТРИ одновременных запроса! Мы рассуждаем про сотни запросов в секунду. К слову сказать граница HIGHLOAD определяется как 100 запросов в секунду. Запустите Apache bench 1000 и похвастайтесь результатами. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
adnull Опубликовано 4 марта, 2013 · Жалоба Sonne, успокойтесь. В треде вообще не об этом речь идет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
replicant Опубликовано 4 марта, 2013 (изменено) · Жалоба Запустите Apache bench 1000 Это -c1000 -n1000 или просто -n1000? Разница как бы будет между этими тестами. Более валидным считается тест с -с10-100, хотя все в зависимости от ситуации. Отдача какой-то статики Document Length: 65809 bytes Concurrency Level: 1000 Time taken for tests: 0.169730 seconds Complete requests: 1000 Failed requests: 0 Write errors: 0 Total transferred: 7045623 bytes HTML transferred: 6853977 bytes Requests per second: 5891.71 [#/sec] (mean) Time per request: 169.730 [ms] (mean) Time per request: 0.170 [ms] (mean, across all concurrent requests) Transfer rate: 40534.97 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 1 18 12.1 29 30 Processing: 22 51 15.0 61 69 Waiting: 15 48 15.4 56 65 Total: 48 70 11.8 69 99 Отдача динамики Document Length: 128544 bytes Concurrency Level: 1000 Time taken for tests: 4.152756 seconds Complete requests: 1000 Failed requests: 0 Write errors: 0 Total transferred: 28989013 bytes HTML transferred: 28648318 bytes Requests per second: 240.80 [#/sec] (mean) Time per request: 4152.756 [ms] (mean) Time per request: 4.153 [ms] (mean, across all concurrent requests) Transfer rate: 6816.92 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 11 11.1 21 23 Processing: 39 1582 650.7 1975 2260 Waiting: 34 1577 650.2 1971 2251 Total: 60 1593 643.0 1981 2283 C -c10 другой домен Document Length: 46912 bytes Concurrency Level: 10 Time taken for tests: 4.504264 seconds Complete requests: 500 Failed requests: 0 Write errors: 0 Total transferred: 23651500 bytes HTML transferred: 23456000 bytes Requests per second: 111.01 [#/sec] (mean) Time per request: 90.085 [ms] (mean) Time per request: 9.009 [ms] (mean, across all concurrent requests) Transfer rate: 5127.81 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 0 0.0 0 0 Processing: 42 88 50.2 73 310 Waiting: 41 88 50.2 72 309 Total: 42 88 50.2 73 310 Произвольный форум с -с100 -n1000 Document Path: /forum/index.php?showforum=8 Document Length: 83868 bytes Concurrency Level: 100 Time taken for tests: 17.661551 seconds Complete requests: 1000 Failed requests: 165 (Connect: 0, Length: 165, Exceptions: 0) Write errors: 0 Total transferred: 84311517 bytes HTML transferred: 83952158 bytes Requests per second: 56.62 [#/sec] (mean) Time per request: 1766.155 [ms] (mean) Time per request: 17.662 [ms] (mean, across all concurrent requests) Transfer rate: 4661.82 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 12 44.4 0 269 Processing: 1277 1666 266.0 1593 2839 Waiting: 1274 1650 260.6 1579 2807 Total: 1277 1679 298.8 1593 2963 Второй тест того же форума Document Path: /forum/index.php?showforum=8 Document Length: 83868 bytes Concurrency Level: 100 Time taken for tests: 16.755079 seconds Complete requests: 1000 Failed requests: 30 (Connect: 0, Length: 30, Exceptions: 0) Write errors: 0 Total transferred: 84395496 bytes HTML transferred: 84035778 bytes Requests per second: 59.68 [#/sec] (mean) Time per request: 1675.508 [ms] (mean) Time per request: 16.755 [ms] (mean, across all concurrent requests) Transfer rate: 4918.93 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 0 0.6 0 2 Processing: 128 1603 347.2 1599 3154 Waiting: 124 1591 345.0 1588 3152 Total: 130 1603 346.8 1599 3154 И главная страница всех форумов Document Path: /forum/index.php Document Length: 119721 bytes Concurrency Level: 100 Time taken for tests: 18.859191 seconds Complete requests: 1000 Failed requests: 1 (Connect: 0, Length: 1, Exceptions: 0) Write errors: 0 Total transferred: 119927992 bytes HTML transferred: 119720992 bytes Requests per second: 53.02 [#/sec] (mean) Time per request: 1885.919 [ms] (mean) Time per request: 18.859 [ms] (mean, across all concurrent requests) Transfer rate: 6210.08 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 6 21.8 0 89 Processing: 302 1786 303.1 1819 2702 Waiting: 299 1776 302.4 1808 2695 Total: 307 1792 296.2 1821 2702 Увеличиваем до -с200 -n1000 Document Path: /forum/index.php Document Length: 119854 bytes Concurrency Level: 200 Time taken for tests: 19.362788 seconds Complete requests: 1000 Failed requests: 0 Write errors: 0 Total transferred: 120126584 bytes HTML transferred: 119919377 bytes Requests per second: 51.65 [#/sec] (mean) Time per request: 3872.557 [ms] (mean) Time per request: 19.363 [ms] (mean, across all concurrent requests) Transfer rate: 6058.58 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 2 12.4 0 136 Processing: 285 3474 1008.4 3617 7179 Waiting: 282 3450 1000.6 3601 7171 Total: 290 3477 1006.3 3620 7179 Фиг знает, хорошо это или плохо (я вообще такие тесты не проводил конкретно с этим сервером), но работает нормально и нагрузки держит тоже нормально. Чисто nginx сервера чутка быстрее в тестах, но по нагрузке что там, что на apache какие-то небольшие проценты от CPU, а памяти по 8Гб во всех тазиках, поэтому хватает с избытком. Хранилище данных вынесено по nfs на сетевой массив, если что. Сервера только раздают, а массив обслуживает другое железо (nas). Изменено 4 марта, 2013 пользователем replicant Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 5 марта, 2013 · Жалоба К слову сказать граница HIGHLOAD определяется как 100 запросов в секунду. Я думал больше. У торрент трекер прокси сейчас около сотни и жрёт она 2-3% одного ядра. Опен трекер на том же сервере ещё меньше жрёт. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Sonne Опубликовано 5 марта, 2013 · Жалоба replicant, а вы что тестируете? Речь о том что при прочих равных системных ресурсах nginx выдержит в несколько раз больше коннектов. Для этого надо взять машину с апачем и увеличивать нагрузку пока сервер не начнет клеить ласты. Т.е. либо дропать коннекты, либо занимать всю память. После этого на том же сервере поставить конфигурацию с nginx и повторить. Важно контроллировать все критерии - время отклика, дропы и занимаемую память. Условной границы вы достигли только в одном тесте - "произвольнй форум -с100 -n1000" где видны дропы коннектов. На самом деле -c100 это опция, которую вытягивает самый дешевый VPS c nginx. В обсуждаемых конфигурациях стоит начинать с -n100000 -c500 Я проводил эти тесты и получал разницу в максимальном количестве соединений между apache2 и nginx+php-fpm примерно в три раза. К слову сказать граница HIGHLOAD определяется как 100 запросов в секунду. Я думал больше. У торрент трекер прокси сейчас около сотни и жрёт она 2-3% одного ядра. Опен трекер на том же сервере ещё меньше жрёт. Прокси генерирует 100-500кб динамического контента на каждый запрос? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
agr Опубликовано 5 марта, 2013 · Жалоба В результате ... Попробовал то, что на гиториусе вы выложили. Что-то не арбайтает, по таймауту отваливается. Можете сказать конфиг nginx? PS: баг репорт elsif ( !return ) { $err = "couldn't run $req_params{SCRIPT_FILENAME}"; } здесь очевидно пропущено $ перед return. И может вообще это здесь не нужно - do вполне может штатно нулем завершиться. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
adnull Опубликовано 5 марта, 2013 · Жалоба Sonne, тестировать apache и nginx+php_fpm несколько глупо. Правильная связка nginx+apache и nginx+php_fpm, т.к. nginx принимает больше запросов за счет своей сути мультиплексора. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 5 марта, 2013 · Жалоба Прокси генерирует 100-500кб динамического контента на каждый запрос? Он размножает запрос клиента на несколько серверов, собирает ответы, сортирует там, удаляет дубликаты и отдаёт клиенту. Вроде по 4-16кб вполне хватает на буфера. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
replicant Опубликовано 5 марта, 2013 · Жалоба Условной границы вы достигли только в одном тесте - "произвольнй форум -с100 -n1000" где видны дропы коннектов. Дропы могут быть связаны с iptables + реализованной защитой от ботов и сканирования портов. На сервере оно имеется, но работает только на ряде ресурсов. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 5 марта, 2013 · Жалоба Попробовал то, что на гиториусе вы выложили. Что-то не арбайтает, по таймауту отваливается. Можете сказать конфиг nginx? Да в общем-то стандартно: server { server_name localhost; listen 127.0.0.1; access_log /var/log/nginx/localhost.access_log main; error_log /var/log/nginx/localhost.error_log info; root /var/www/localhost/htdocs; location / { index index.cgi; } location ~\.cgi$ { fastcgi_pass localhost:8999; fastcgi_index index.cgi; include fastcgi.conf; } } Рассыпалось все внезапно с введением потоков - интерпретатор считает, что остальные потоки живы, со всеми вытекающими. Пофиксю сегодня. здесь очевидно пропущено $ перед return. И может вообще это здесь не нужно - do вполне может штатно нулем завершиться. Угу, таки да. Пофиксил. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
adnull Опубликовано 5 марта, 2013 · Жалоба Непонятно. А штатный fastcgi для перла с префоркед процессами отсутствует в природе? Треды лучше не городить - плохо закончится. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 5 марта, 2013 · Жалоба Треды лучше не городить - плохо закончится. Таки да, тредф с форками дружат весьма похабно; сейчас FCGI:ProcManager пробую прикрутить вместо тредов - вроде как прикручивается. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 5 марта, 2013 · Жалоба Хм, FCGI:ProcManager + FCGI что-то тоже неадекватно работают - запросы обрабатываются воркерами сугубо поочередно. Разными. Даже в примере Ivan_83. Т.е., один воркер окончил обработку Accept - второй подхватил ее. FCGI версии 0.74, FCGI-ProcManager версии 0.24. Интересно, с какой радости... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
adnull Опубликовано 5 марта, 2013 · Жалоба Значит головной процесс неправильно работает. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 5 марта, 2013 · Жалоба Простой тестовый пример: use strict; use warnings; use FCGI; use POSIX; use FCGI::ProcManager qw(pm_manage pm_pre_dispatch pm_post_dispatch); my $socket = FCGI::OpenSocket(":8999", 5); my $request = FCGI::Request(\*STDIN, \*STDOUT, \*STDERR, \%ENV, $socket); pm_manage(n_processes => 2); my $count = 1; while($request->Accept() >= 0) { pm_pre_dispatch(); print "Content-Type: text/plain\r\n\r\n"; print "$$: ".$count++; sleep(5); pm_post_dispatch(); }; У меня 2-й запрос выполнялся только по окончании 1-го. Другим процессом. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
agr Опубликовано 6 марта, 2013 · Жалоба У меня 2-й запрос выполнялся только по окончании 1-го. Другим процессом. а как вы проверяли? Если браузером одинаковыми запросами, то он(браузер) может и не слать новый идентичный запрос до получения ответа на предыдущий. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 6 марта, 2013 · Жалоба Если браузером одинаковыми запросами, то он(браузер) может и не слать новый идентичный запрос до получения ответа на предыдущий. Хм, таки да, так и есть. Все вроде как работает адекватно, допилю мелкие плюшки и буду сегодня обкатывать... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 13 марта, 2013 · Жалоба В общем вроде все основное допилил, вроде как адекватно работает. Пришлось вернуть чтение вывода форкнутого процесса через sysread - для больших страничек буфер таки забивался, и чайлд не мог передавать воркер процессу оставшуюся часть странички. Хотя sysread порой может приводить к подземным стукам, но проще варианта пожалуй не было (разве что еще один поток порождать для контроля тайм-аута). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
snark Опубликовано 13 марта, 2013 · Жалоба Вдруг вспомнилось, что нечто похожее уже видел. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 13 марта, 2013 · Жалоба Что похожее? Пример FastCGI? Задача сабжа - запускать любой CGI перловый скрипт как FastCGI, не вызывая каждый раз интерпретатор для его выполнения, и не закапываясь глубоко в код того самого скрипта. Результат вполне положительный. + ко всему - служит заодно и враппером для прочих не-перловых CGI скриптов, запуская их через стандартный exec(). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 8 мая, 2018 · Жалоба Для перла и прочих cgi приложух можно/проще заюзать uwsgi: http://vladimir-stupin.blogspot.nl/2014/08/nginx-php5-fpm-uwsgi.html Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
^rage^ Опубликовано 13 мая, 2018 · Жалоба В 5/8/2018 в 21:42, Ivan_83 сказал: Для перла и прочих cgi приложух можно/проще заюзать uwsgi: http://vladimir-stupin.blogspot.nl/2014/08/nginx-php5-fpm-uwsgi.html зачем некропостить? ) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 13 мая, 2018 · Жалоба У меня перловый демон сломался некоторое время назад и я опять решал эту проблему. А то что у кого то оно с 2014 года работает не есть некрофилия, другой годной инструкции на русском не нашлось. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...