Есть метод Web API, который запускается нагрузочным софтом 500 раз одновременно, и согласно внутреннему логу выполняется в среднем 200 мс, в то-же время нагрузочный софт показывает среднее время отклика 2.5 секунды. Т.е. это где-то в IIS что-то не успевает. Как это что-то найти и что можно подкрутить что-б уменьшить время отклика? С увеличением количества одновременных запросов время отклика растет, 1000 запросов в среднем потребляет уже 4.5 секунды

hVosttПереписать метод WebAPI и сделать его асинхронным. Проблема с ограниченным количеством потоков в пуле уже не раз обсуждалась и мусолилась.

не оказывает влияния, и даже (правда в пределах погрешности) замедляет среднее арифметическое отклика. Возможно потому, что сам по себе запрос занимает порядка 20-30 миллисекунд (не 200 как сначала написал) и асинхронное исполнение не дает каких-то преимуществ

handmadeFromRuоткуда у вас инфа что не даст улучшения отклика? асинхроность дает улучшение но не 100%, завист от того как написано и как использутся потоки. Рекомендация хвоста имеет место. И то что в иисе кол-во потоков ограничено дает вам проблемку. я вижу тут решение в балансировщике и n-копиях приложения и тогда вы размажите пики по машинам. да 500 реквестом в секунду эт не мало уже так то имхо

пс. включите внутрений лог ииса, может подскажет. insight врядли покажет к примеру так как вы говорите что у вас там 20мс
инфа оттуда, что заменил в EF метод на асинхронный и запустил через нагрузочый софт, который мне и показал статистику. Я так понимаю асинхронность надо пихать не в каждый метод, а там, где запросы медленно выполняются. 30 миллисекунд судя по всему достаточно быстро что-бы никаких выгод не было, и даже возможно наоборот идет просадка из-за записка асинхронного потока

hVosttЧёт мне лень разжёвывать очевидное. Ты не прав. Хочешь разобраться в чём и почему, нагуглишь, не хочешь, оставайся в неведении.

ок, асинхронное или нет не так и важно. Почему IIS из 40 миллисекунд делает 2 секунды? Чем он там занимается? Это при асинхронном запуске если что. Как можно это дело оптимизировать? Или только лоад балансер с несколькими серверами тут поможет?

hVostt https://habrahabr.ru/post/142372/

Статья от бородатого 2012 года.
thanks, прочитаю

handmadeFromRuпро асинхроност ну чет аргумет слабенький с таким то тестом, я уже писал асинхроность не панацея и надо понимать зачем.
ну 30мс эт 1 метод в бд или что? у тебя есть время ответа полное страницы со всеми запросами? чем мерил то? у тебя там какой нить Glimpse или MiniProfiler стоит?

30 мс - это целиком весь процессинг web api, от момента первого message handler'a, до его-же но уже на выходе, я там лог привинтил который меряет затраченное время. Т.е. сам непосредственно запрос к БД еще меньше будет.
Нагрузочный софт это jmeter. Но похожих результатов можно и в фиддлере добится, если ты скажем запустишь такой метод:



раз 400, то разницы между блокирующим и асинхронным результатом в проиводительности почти не будет. Вот где-то с 50 миллисекунд она начинает появлятся, и скажем если поставить 300, то будет уже совсем чувствительно

Пока читал тут ссылки по поводу потоков, нашел одно очень полезное замечание

Pop quiz: If you have a thread that is doing a lot of computational work and using the CPU heavily, and this takes a while, should you switch to another thread? No! The current thread is efficiently using the CPU, so switching will only incur the cost of a context switch. Ok, well, what if you have a thread that makes an HTTP or SOAP request to another server and takes a long time, should you switch threads? Yes! You can perform the HTTP or SOAP request asynchronously, so that once the "send" has occurred, you can unwind the current thread and not use any threads until there is an I/O completion for the "receive". Between the "send" and the "receive", the remote server is busy, so locally you don't need to be blocking on a thread, but instead make use of the asynchronous APIs provided in .NET Framework so that you can unwind and be notified upon completion.

https://blogs.msdn.microsoft.com/tmarq/2010/04/14/performing-asynchronous-work-or-tasks-in-asp-net-applications/

