Никто вам не скажет что у вас происходит по простой причине - нет исходных данных. То что вы привели в первом посте говорит лишь одно - тормоза.
Вам посоветовали уже поставить утилиту от гугла, есть аналогичная от яхи, посмотрите встроенную в Хром в конце-концов.
Программист этот ваш что, с секундомером сидел? Тогда найдите другого программиста
т.е. напишите забесплатно.
но вы же сами указывали коэффициент 1.6? Т.е. если поставить 8, хуже точно не будет, а лучше скорее всего будет, не так ли?
Как бы вопрос важный, если мы начнем добавлять БД и будем привязывать к ядрам, нужно же понимать сколько ядер у нас, 4 или 8.
worker_cpu_affinity
CPU affinity is represented as a bitmask (given in hexadecimal), with the lowest order bit corresponding to the first logical CPU and the highest order bit corresponding to the last logical CPU.
Examples:
CPU #0: 0x00000001
CPU #1: 0x00000002
CPU #2: 0x00000004
CPU #3: 0x00000008
CPU #0 and CPU #1: 0×00000003
CPU #2 and CPU #3: 0x0000000C
All CPUs: 0xFFFFFFFF
т.е. запустить nginx на CPU0 и CPU2
worker_cpu_affinity 0001 0100
проверить на каких ядрах работает можно так:
taskset -p PID
если в конце стоит mask: f - значит данный процесс может использовать любое ядро.
iopiop добавил 30.10.2011 в 00:26
не догоняю я этого :-(
разжуйте пожалуйста для идиота, почему 4, а не 8? в чем плюс четырех, а не восьми? для упрощения понимания предлагаю использовать систему где стоит только ngnix и отдает только статику.
спасибо.
смотрите мой последний коментарий, потому что нельзя сказать сколько точно, завивит от того, что у вас используется.
если статика, то распределяйте равномероно по количеству виртуальных ядер, т.е. 8 в вашем случае.
а если динамика (ну пхп какой-нить), то смотреть надо, может быть стОит 1 ядро отдать nginx (аффинити-чего-то-там в конфиге), а остальные под пхп.
вы привяжите nginx скажем к двум ядрам только и посмотрите как нагрузка распределяется ( top в линухе). после этого добавляйте-убирайте в зависимости от нагрузки ядер.
таки как максимум
на самом деле в коде действительно можно увидеть поддержку multi-threads, но она сейчас не работает правильно, сысоев обещает ко второй версии исправить. Как я понимаю, апач имеет 1:1 модель, nginx 1:N, хотят сделать M:N, наверное как раз для тех случаев когда диски очень медленные по сравнению с поступающими запросами, т.е ввести некоторую интерактивность, чтобы все запросы хоть чуть-чуть, но обрабатывались, независимо от глубины очереди.
Забавно что Sun (и не только он, бо очень непросто) отказался от такой модели лет 10 назад в яве, посмотрим что получится у сысоева.
да? не знал, обычно +1 принимает соединения и передает дальше, это его стандартная функция. Собственно, непонятно как могут принимать соединение сразу несколько ниток на одном сокете. Не складывается.
соглашусь пока что с netwind , вот некоторое подтвердение http://forum.nginx.org/read.php?2,194884,194938
