😂 я в контексте выссказывания именно это я и имел ввиду.
babnicks добавил 29.10.2011 в 14:33
iHead: 1.6 от ситуации без Hyper-threading.
Если покажите мне веб-сервер, который с hyper-threading'ом обрабатывает на 60% запросов больше чем без него, я вам дам много денег 😂
iHead:
"удвоение" видят все владельцы современных процессоров с поддержкой Hyper-threading: в ОС каждое ядро с гипертредингом определяется как 2 ядра
Вот именно что удвоение касается в основном количеством показываемых ядер ;)
Реальный прирост быстродействия от HT, хорошо, если бываете около 10-20%, а иногда и вообще ничего нет :)
iHead:
по остальному вам коллеги ответили.
Не ответили вот на это:
iHead:
т.к. внутри процесса параллелизация происходит за счет событий.
С точки зрения пользователя это выглядит как "параллелизация", на самом деле это ОДИН процесс и один поток и к параллелизации отношение имеет слабое, если одна нить, то она работает последовательно и никак не может начать работать параллельно :)
Lord Maverik: На серваке ~150 сайтов различных. Есть с сапой с множеством страниц.
Вопрос еще в памяти, если по памяти не критично, то можно с легкостью ставить по кол-ву логических ядер. Если с памятью напряг, то лучше сделать по кол-ву физических процессоров :)
netwind: Проверить очень просто - pgrep nginx | wc -l
Вы ошибаетесь, этим Вы никак не проверите наличие нитей в рамках одного процесса, а я говорил именно про это.
Пруфом является не это, а поиск по исходникам по строке "ngx_create_thread" только в этой процедуре идет создание нити с помощтю pthread_create.
И действительно, похоже я был не прав :( nginx похоже действительно управляется со всем основным циклом работы при помощи одной нити.
babnicks добавил 29.10.2011 в 14:10
zexis: Да, вы просто гигант программирования, что бы мельком посмотрев на исходники, понять как они работают.
Для того, чтобы понять как создаются нити достаточно поискать вызовы системных функций за это отвечающих, а после поглядеть вызовы тех функций, которые вызывают они.
babnicks добавил 29.10.2011 в 14:12
iopiop: да? не знал, обычно +1 принимает соединения и передает дальше, это его стандартная функция. Собственно, непонятно как могут принимать соединение сразу несколько ниток на одном сокете. Не складывается.
😂 ну собственно говоря да, слушать как минимум должен кто-то один. (имеется ввиду что ДА только один может слушать)
iopiop: хм, че-то вы тут загнули. сцылкой не поделитесь почитать? а то быстрый гуглопоиск ниче не дает такого.
Я не имею ввиду ветвление по кол-ву пользователей, но явно nginx внутри работает не в рамках одного потока. Ссылка :)
В этом его и отличие от apache, что апач создает потоки для каждого запроса в результате чего, в памяти могут застревать процессы, которые уже давно выполнились, но ждут пока клиент закончит прием данных.
Но и в nginx явно одновременно работает несколько потоков каждый своего назначения, одни отвечают за ввод/вывод, одни за чтение файлов, другие за проксирование.
Писать веб-сервер в ОДИН поток это очень не эффективно, так как одновременно разные коннекты находятся на разной стадии выполнения и эти стадии зачастую полностью параллельны друг-другу.
Это имхо, исходники дадут точный ответ, если он нужен :)
PS: мельком сейчас посмотрел исходники nginx, на первый взгляд все именно так, как я написал :)
iHead: иногда результат может быть близо к к удвоенному, но зачастую прирост от гипертрединга где-то 1.6 раза.
Про прирост чего Вы говорите? 1.6 раза от чего? Вы это где и когда видели УДВОЕНИЕ 😮 хоть чего-либо от использования гиппер-трейдинга? 😂
iHead:
да и необходимости нет в большом числе процесcов nginx, т.к. внутри процесса параллелизация происходит за счет событий.
😂 это как ? Это что за ноу-хау "параллелизация за счет событий" ?
Параллелизация внутри nginx идет за счет создания нитей в рамках одного процесса (имеется ввиду не по кол-во коннектов, а просто что в nginx работает несколько потоков, как и в любом достаточно сложном демоне).
TC, по сабжу имхо надо понять какая доля нагрузки лежит именно на nginx, возможно как раз nginx стоит вообще загнать на 1-2 процесса (у меня лично nginx вообще в один процесс работает, так как его роль 1% от общей вычислительной нагрузки), а остальное пускай кушает mysql, php и прочие ресурсоемкие процессы.
Вобщем зависит все от того, какой у Вас сайт, какие ресурсы он потребляет больше всего.
Дело в том что nginx, сам по себе, не много ресурсов потреблеят, и возможно нет никакого смысла, а то и вообще вред (в виде лишней скушанной памяти) в увеличении кол-ва его процессов.
😂 вообще-то я хочу посмотреть, возможно, там также, как при генерации rsa, пытаются получить как можно более случайное значение. В этом случае возможно упрощение алгоритма, оно конечно не лучшим образом скажется на безопасности, но для личного использования этого имхо будет достаточно... Вобщем надо смотреть...
Andreyka: Патчить скорее надо не сам openssl, а его привязку к апачу mod_ssl
Это так же как и с range при deflate - криво прикрутили, и патчили сам апач а не gzip
Понятно что патчить надо apache, надо вырубать у него renegotiation.
В openssl я хочу залезть и посмотреть, что же это там за функция такая, которая дает такую нагрузку, возможно что можно ее заменить на какой-то более упрощенный аналог...
Дык не пойдет, не видно главного значения сколько запросов в секунду исполняется :)
Вобщем у меня на VPS получилось 900 штук в секунду что "на вскидку" равняется где-то 100 мегабитам доса...
Резьюм данной темы таков:
Вобщем в nginx нет никакой уязвимости, как я и говорил выше, есть просто не очень быстрая работа при установке SSL соединения, причем 2048 битные ключи примерно в 3 раза медленее чем 1024 битные.
В случае с nginx с помощью файроволла все легко лечится, путем установки ограничения на кол-во коннектов в секунду с одного IP.
А вот апач действительно под угрозой, через одно соединение можно хорошенько загрузить сервер.
Так что надо перекомпилировать апач с отключенным renegotiation, а еще лучше поставить его за nginx'ом :)
ps: на досуге может даже поковыряюсь в исходниках openssl, что-то они там такое ужасное замутили, что оно так тормозит...
таки как максимум
😂 я в контексте выссказывания именно это я и имел ввиду.
babnicks добавил 29.10.2011 в 14:33
1.6 от ситуации без Hyper-threading.
Если покажите мне веб-сервер, который с hyper-threading'ом обрабатывает на 60% запросов больше чем без него, я вам дам много денег 😂
"удвоение" видят все владельцы современных процессоров с поддержкой Hyper-threading: в ОС каждое ядро с гипертредингом определяется как 2 ядра
Вот именно что удвоение касается в основном количеством показываемых ядер ;)
Реальный прирост быстродействия от HT, хорошо, если бываете около 10-20%, а иногда и вообще ничего нет :)
по остальному вам коллеги ответили.
Не ответили вот на это:
т.к. внутри процесса параллелизация происходит за счет событий.
С точки зрения пользователя это выглядит как "параллелизация", на самом деле это ОДИН процесс и один поток и к параллелизации отношение имеет слабое, если одна нить, то она работает последовательно и никак не может начать работать параллельно :)
На серваке ~150 сайтов различных. Есть с сапой с множеством страниц.
Вопрос еще в памяти, если по памяти не критично, то можно с легкостью ставить по кол-ву логических ядер. Если с памятью напряг, то лучше сделать по кол-ву физических процессоров :)
Проверить очень просто - pgrep nginx | wc -l
Вы ошибаетесь, этим Вы никак не проверите наличие нитей в рамках одного процесса, а я говорил именно про это.
Пруфом является не это, а поиск по исходникам по строке "ngx_create_thread" только в этой процедуре идет создание нити с помощтю pthread_create.
И действительно, похоже я был не прав :( nginx похоже действительно управляется со всем основным циклом работы при помощи одной нити.
babnicks добавил 29.10.2011 в 14:10
Да, вы просто гигант программирования, что бы мельком посмотрев на исходники, понять как они работают.
Для того, чтобы понять как создаются нити достаточно поискать вызовы системных функций за это отвечающих, а после поглядеть вызовы тех функций, которые вызывают они.
babnicks добавил 29.10.2011 в 14:12
да? не знал, обычно +1 принимает соединения и передает дальше, это его стандартная функция. Собственно, непонятно как могут принимать соединение сразу несколько ниток на одном сокете. Не складывается.
😂 ну собственно говоря да, слушать как минимум должен кто-то один. (имеется ввиду что ДА только один может слушать)
хм, че-то вы тут загнули.
сцылкой не поделитесь почитать? а то быстрый гуглопоиск ниче не дает такого.
Я не имею ввиду ветвление по кол-ву пользователей, но явно nginx внутри работает не в рамках одного потока. Ссылка :)
В этом его и отличие от apache, что апач создает потоки для каждого запроса в результате чего, в памяти могут застревать процессы, которые уже давно выполнились, но ждут пока клиент закончит прием данных.
Но и в nginx явно одновременно работает несколько потоков каждый своего назначения, одни отвечают за ввод/вывод, одни за чтение файлов, другие за проксирование.
Писать веб-сервер в ОДИН поток это очень не эффективно, так как одновременно разные коннекты находятся на разной стадии выполнения и эти стадии зачастую полностью параллельны друг-другу.
Это имхо, исходники дадут точный ответ, если он нужен :)
PS: мельком сейчас посмотрел исходники nginx, на первый взгляд все именно так, как я написал :)
иногда результат может быть близо к к удвоенному, но зачастую прирост от гипертрединга где-то 1.6 раза.
Про прирост чего Вы говорите? 1.6 раза от чего? Вы это где и когда видели УДВОЕНИЕ 😮 хоть чего-либо от использования гиппер-трейдинга? 😂
да и необходимости нет в большом числе процесcов nginx, т.к. внутри процесса параллелизация происходит за счет событий.
😂 это как ? Это что за ноу-хау "параллелизация за счет событий" ?
Параллелизация внутри nginx идет за счет создания нитей в рамках одного процесса (имеется ввиду не по кол-во коннектов, а просто что в nginx работает несколько потоков, как и в любом достаточно сложном демоне).
TC, по сабжу имхо надо понять какая доля нагрузки лежит именно на nginx, возможно как раз nginx стоит вообще загнать на 1-2 процесса (у меня лично nginx вообще в один процесс работает, так как его роль 1% от общей вычислительной нагрузки), а остальное пускай кушает mysql, php и прочие ресурсоемкие процессы.
Вобщем зависит все от того, какой у Вас сайт, какие ресурсы он потребляет больше всего.
Дело в том что nginx, сам по себе, не много ресурсов потреблеят, и возможно нет никакого смысла, а то и вообще вред (в виде лишней скушанной памяти) в увеличении кол-ва его процессов.
Это вам в помощь.
😂 вообще-то я хочу посмотреть, возможно, там также, как при генерации rsa, пытаются получить как можно более случайное значение. В этом случае возможно упрощение алгоритма, оно конечно не лучшим образом скажется на безопасности, но для личного использования этого имхо будет достаточно... Вобщем надо смотреть...
Так это, можно мне в ПМ ссылочку на вариант который апач по вашему укладывает, буду у себя тестировать. А то сурово это как-то все.
Оригинальный исходник - http://www.thc.org/thc-ssl-dos/ умеет это делать...
babnicks добавил 29.10.2011 в 10:37
Патчить скорее надо не сам openssl, а его привязку к апачу mod_ssl
Это так же как и с range при deflate - криво прикрутили, и патчили сам апач а не gzip
Понятно что патчить надо apache, надо вырубать у него renegotiation.
В openssl я хочу залезть и посмотреть, что же это там за функция такая, которая дает такую нагрузку, возможно что можно ее заменить на какой-то более упрощенный аналог...
Как говорится, вам шашечки или ехать? 😂
Для тестов пойдет.
Дык не пойдет, не видно главного значения сколько запросов в секунду исполняется :)
Вобщем у меня на VPS получилось 900 штук в секунду что "на вскидку" равняется где-то 100 мегабитам доса...
Резьюм данной темы таков:
Вобщем в nginx нет никакой уязвимости, как я и говорил выше, есть просто не очень быстрая работа при установке SSL соединения, причем 2048 битные ключи примерно в 3 раза медленее чем 1024 битные.
В случае с nginx с помощью файроволла все легко лечится, путем установки ограничения на кол-во коннектов в секунду с одного IP.
А вот апач действительно под угрозой, через одно соединение можно хорошенько загрузить сервер.
Так что надо перекомпилировать апач с отключенным renegotiation, а еще лучше поставить его за nginx'ом :)
ps: на досуге может даже поковыряюсь в исходниках openssl, что-то они там такое ужасное замутили, что оно так тормозит...
Посмотрите в SSL_set_rw - там все что надо передергивается само,
если SSL_do_handshake зафэйлится.
Мой вариант у вас nginx на 100% CPU не грузил разве?
Ваш вариант выдает ошибки SSL и не показывает сколько текущих коннектов и какая скорость h/s.
То что в случае ошибки оно само передергивается, я не спорю :) Но хочется видеть процесс и его скорость...
С точки зрения заложенной в программу логики правильно НЕ комментировать :)
Интересно мерить h/s это и есть критичная велечина, у меня на VPS она = 927.81 h/s
"SSL: error:00000000:lib(0):func(0):reason(0)" генерит вызов SSLERR("SSL");
в функции SSL_set_rw, так что логика работы SSL не нарушена :)
Не путайте следствие с причиной, происходит ошибка при renegotiation так как nginx его не поддерживает вот и выдается ошибка...
Чтобы ошибки не было надо "передернуть" коннект, обозначенным способом.