По сути оно означает, что утверждение о необходимости асинхронного выполнения в asp.net не всегда верно. Т.е. я запустил что-то что грузит проц, то никакого переключения не нужно и только вредит т.к. необходимо переключение контекста. То-же самое видимо относится и к обсуждению выше про очень маленькие запросы < 50 мс, когда пользы от переключения контекста нет никакого. А вот длинные запросы, когда мы запросили sql server и он там думает полсекунды - уже есть т.к. не нужен никакой поток что-бы просто ждать.

Т.е. насколько я понимаю ситуация следующая: Пришло 500 одновременных запросов к IIS. Сервер не может создать 500 потоков просто потому, что это нерационально с точки зрения операционки и он ограничен 25-50 потоками на процессор. Поэтому если методы блокирующие, то одновременно исполняется 50 запросов, остальные ждут. Если методы асинхронные, то метод запускает запрос к sql server, после чего поток освобождается т.к. что-бы ждать ответ никакой поток не нужен. Когда через полсекунды приходит ответ - то из пула в 50 потоков запрашивается один для генерации ответа.
Отсюда следует, что сам я недолжен создавать никакие потоки т.к. эффект будет аналогичен блокирующему методу. Смысл асинхронных методов исключительно в том, что для ожидания ответа от другого сервера поток не нужен. Если для обработки метода создается поток на этой-же машине - то толку от такого асинхронного метода тоже нет. Все верно?

hVosttНе верно ни разу.
тем не менее, в приведенной ссылке утверждается именно это

Q4) Should I create my own threads (new Thread)? Won’t this be better for ASP.NET, since it uses the CLR ThreadPool.

A4) Please don’t. Or to put it a different way, no!!! If you’re really smart—much smarter than me—then you can create your own threads; otherwise, don’t even think about it. Here are some reasons why you should not frequently create new threads:
1) It is very expensive, compared to QueueUserWorkItem.
2) Before you allow your thread to exit, you must check for pending I/O because your new thread might call into a .NET Framework API that initiates an asynchronous operation, and there’s really no way for you to know whether or not this happened unless you don’t call into framework APIs.
3) The performance of the system hinges on the fact that only a reasonable number of threads are executing at any given time , and if you start creating your own threads it will then become your responsibility to maintain performance of the system. By the way, if you can write a better ThreadPool than the CLR’s, I encourage you to apply for a job at Microsoft, because we’re definitely looking for people like you!

т.е. как я говорил идея такая, что в системе должно быть быть ограниченное число потоков, скажем 50 на проц. Именно на этом факте зиждется это ограничение IIS, иначе-бы оно без проблем просто создало 500 потоков и не морочило нам голову.

hVosttА вот здесь ты начинаешь выдумывать. Какие 50 мс? Если у тебя I/O операция, смысл сделать работу с ней асинхронной. И это верно при любых раскладах. По какие секунды идёт речь?? Я же давал ссылку, нет там никаких полсекунд и уж тем более секунд. Однако добавление асинхронности сильно изменило ситуацию под нагрузкой.

Короче хватит выдумывать. Есть простой правило: CPU bound синхронно, I/O bound асинхронно. И ничего не надо придумывать и фантазировать. Точка.
50 мс исходя из моих тестов. Вопрос не в конкретно 50 мс, а в том, что на краткосрочную операцию переключение контекста перевесит выгоду от неиспользования потока

handmadeFromRustenford,

иис устроен так что берет потоки на реквест из тридпула для своего процесса, не надо просто так создавать потоки, это разумно. колв-о потоков на процесс можно управлять, если просто хреначит потоки на каждый реквест то в определеную цифру у тебя процессор не справиться или все ресурсы выжрет, а так оно ждет ожидания выполнения. Создание процесса дело накладное, а так у тебя есть набор который жаждет что сделать. увеличь тридпул в коде на свой процесс ценой выжирания больше памяти.. думаю 500 реквестов в секунду таким образом можно поглодить. у so я когда то посчитал по их статье выходило 2500 реквестов в секунду.

п.с. посмотри сколько у тебя щас активный потоков по умолчанию и задай цифру побольше https://msdn.microsoft.com/ru-ru/library/system.threading.threadpool.setmaxthreads(v=vs.110).aspx
имеется ввиду вот эта настройка, верно? Я так понял что это где-то в файле машинного конфига ставится, пока с ней не игрался. Вообще, threadpool он на все машину общий, верно? Т.е. теоретически если я поставлю 50 потоков на процессор, и они все займутся моими реквестами, то все остальные процессы на машине (всякие сервисы и прочее) начнут от этого страдать, верно?

