Есть метод 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 мс, а в том, что на краткосрочную операцию переключение контекста перевесит выгоду от неиспользования потока