Хм, исходников действительно нет, просто бесплатная сборка + платная поддержка кому нужно. В любом случае на месте разработчиков я бы связался с командой www.ecsystems.nl и выкупил все их коды и включил в основную ветку. Какой смысл изобретать велосипед и тратить человекоресурсы, если проще заплатить деньги за готовое. В любом случае огромное спасибо вам и за труды и за статью.
А как же сборка от nginx-win.ecsds.eu в которой и Fully ASLR and DEP compliant for shared memory и Select-boost и Multiple workers supported и FD_SETSIZE = 32768 и многое другое…
Вот полный список возможностей этой сборки:
All current nginx features (see with nginx.exe -V) (subject to Windows compatibility)
Consistent with original nginx code (subject to Windows compatibility)
FD_SETSIZE = 32768 (modded kernel), allows one worker to handle c250k+ (with optimization registry file)
Multiple workers supported! use no more than 2 workers for 1 core (cpu)
ngxLuaDB, the drizzle and dynamic loaded module solution
ngx_upstream_jdomain
cache_purge
nginx-http-concat
nginx-module-vts (Virtual host traffic status)
Или несколько человек делают дурную работу делая одно и тоже… или я чего-то недогоняю? Может разработчикам Nginx подсмотреть что и как сделано в этой сборке?
Рискну предположить — здесь много фрилансеров, которые получают доход в $$$, много тех, у кого зарплата в рублях выплачивается в эквиваленте по курсу, много тех кто вообще за рубежом работает. Думаю отсюда и радость — упала гривна в Украине, ты стал зарабатывать больше, упал в России рубль в 2 раза, ты стал в 2 раза богаче! Как тут не радоваться? А подобные решения дают ещё большей радости, ибо рубль от таких санкций упадёт ещё больше…
Если верить прогнозу «Финам Менеджмент» о 200руб. за $1 в марте, то чёрная пятница теперь будет каждый день :-)
P.S. Очень удобно сделали: http://zenrus.ru/
Дмитрий Анатольевич не знал что пользуется взломанной точкой доступа Wi-Fi на пляже в Крыму, вспоминая коды запуска ядерных ракет и вводя пароль 00000000…
Если у ответственных лиц возникнет подозрение, что это был не банальный взлом, то у неответственных лиц (простых людей) аналогично возникнет подозрение что это был фейковый взлом для получения предлога полной блокировки Twitter России, ну или как вариант получить от администрации Twitter возможность тотального контроля и блокировки всего что вздумается.
Очень хорошо, что есть такие замечательные компании и такой замечательный сервис. Мышки, клавиатуры, читалки… но простые батарейки это неожиданно :-) Видимо в Procter & Gamble берут пример с Logitech. Жаль что куда более серьёзные вещи так просто не меняют, даже наоборот. Например ASUS, эту компанию даже врагу не пожелаю. Вышла из строя батарея в ноутбуке — прислали старую покоцаную имеющую следы вскрытия, то ли Refubrished, то ли просто на замену хлам присылают. Сгорел SSD винчестер в их новом плоском ноуте аля Apple — прислали на замену SSD другой модели другого производителя с намного худшими скоростными характеристиками, но такой же ёмкости. Это всё равно что для ноутбука с IPS экраном прислать на замену TN матрицу. Это была моя последняя покупка чего-либо марки ASUS.
Добавлю. Возможно вы подумали, что при ограничении скорости учитываются вообще ВСЕ подключения к серверу, однако это не так. Учитываются конечно же только те соединения, которые установлены клиентом с тем location где прописан лимит. Т.е. если я качаю файл из ограниченного по скорости файлохранилища в 10 потоков и имеют 10к на поток (100k/10), а потом решил еще с форума на сайте скачать архивчик на пару гигабайт и тоже в 10 потоков, то мои первые 10 потоков из файлохранилища будут иметь ту же скорость (она не изменится), в то время как с форума я буду качать без ограничений в 10 потоков на максимальной скорости.
Если у администратора нет мозгов, то может он и сделает так, как вы тут всё описали. В нормальной ситуации ограничение будет выставлено только на location откуда загружаются файлы, например location /download/ {… }, соответственно серверу будет глубоко до лампочки какие ещё у пользователя открыты соединения, сколько их и что он там загружает (html, css, js и т.д.). Использовать данный модуль для ограничение скорости доступа ко всему сайту — это глупость ввиду описанных вами причин, он не для этого создан.
Дочитал. А вы в свою очередь читали мой комментарий? По моему про speed / ls->conn там предельно понятно всё написано — скорость делится на количество текущих соединений с сервером. И после этого вы спрашиваете: Или же ls->conn — это _текущее_ количество соединений?
Это лишь ваше мнение, что чему-то там далеко до правильного. Я так не считаю. Про какие-то там выборы соединений пользователя так вообще чушь, нигде ничего выбирать не требуется, ограничиваются все подключения разом. Модуль предельно чётко и прозрачно регулирует скорость и это именно то, что так давно ждали от Nginx. Данную функциональность в Nginx не вводили только лишь потому, что разработчики мало ориентированы на те нововведения, которые не нужны и не интересны им самим, а так же потому, что разработчиков (помимо Игоря Сысоева) до недавнего времени там было 1-2 человека (а может и сейчас столько) и в таком формате довольно тяжело реагировать на все «хотелки» пользователей.
Марихуана? ЛСД? Бросайте… Если установлено ограничение в 100к и пользователь качает в 1 поток, то у него будет скорость 100k. Выше представлена формула вычисления скорости, разделите 100/1 и подумайте что получится.
Сколько угодно причин можно придумать — тонкий канал (дешевая или вообще бесплатная VPS к примеру), перегруженный канал, ddos, файлообменные сервисы, premium загрузки (остальным минимум скорости), нашествие GoogleBot, YandexBot и прочих сканеров или пауков, банальное желание ЧЕСТНО порезать скорость под свои нужды. Да вообще мало ли для чего люди используют лимиты, если бы урезание скорости не было востребовано, то даже $limit_rate в Nginx наверное бы не было, однако же оно есть.
Смотрите, Nginx лимитирует скорость для каждого запроса примерно так (мои предположения):
r->main->limit_rate = $limit_rate; (а именно $limit_rate указанный в конфиге запрошенного location или хоста)
Модуль представленный в статье так же лимитирует скорость каждого запроса (соединения), но несколько иначе, вот выдержка прямо из кода модуля:
speed = lscf->speed;
r->main->limit_rate = speed / ls->conn; (а именно limit_speed указанный для зоны в конфиге запрошенного location или хоста)
т.е. скорость делится на количество текущих соединений с сервером. Как видите всё предельно просто.
Более того, поскольку используются зоны, то вместо $binary_remote_addr можно использовать всё что угодно для создания нужной зоны ограничений. Можно установить лимиты на домен, страну (geoip), да хоть по имени браузера или зарезать скорость для Googlebot.
Модуль используется с ноября 2013 года на нескольких серверах, всё работает на ура, никаких сбоев не было. Буквально вчера собрал на очередном сервере Nginx 1.6.0 (последняя версия) с этим модулем (поэтому и решил написать статью, уж больно модуль хороший). Хотя признаюсь — модуль совершенно неизвестный от сомнительного китайского товарища, но на практике претензий к нему нет. Всевозможные конфигурации и ситуации конечно не тестировались, поэтому подводные камни могут быть, но исправить ошибку может любой — да здравствует opensource.
Вот так и получается, что многие используют set $limit_rate наивно полагая что ограничили максимальную скорость для клиента вне зависимости от того в 1 поток он качает или в 10. А потом жалуются что какой-то пятиклассник забил им канал качая в 10 потоков Звездные Войны в Blu-Ray формате…
Установить описанный в статье модуль и ограничивать скорость для нее (вне зависимости от числа соединений), как сказал esc. Без этого модуля Nginx попросту не сможет ограничивать скорость вне зависимости от числа соединений, он этого попросту не умеет.
О чём речь? Как раз таки Nginx этого и не умеет, он не умеет ограничивать скорость ни на домен, ни на ссылку, ни по IP клиента. Вернее он делает это, но только на каждый отдельный запрос (соединение). А извращаться с отдачей через PHP или ограничивать клиента одним соединением на IP или пусть даже на сгенерированную ссылку — это костыли. Описанный в статье модуль как раз таки решает данную проблему ограничивая скорость по IP.
Не ограничивают скорость на ip потому... Вы про разработчиков Nginx? Если они сознательно что-то не хотят делать в силу своих убеждений, это вовсе не значит что это не надо пользователям их программного продукта.
Боюсь вы ошибаетесь, Nginx не умеет ограничивать скорость для IP, только на отдельное соединение. Предполагаю что вы подумали про это:
if ($slow) {
set $limit_rate 4k;
}
Выдержка из документации: Ограничение устанавливается на запрос, поэтому, если клиент одновременно откроет два соединения, суммарная скорость будет вдвое выше заданного ограничения.
И не будет его в Open Server до тех пор, пока разработчики не сделают возможность остановки MongoDB из командной строки. Сейчас они предлагают остановку через внутренний shell командой «db.shutdownServer()» или остановку сервиса «net stop mongodb» — это имхо бред для ситуации с портативным запуском. Ну а убивать прочесс как-то боязно, вдруг база поломается. Так что как только они сделают то, что должны были сделать еще 100 лет назад — так сразу MongoDB в Open Server и появится :-)
А если нет «сети оператора»? Что мне делать если я с другом в тёмный лес пошел за грибами?.. Я уж думал что вот оно, свершилось, а тут на тебе… обычный голосовой чат и радио по сети. Сделали ли бы лучше по настоящему автономную связь, чтобы телефоны по Bluetooth или Wi-fi связывались и работали в лесу как настоящие рации без всяких там интернетов, сетей операторов и прочего ненужного. А так считаю для себя этот сервис бесполезным.
Вот полный список возможностей этой сборки:
Или несколько человек делают дурную работу делая одно и тоже… или я чего-то недогоняю? Может разработчикам Nginx подсмотреть что и как сделано в этой сборке?
P.S. Очень удобно сделали: http://zenrus.ru/
Это лишь ваше мнение, что чему-то там далеко до правильного. Я так не считаю. Про какие-то там выборы соединений пользователя так вообще чушь, нигде ничего выбирать не требуется, ограничиваются все подключения разом. Модуль предельно чётко и прозрачно регулирует скорость и это именно то, что так давно ждали от Nginx. Данную функциональность в Nginx не вводили только лишь потому, что разработчики мало ориентированы на те нововведения, которые не нужны и не интересны им самим, а так же потому, что разработчиков (помимо Игоря Сысоева) до недавнего времени там было 1-2 человека (а может и сейчас столько) и в таком формате довольно тяжело реагировать на все «хотелки» пользователей.
r->main->limit_rate = $limit_rate; (а именно $limit_rate указанный в конфиге запрошенного location или хоста)Модуль представленный в статье так же лимитирует скорость каждого запроса (соединения), но несколько иначе, вот выдержка прямо из кода модуля:
speed = lscf->speed; r->main->limit_rate = speed / ls->conn; (а именно limit_speed указанный для зоны в конфиге запрошенного location или хоста)т.е. скорость делится на количество текущих соединений с сервером. Как видите всё предельно просто.
Более того, поскольку используются зоны, то вместо $binary_remote_addr можно использовать всё что угодно для создания нужной зоны ограничений. Можно установить лимиты на домен, страну (geoip), да хоть по имени браузера или зарезать скорость для Googlebot.
Модуль используется с ноября 2013 года на нескольких серверах, всё работает на ура, никаких сбоев не было. Буквально вчера собрал на очередном сервере Nginx 1.6.0 (последняя версия) с этим модулем (поэтому и решил написать статью, уж больно модуль хороший). Хотя признаюсь — модуль совершенно неизвестный от сомнительного китайского товарища, но на практике претензий к нему нет. Всевозможные конфигурации и ситуации конечно не тестировались, поэтому подводные камни могут быть, но исправить ошибку может любой — да здравствует opensource.
Не ограничивают скорость на ip потому... Вы про разработчиков Nginx? Если они сознательно что-то не хотят делать в силу своих убеждений, это вовсе не значит что это не надо пользователям их программного продукта.
Выдержка из документации: Ограничение устанавливается на запрос, поэтому, если клиент одновременно откроет два соединения, суммарная скорость будет вдвое выше заданного ограничения.