hVosttУже замерил издержки на переключение контекста? Что тебя так пугает не пойму?

меня ничего не пугает, я просто говорю что краткосрочные асинк вызовы не принесут пользы, и об этом написано в том числе и в обсуждаемых линках. То, как делать это на практике это другой вопрос, и логично будет следовать конвенции что все дб вызовы делались ансинхронно просто потому, что так удобнее в командной разработке. Но я сейчас в теории разбираюсь, а не в конвенциях

handmadeFromRuп.с. посмотри сколько у тебя щас активный потоков по умолчанию и задай цифру побольше https://msdn.microsoft.com/ru-ru/library/system.threading.threadpool.setmaxthreads(v=vs.110).aspx

установка количества потоков не помогает. Thread.GetAvailableThreads() вообще выдает 32760 доступных потоков, а при загрузке 500 юзерами их число снижается примерно на 15-20, а ни как не на 500, т.е. несмотря на то, что потоки в пуле есть - IIS их просто не использует и выстраивает очередь.
Вычитал, что Thread Pool не выдает сразу 500 потоков даже если есть в них потребность, типа защитная фича, он с промежутком где-то в секунду-две выдает сколько-то там потоков. Это видимо то, что и происходит.
Это будет видно если провести следующий эксперимент - запихать следующий код в message handler:




Он создает новый поток, который просто спит. Так вот на 500 юзерах это полностью валит сервер, т.е. очевидно что потоки просто не выдаются из пула, несмотря на то, что их там 32 тыщи доступных.
Thread.SetMinThreads(), который теоретически должен фиксить это тоже ничем не помогает.

Также установка в machine.config настоек потоков, которые должны фиксить данную ситуацию для IIS тоже имеют нулевой эффект:




Как и Threads per Processor Limit. В общем хорошо майкрософт защитились, наделали переключателей и просто не обращают на них внимание.

Как-же заставить тогда IIS обрабатывать такие сценарии-то? Зачем такую жадную логику туда накрутили, ведь ограничение по потокам имеет смысл только в случае когда потоки крутяться на это-же самой машине, а веб сервер в основном открывает async потоки, которые не грузят процессор

skyANAstenford,

во первых autoConfig="true" надо убрать
во вторых что показывает Performance Monitor? на какой нагрузке запросы начинают вставать в очередь, сколько при этом выполняется, сколько всего, каково время выполнения?

и зачем все это нужно? 500 запросов в секунду - это 43 200 000 запросов в сутки
откуда Вы столько планируете получить?
круто, спасибо, вот сейчас сразу зашевелилась в несколько раз быстрее на "тяжелых" (занимающих сотню-другую мс) запросах. Надо посмотреть только что там с рекомендованными значениями этих параметров, а то непонятно почему по умолчанию стоят настолько низкие.
Тем не менее, на "быстрых" запросах (порядка 50 мс на запрос) ситуация примерно такая-же, как и была, либо улучшилась незначительно.
Performance Monitor я не запускал, с ним разбираться надо как там счетчики нужные активировать, пока времени нет. В Task Manager'e показатели памяти, процессора и диска вообще почти не меняются, только активность сетки резко подскакивает, возможно она стала узким местом тут.
JMeter показывает картинку ниже, это 500 запросов, видно что отклики начинаются примерно с одной секунды, и линейно растут пока не достигают 3.6 секунды. Среднее выходит 1.8

500 запросов - это техзадание. Надо что-бы прошел стресс-тест на 500 запросов, и запросы не вылезли за несколько секунд. И если "легкие" запросы еще ничего, 1.8 секунды это нормально, "тяжелые" начинают выдавать среднее под 10-15 секунд. Хотя сейчас уменьшилось под 2-3 секунды с этими настройками

hVosttТЗ это ок, можно нацелиться на этот результат. Что будете делать, когда появятся пики по 1000+? Дальше ковырять конфиги и пытаться всё нарулить количеством выделенных потоков?

когда потребуется 1000, то это сначала вписывается в спецификацию, теститься на существующем железе, подкручиваются параметры типа тех что выше, если не помогает, то я согласен что надо выявлять узкое место Performance Monitor'ом, после чего выдавать новые характеристики рекомендуемого железа.

hVosttЯ всё ещё не понимаю, чё вы так упёрлись в потоки?
это не я уперся, это IIS уперся и не дает потоки, пока ему явно это не скажешь.
В общем по итогам топика получается следующая стратегия при разработке web api:

