Это он про вычисление PI говорил ;) Если поставить 8, то имхо хуже не будет, за исключением того, что память сожрется.
Вопрос в другом - нужно-ли Вам там 8? Может и с 2 все прекрасно работает, зачем жрать лишнюю память, когда она так нужна для БД?
Что именно Вы хотите сделать теперь?
Если просто обеспечить доступ к сайту "из нутри", то на сайте достаточно прописать правило, что если ip = ... то все-таки работаем с www.
Какой ИП изнутри отдается при nslookup site.ru? Контроллера домена?
Тогда еще можно на контроллере AD поднять маппинг его 80 порта (ну и 443 если надо) к порту www сервера :) но имхо это более через зад, чем способ №1
Хотя может быть Вам удобней вариант с маппингом.
Я на своем не пробовал, у мну как-то нет apache+ssl, надо будет настроить, но пока я пытался повалить nginx, случайно воткнул другой IP (а там у кого-то апач) я просто одну циферку в IP перепутал...
Дык вот пока я понял в чем дело, тот сервак перестал отвечать (пробовал пробиться с другого IP, не с атакующего), больше я не повторял сей эксперемент :)
Там был apache + ssl1 :)
Вы загрузку процессоров смотрели? В исходном тексте говорится о нескольких атакующих, просто их надо намного меньше чем для обычного ддоса.
Его придумали для параллельного выполнения параллельных процессов :) а не для того, чтобы загружать процессор... :D
netwind, iHead, Вы что мне оба доказываете? :D Что у nginx сейчас все хорошо и не надо ничего менять, ну дык я согласен :) не будем ничего менять в nginx (тем более ни Вы, ни я, не являемся авторами данного продукта).
К сожалению nginx ничего не знает о том, чем занимается второй процессор, по процессорам потоки распределяет ОС, вполне возможно что второй процессор курит бамбук, а текущий процессор загрузился на 100% и перестал адекватно отвечать ;) особенно если кто-то указал worker_processes=1 ;)
Из того, что число клиентов ЗНАЧИТЕЛЬНО превосходит количество процессоров НИКАК не следует что расходы на обмен и диспетчеризацию тоже будут значительными, я Вам это уже объяснял, все зависит от выбранной архитектуры и принципа разбиения на нити.
Я не спорю и никогда не спорил с тем, что излишние нагрузки на диспетчеризацию потоков это плохо.
Давайте кончать этот спор ни о чем :)
Я считаю что во всем нужна мера, и процессы которые действительно параллельны надо выполнять параллельно, если это не приводит к непомерным расходом на их диспетчеризацию, именно для этого создаются многопроцессорные ЭВМ и многоядерные процессоры ;)
В разумных пределах параллельное программирование действительно необходимость, такова природа вещей, как бы Вам не хотелось обратного ;)
😂😂😂 Все, я спорить больше с Вами не собираюсь, Вы перешли в режим "веры" и внушения мне чаго я знаю и понимаю, а чаго нет, такое не лечится...
Исходя из Вашей логики вообще паралельное программирование это зло и нужно только для декстопов... имхо Вы перешли грань добра и зла в своих утверждениях :)
занавес... 😂 аплодисменты...
Да, дейтсвительно спорить тут бесполезно, тем более о том почему кто-то что-то сделал или не сделал.
Просто имхо мнение что "так однозначно эффективней чем Вы предлагаете" это не конструктив...
Кому интересно, тот посмотрит код, а остальным и не надо :)
babnicks добавил 29.10.2011 в 19:58
Да причем тут десктопы-то??? Вы о чем вообще? С точки зрения программирования логично.
Просто логично что если процессы можно выполнить параллельно их надо выполнять параллельно, без фанатизма конечно, но все-же...
Никто не говорит о расплождении процессов по кол-ву коннектов, но возьмите Вы блин любой сервер БД или еще что-то, да там с десяток нитей наберется. А Вы про десктоп вспоминаете...
Зачем гнать-то уже конкретно?
И что? А какие расходы на синхронизацию в описываемом мной подходе? Вы их считали?
И вообще Вы понимаете что если уже подходить чисто формально, то nginx распралеливает обработку коннектов, только делает это не сам, а отдает другим процессам через проксирование.
Это чем отличается от создания внутри nginx'а хотя-бы отдельных нитей для разных проксируемых приложений и работы со статикой?
Также есть вариант создание нитей для каждого из описываемых location'ов, тоже возможно дало-бы свои +
Я не спорю с тем, что nginx хороший продукт, но у Вас какая-то странная иллюзия что nginx не нуждается в доработках, что это идеальный продукт :)
Какой еще обмен данными между потоками? Такие нити должны работают с одной кучей.
Синхронизация конечно нужна, как и в любой паралелльной системе, но имхо такая синхронизация требует минимальных накладных расходов ввиду разной функциональности нитей...
не убедительно :) если отборсить авторитет Сысоева, то не убедительно...
Это да, скорее всего так и есть, но nginx занимается проксированием (с хранением промежуточных данных), строит rb деревья (не разбирался для чего, но в исходниках есть) и много чаго еще делает... Делать эти задачи в отдельных нитях весьма логично.
Я думаю что эффект от создания такого функционального распараллеливания скорее всего был бы, но это усложнило бы и код и процесс отладки, а выйгрышь возможно был не более 5%
Возможно поэтому пока и не сделал, может и сделает когда-нить...
Гыг 😂
Только вот обнаружена такая интересная особенность:
Серверов там много, а вот проблемы ВСЕГДА в одних и тех же сегментах, абсолютно не понятное с точки зрения законов вероятности явление...
