😂 я в контексте выссказывания именно это я и имел ввиду.
babnicks добавил 29.10.2011 в 14:33
Если покажите мне веб-сервер, который с hyper-threading'ом обрабатывает на 60% запросов больше чем без него, я вам дам много денег 😂
Вот именно что удвоение касается в основном количеством показываемых ядер ;)
Реальный прирост быстродействия от HT, хорошо, если бываете около 10-20%, а иногда и вообще ничего нет :)
Не ответили вот на это:
С точки зрения пользователя это выглядит как "параллелизация", на самом деле это ОДИН процесс и один поток и к параллелизации отношение имеет слабое, если одна нить, то она работает последовательно и никак не может начать работать параллельно :)
Вопрос еще в памяти, если по памяти не критично, то можно с легкостью ставить по кол-ву логических ядер. Если с памятью напряг, то лучше сделать по кол-ву физических процессоров :)
Вы ошибаетесь, этим Вы никак не проверите наличие нитей в рамках одного процесса, а я говорил именно про это.
Пруфом является не это, а поиск по исходникам по строке "ngx_create_thread" только в этой процедуре идет создание нити с помощтю pthread_create.
И действительно, похоже я был не прав :( nginx похоже действительно управляется со всем основным циклом работы при помощи одной нити.
babnicks добавил 29.10.2011 в 14:10
Для того, чтобы понять как создаются нити достаточно поискать вызовы системных функций за это отвечающих, а после поглядеть вызовы тех функций, которые вызывают они.
babnicks добавил 29.10.2011 в 14:12
😂 ну собственно говоря да, слушать как минимум должен кто-то один. (имеется ввиду что ДА только один может слушать)
Я не имею ввиду ветвление по кол-ву пользователей, но явно nginx внутри работает не в рамках одного потока. Ссылка :)
В этом его и отличие от apache, что апач создает потоки для каждого запроса в результате чего, в памяти могут застревать процессы, которые уже давно выполнились, но ждут пока клиент закончит прием данных.
Но и в nginx явно одновременно работает несколько потоков каждый своего назначения, одни отвечают за ввод/вывод, одни за чтение файлов, другие за проксирование.
Писать веб-сервер в ОДИН поток это очень не эффективно, так как одновременно разные коннекты находятся на разной стадии выполнения и эти стадии зачастую полностью параллельны друг-другу.
Это имхо, исходники дадут точный ответ, если он нужен :)
PS: мельком сейчас посмотрел исходники nginx, на первый взгляд все именно так, как я написал :)
Про прирост чего Вы говорите? 1.6 раза от чего? Вы это где и когда видели УДВОЕНИЕ 😮 хоть чего-либо от использования гиппер-трейдинга? 😂
😂 это как ? Это что за ноу-хау "параллелизация за счет событий" ?
Параллелизация внутри 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
Понятно что патчить надо apache, надо вырубать у него renegotiation.
В openssl я хочу залезть и посмотреть, что же это там за функция такая, которая дает такую нагрузку, возможно что можно ее заменить на какой-то более упрощенный аналог...
Дык не пойдет, не видно главного значения сколько запросов в секунду исполняется :)
Вобщем у меня на VPS получилось 900 штук в секунду что "на вскидку" равняется где-то 100 мегабитам доса...
Резьюм данной темы таков:
Вобщем в nginx нет никакой уязвимости, как я и говорил выше, есть просто не очень быстрая работа при установке SSL соединения, причем 2048 битные ключи примерно в 3 раза медленее чем 1024 битные.
В случае с nginx с помощью файроволла все легко лечится, путем установки ограничения на кол-во коннектов в секунду с одного IP.
А вот апач действительно под угрозой, через одно соединение можно хорошенько загрузить сервер.
Так что надо перекомпилировать апач с отключенным renegotiation, а еще лучше поставить его за nginx'ом :)
ps: на досуге может даже поковыряюсь в исходниках openssl, что-то они там такое ужасное замутили, что оно так тормозит...
Ваш вариант выдает ошибки SSL и не показывает сколько текущих коннектов и какая скорость h/s.
То что в случае ошибки оно само передергивается, я не спорю :) Но хочется видеть процесс и его скорость...
С точки зрения заложенной в программу логики правильно НЕ комментировать :)
Интересно мерить h/s это и есть критичная велечина, у меня на VPS она = 927.81 h/s
Не путайте следствие с причиной, происходит ошибка при renegotiation так как nginx его не поддерживает вот и выдается ошибка...
Чтобы ошибки не было надо "передернуть" коннект, обозначенным способом.