- IIS (точнее CLR thread pool) по умолчанию выделяет очень мало потоков из соображений оптимальности, и следовательно они являются ценным ресурсом
- Все операции по вызову БД или сторонних сервисов заворачиваются в async для экономии потоков IIS
- При тестировании, если время отклика слишком большое, то в машинном конфиге надо увеличить количество одновременно выполняемых потоков, но только при условии, что эти потоки занимаются асинхронными вызовами и реально не нагружают систему. На самом деле это 99% всех вебсервисов т.к. они все работают с базами данных. Если-же сервис занимается обработкой чего-то у себя в памяти, то лучше ничего не трогать
- Если это не помогает, то выяснять Performance Monitor'ом узкое место т.к. значит уже уперлись в физические ресурсы

hVosttвот даже не знаю что сказать. сегодня какой год? разве так решают сегодня проблему хайлоад? я очень сомневаюсь, что вы, не обладая парком машин разных конфигураций, чтобы провести полноценный съём бенчей, сможете выдать адекватные «новые характеристики рекомендуемого железа», разве что не с потолка.

именно так всегда и решали, временами просто аппроксимируя железо если требования возрастали к уже существующей системе. Как провайдер, мы сами определяем софт и железо, который клиент обязан обеспечить что-бы выполнялись его требования к софту. Никакого парка различных конфигураций нет и не нужно, это все решается созданием виртуалок с описываемыми требованиями, либо в простых случаях обходятся и без виртуалок, это собственно проблема админов и QA, а не разработчиков, как все это дело тестировать
Интересно послушать конечно каким-же образом вы решаете проблему требований к железу не имея возможности их тестировать

hVosttа толку от того, что он их будет давать? вы решаете не реальную задачу, а выдуманную, которая не имеет никакого отношения к реальности.

примерно, как мне защититься от кирпичей, падающих на меня с домов, когда я выйду на улицу?

если у вас операции асинхронные, делайте async, и проблема с потоками решается, до определённых границ конечно, но за рамками этих границ вас уже не спасут никакое количество потоков.

если у вас операции вычислительные, то увеличение количества потоков это как сшить не одну, а 8 шапок из одной и той же шкуры. разрешаю воспользоваться логикой

задача реальная, и именно так клиент (как я понимаю) собирается тестировать наш софт. Это раз. А два, что это вполне адекватный подход с их стороны на мой взгляд, т.к. опять-же у них требование обеспечить полноценную работу 500 юзеров, и система не должна подвиснуть больше чем на 2-3 секунды в таких случаях.
Выставив в их конфиге повышенное число потоков мы эту задачу получается решим. Это то, что и требуется. И судя по всему, именно так это и должно быть в принципе т.к. очевидно майкрософтовские дефолты расчитаны на работу сервера в "одиночку". Наш-же аппсервер во всех своих методах делает БД запросы. Следовательно, дефолтные значения в машинном конфиге неоптимальны по определению

hVosttне очень похоже на стратегию, да и не вижу ничего про горизонтальное масштабирование. поэтому это всё как-то курам на смех, учитывая что нагрузка в веб приложениях никогда почти не бывает линейная и может подскакивать до огромных показателей, а вы к этому совершенно не готовы.
Совершенно неконструктивная критика. Если с чем-то несогласны, то и пишите конкретно с чем и почему. Что значит не бывает линейная и может подскакивать до огромных показателей ? Это именно то, что мы тут уже 2 страницы обсуждаем - нелинейный подскок до 500 запросов. Больше не будет т.к. это клиент указал в своих требованиях. Если он посадит 1000 пользователей без консультации с нами, то это не наша проблема. Решение выявлено - тьюнить дефолты машинного конфига до момента, пока не перестает помогать. После чего идет расшивка узких мест в железе. Вертикальная или горизонтальная не особо относится к данному топику т.к. это задача не разработчиков, а админов. Скорее всего да, создадут несколько серверов и посадят их на лоад балансер.

skyANAесли не секрет, а сколько у клиента вообще пользователей? Что за предметная область?
У него уже есть какой-то софт?
И почему вы не отвечаете за то, что будет при их росте? Вроде обычно интересуются что у клиента будет в ближайшей перспективе.

