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