Ограничение скорости — это концепция ограничения объема доступа к ресурсу. Например, вы знаете, что база данных, к которой обращается ваше приложение, может безопасно обрабатывать 1000 запросов в минуту, но не уверены, что она может обрабатывать намного больше. Вы можете установить в своем приложении ограничитель скорости, который разрешает 1000 запросов в минуту и отклоняет любые дополнительные запросы, прежде чем они смогут получить доступ к базе данных. Таким образом, ограничьте скорость вашей базы данных и разрешите вашему приложению обрабатывать безопасное количество запросов без потенциально серьезных сбоев в вашей базе данных.
Существует несколько различных алгоритмов ограничения скорости для управления потоком запросов. Мы рассмотрим 4 из них, которые будут представлены в .NET 7.
Здравствуйте, BlackEric, Вы писали:
BE>Похоже, в 7 dotnete появится интереснейшая фича — встроенное лимитирование нагрузки.
Нашли на что молиться! Наши юные индусские друзья вновь придумали фиксированную очередь?
Тонкость в том, что если у тебя ОДНА база и много апп-серверов, НИКАКОГО смысла твоя "ограничивалка" не имеет, ибо требуется полная синхронизация к-ва потоков по всем апп-серверам. И как они собрались это решать??
Ну и потом, ограничение — не выход, нужно увеличивать мощность, для чего на базе смотрят показатели и делают выводы — никакие дотнеты тут не нужны.
Здравствуйте, Kolesiki, Вы писали:
K>Нашли на что молиться! Наши юные индусские друзья вновь придумали фиксированную очередь?
Ну, технология, однозначно, не новая, но в чём смысл так пыхать ядом на её внедрение в конкретной платформе?
K>Тонкость в том, что если у тебя ОДНА база и много апп-серверов, НИКАКОГО смысла твоя "ограничивалка" не имеет, ибо требуется полная синхронизация к-ва потоков по всем апп-серверам. И как они собрались это решать??
А в чём проблема держать в каком-нибудь внешнем кеше, типа условного редиса (или даже той же базы, в служебной табличке), количество актуальных серверов и каждому серверу лимитировать себе нагрузку, синхронизируясь с кешем раз в пару минут для актуализации информации о числе серверов? Задачка на пару сторипоинтов от силы.
При этом я сталкивался с ситуацией, когда, например, криво написанный воркер забивал доступные коннекты к базе. И быстрым хотфиксом на данный случай (нормальное решение — однозначное переписывание воркера) вполне могло бы быть вот такое ограничение.
K>Ну и потом, ограничение — не выход, нужно увеличивать мощность, для чего на базе смотрят показатели и делают выводы — никакие дотнеты тут не нужны.
Если типовая нагрузка от клиентов такая, что ложится база, то лимитирование числа запросов от бека тут, действительно, не спасёт.
Но, возвращаясь к теме воркеров, сценарий, когда тяжёлый воркер перед запуском проверяет нагрузку системы и, если идёт пик, лимитирует число своих запросов к базе, отрабатывая пусть дольше, но без краха системы, тоже вполне себе нормальное решение как альтернатива масштабированию базы, которое может быть очень не дешёвым в некоторых условиях.
А ещё можно лимиты на, например, сервера, отвечающие за внешние API-запросы повесить. Чтобы сайт стабильно работал, а дополнительный функционал уже по остаточному принципу, если кто-то случайно API ддосить начнёт.
В общем, повода для "попыхать ядом" как-то не вижу, а вот варианты применения — без особых проблем придумать могу.
"Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живете". (с) Макконнелл, "Совершенный код".
Здравствуйте, Александр Кузнецов, Вы писали:
АК>Здравствуйте, Kolesiki, Вы писали:
K>>Нашли на что молиться! Наши юные индусские друзья вновь придумали фиксированную очередь? АК>Ну, технология, однозначно, не новая, но в чём смысл так пыхать ядом на её внедрение в конкретной платформе?
Где ты здесь увидел "яд"? Научись выражению "здравый скепсис с долей юмора"! Не раз пригодится в отношении "мелкомягких изобретений" — очередные "технологии доступа к СУБД" или "ГУЁвая библиотека".
K>>Тонкость в том, что если у тебя ОДНА база и много апп-серверов, НИКАКОГО смысла твоя "ограничивалка" не имеет, ибо требуется полная синхронизация к-ва потоков по всем апп-серверам. И как они собрались это решать?? АК>А в чём проблема держать в каком-нибудь внешнем кеше, типа условного редиса....
Вот скажи, тебе лишь бы поспорить или ты наконец ВДУМАЕШЬСЯ в то, что сам пишешь и не читаешь в моём сообщении?? Я именно это и сказал! "Зачем нужен какой-то дотнет, когда всё решается внешними тулзами"?
АК>При этом я сталкивался с ситуацией, когда, например, криво написанный воркер забивал доступные коннекты к базе
Дотнет к этому никаким боком. Кривые погромизды с ЛЮБЫМИ библиотеками налажают.
K>>Ну и потом, ограничение — не выход, нужно увеличивать мощность, для чего на базе смотрят показатели и делают выводы — никакие дотнеты тут не нужны.
АК>Если типовая нагрузка от клиентов такая, что ложится база, то лимитирование числа запросов от бека тут, действительно, не спасёт. АК>Но, возвращаясь к теме воркеров, сценарий, когда тяжёлый воркер перед запуском проверяет нагрузку системы и, если идёт пик, лимитирует число своих запросов к базе, отрабатывая пусть дольше, но без краха системы, тоже вполне себе нормальное решение как альтернатива масштабированию базы, которое может быть очень не дешёвым в некоторых условиях.
"проверяет нагрузку системы" — причём тут "ограничитель скорости, встроенный в дотнет"? Проверять ты можешь в ЛЮБОМ языке! Ты вообще основную тему-то понял? Пишешь-пишешь тут — то случаи, то способы решения, а сути не видишь.
АК>В общем, повода для "попыхать ядом" как-то не вижу
Да не, это ты тут мистер Дартаньян и кэп Очевидность в одном флаконе — сам придумал "яд", сам придумал проблемы, САМ же их решил БЕЗ помощи дотнета и внезапно решил, что это ТЫ тут весь в белом! Нет, дорогой, ты пролажал самую суть моего коммента и просто воевал с мельницей. Вернись к моему сообщению и поясни, ЧТО КОНКРЕТНО ты находишь неверным. Именно мои слова, а не то, что ты сам себе придумал.
Здравствуйте, BlackEric, Вы писали:
BE>Вы можете установить в своем приложении ограничитель скорости, который разрешает 1000 запросов в минуту и отклоняет любые дополнительные запросы
Обратите внимание, насколько ТУПОЕ решение принимает M$ даже в свете далеко не новой проблемы! ОГРАНИЧИТЬ! Урезать. По газонам не ходить!
В то время, как вдумчивый инженер либо сделал бы балансер, либо как ВРЕМЕННАЯ заплатка — специальный ответ клиенту: "извините, тут немного нагрузка, МЫ РАБОТАЕМ, но с трудом. Повторите свой запрос через 200 миллисекунд". Таким образом клиент (напр. браузер) сделал бы передышку, показал человеку вразумительное сообщение (что ничего не упало) и продолжил бы работу. ВОТ НА ЭТО микрософту мозгов нехватает! А ограничить — много ума не надо.
Здравствуйте, Kolesiki, Вы писали:
K>>>Нашли на что молиться! Наши юные индусские друзья вновь придумали фиксированную очередь? АК>>Ну, технология, однозначно, не новая, но в чём смысл так пыхать ядом на её внедрение в конкретной платформе? K>Где ты здесь увидел "яд"? Научись выражению "здравый скепсис с долей юмора"! Не раз пригодится в отношении "мелкомягких изобретений" — очередные "технологии доступа к СУБД" или "ГУЁвая библиотека".
Вот прямо здесь и увидел. Возможно в тех кругах, где ты постоянно общаешься, это и называется "здравый скепсис с долей юмора", но большинство известных мне людей называют это либо "пыхать ядом", либо используют более жёсткие термины.
K>>>Тонкость в том, что если у тебя ОДНА база и много апп-серверов, НИКАКОГО смысла твоя "ограничивалка" не имеет, ибо требуется полная синхронизация к-ва потоков по всем апп-серверам. И как они собрались это решать?? АК>>А в чём проблема держать в каком-нибудь внешнем кеше, типа условного редиса.... K>Вот скажи, тебе лишь бы поспорить или ты наконец ВДУМАЕШЬСЯ в то, что сам пишешь и не читаешь в моём сообщении?? Я именно это и сказал! "Зачем нужен какой-то дотнет, когда всё решается внешними тулзами"?
И вот тут тоже. Хамишь, причём откровенно.
А если по делу, то что ты предпочитаешь: внешнее хранилище числа потоков, простенький самописный апи синхронизации и _встроенную_ утилиту ограничения потоков на локальном сервере, или всё то же самое, только ещё и ограничивалку руками писать?
Я, если ограничивалка сделана без косяков и полностью подходит по функционалу, однозначно предпочту готовое решение. Нет, лучше бы, конечно, полное решение "из коробки", но чего пока нет, того нет. Возможно, в следующей версии появится, или можно самому написать и предложить.
АК>>При этом я сталкивался с ситуацией, когда, например, криво написанный воркер забивал доступные коннекты к базе K>Дотнет к этому никаким боком. Кривые погромизды с ЛЮБЫМИ библиотеками налажают.
Да без вопросов. Вот только кривые погромизды налажали хз когда, переписать воркер "с нуля" быстро не получится, а продакшен падает вот прямо сейчас. И да, сама проблема к дотнету никакого отношения не имеет. Вот только лично мне в этой ситуации возможность быстро, встроенными средствами дотнета, искусственно ограничить поток запросов на базу, неплохо бы так сэкономила время.
АК>>Если типовая нагрузка от клиентов такая, что ложится база, то лимитирование числа запросов от бека тут, действительно, не спасёт. АК>>Но, возвращаясь к теме воркеров, сценарий, когда тяжёлый воркер перед запуском проверяет нагрузку системы и, если идёт пик, лимитирует число своих запросов к базе, отрабатывая пусть дольше, но без краха системы, тоже вполне себе нормальное решение как альтернатива масштабированию базы, которое может быть очень не дешёвым в некоторых условиях. K>"проверяет нагрузку системы" — причём тут "ограничитель скорости, встроенный в дотнет"? Проверять ты можешь в ЛЮБОМ языке! Ты вообще основную тему-то понял? Пишешь-пишешь тут — то случаи, то способы решения, а сути не видишь.
Да нет, сдаётся мне, что это кое-кто другой тут не особо утруждает себя попыткой даже не понять суть, а просто прочитать ответы оппонента до конца. Специально для тебя выделил выше слово "лимитирует".
АК>>В общем, повода для "попыхать ядом" как-то не вижу K>Да не, это ты тут мистер Дартаньян и кэп Очевидность в одном флаконе — сам придумал "яд", сам придумал проблемы, САМ же их решил БЕЗ помощи дотнета и внезапно решил, что это ТЫ тут весь в белом! Нет, дорогой, ты пролажал самую суть моего коммента и просто воевал с мельницей. Вернись к моему сообщению и поясни, ЧТО КОНКРЕТНО ты находишь неверным. Именно мои слова, а не то, что ты сам себе придумал.
Ну то есть ты увидел, что в языке/платформе появилась новая конкретно для этого языка/платформы функциональная возможность, пришёл на форум, высказал своё "фе", а когда тебе накидали сценариев, при которых эта функциональная возможность может быть крайне полезна (альтернатива — написание примерно такого же функционала руками, или переписывание кучи кода в условиях жёсткого цейтнота), лихо называешь противника д'Артаньяном? Ну-ну, месье, а ваша-то лошадь, случайно, не "желтовато рыжей масти, с облезлым хвостом, и распухшими боками"?
"Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живете". (с) Макконнелл, "Совершенный код".
Здравствуйте, Kolesiki, Вы писали:
BE>>Вы можете установить в своем приложении ограничитель скорости, который разрешает 1000 запросов в минуту и отклоняет любые дополнительные запросы K>Обратите внимание, насколько ТУПОЕ решение принимает M$ даже в свете далеко не новой проблемы! ОГРАНИЧИТЬ! Урезать. По газонам не ходить!
Это не тупое решение. Это _простое_ решение. Точно также, как большинство балансеров работают по принципу простой карусели вместо интеллектуальной оценки степени загруженности каждого балансируемого сервера.
K>В то время, как вдумчивый инженер либо сделал бы балансер, либо как ВРЕМЕННАЯ заплатка — специальный ответ клиенту: "извините, тут немного нагрузка, МЫ РАБОТАЕМ, но с трудом. Повторите свой запрос через 200 миллисекунд". Таким образом клиент (напр. браузер) сделал бы передышку, показал человеку вразумительное сообщение (что ничего не упало) и продолжил бы работу. ВОТ НА ЭТО микрософту мозгов нехватает! А ограничить — много ума не надо.
Вообще-то как раз в связке с внешним балансером — это более чем нормальное решение. Каждый отвечает ровно за свою зону ответственности.
Сервер имеет ограничение на число одновременно обрабатываевых запросов, и отфутболивает всё, что сверху, не падая при этом сам. Внешний балансер же, получая такой ответ, просто перекидывает запрос на следующий сервер "карусели" (при этом сам никакими расчётами не занимается). В дополнении, на число таких ответов может быть завязана команда на автоматический подъём дополнительных контейнеров с API, если проблема там, а не уже на стороне базы.
"Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живете". (с) Макконнелл, "Совершенный код".
Наши юные индусские друзья вновь придумали фиксированную очередь? 