P.S.: ну и удивительно, что вы решаете такую задачу без вменяемого мониторинга на стенде.
думаю 500 и есть, либо планируется скоро. При росте в > 500 пользователей, как я написал, мы после тестирования скажем им нужен-ли апгрейд т.к. это выходит за пределы подписанной спецификации. Такие ограничения есть всегда если есть требования к производительности
На стенде это еще не обкатано, и он сам-то еще не создан т.к. система не закончена. Все данные тут были с моей машины. Предметная область тут не играет особой роли

hVosttКак виртуалки позволяют протестировать различное железо из представленного на рынке?

хех, действительно, а какой год на улице ;) Виртуалки позволяют тестировать не разновидности железяк, а ресурсы выделяемые системе. Там задается процессорная мощность, рам, диски и все остальное. И скажу более того, как минимум несколько клиентов у нас именно так и хостят потом системы, никто давно уже не покупает сервера под систему с набором железяк из спецификации, ставится шина, на которой крутятся десятки или сотни виртуалок для всех систем компании, и каждой из которых на шине выделены необходимые ресурсы.

hVosttЕсли вы собираетесь обеспечить одновременную работу 500 юзеров, то пик запросов у вас будет гораздо выше, чем 500. Но наверное вы и сами в курсе. Просто пишите странные и непонятные вещи :)

не должно быть сильно выше, и вообще думаю ситуация, которую симулирует стресс тест, в реальной работе вряд-ли вообще произойдет. При создании 500 запросов например фиддлером, никаких 3 секунд нет, там где-то значительно меньше секунды было т.к. фиддлер посылает их последовательно, хоть и очень быстро, но IIS успевает обработать запросы.

hVosttТ.е. не позволяют вам работать в потолок ресурсов?

в потолок ресурсов при одиночном сервере, который сам производит обработку, а не отсылает ее по сети в другое место. И не в "потолок" даже, а просто переключение контекста просто становится неэффективным

skyANAВсего 500? Тогда Вы страдаете фигней.
У нас более восьми миллионов. И они далеко не часто создают ту нагрузку, что Вы тестируете.

Вы возьмите в руки калькулятор и посчитайте сколько должно быть пользователей, чтобы обеспечить постоянную рабочую нагрузку хотяб 10 запросов в секунду.
8 миллионов одновременно? И как вы производили стресс тестирование? Скажем если условно все 8 миллионов нажмут одну и ту-же кнопку?

stenford- При тестировании, если время отклика слишком большое, то в машинном конфиге надо увеличить количество одновременно выполняемых потоков, но только при условии, что эти потоки занимаются асинхронными вызовами и реально не нагружают систему. На самом деле это 99% всех вебсервисов т.к. они все работают с базами данных. Если-же сервис занимается обработкой чего-то у себя в памяти, то лучше ничего не трогать

так, тут будет следующая поправка:

В IIS7 по умолчанию maxConcurrentRequestsPerCPU="5000", что фактически делает количество запросов (не потоков) обрабатываемых одновременно очень большим. Т.е. если вебсервер вообще не имеет особой логики и все асинхронно процессится на сервере БД, то улучшить пропускную способность IIS конфигурационными настройками по-сути нельзя (если запросов < 5000) т.к. сервер реально не нагружен даже при тысячах запросов т.к. они реально ничего не делают, а просто ждут. В IIS7 регулировать количество именно потоков напрямую невозможно.
https://blogs.msdn.microsoft.com/tmarq/2007/07/20/asp-net-thread-usage-on-iis-7-5-iis-7-0-and-iis-6-0/

Однако, если метод не 100% асинхронный (идут какие-то расчеты после получения данных из БД, логирование итп), то вот тут-то и вступают в игру параметры настройки CLR пула maxWorkerThreads, minWorkerThreads, maxIoThreads, minIoThreads из машинного конфига. Эти настройки помогут в ситуации, когда происходит резкое "взрывное" увеличение "блокирующих" запросов (т.е. не 100% асинхронных), прямо как у меня со стрессовым тестированием. Т.к. CLR пул по умолчанию увеличивает количество потоков очень медленно, эти настройки помогут справится с такой нагрузкой, но ценой памяти сервера. Вообще хороший вопрос стоит-ли их менять на продакшене, т.к. стрессовое тестирование тут довольно искуственный пример нагрузки, а держать увеличенное число поток в памяти отразится на работе сервера в обычном режиме

В общем не надо получается путать реквесты и потоки, их настройка изменилась в IIS7, до этого регулировались именно "потоки", а сейчас они абстрагировались в "реквесты", что вносит эту путаницу.