Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / ASP.NET Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2 3 4 5   вперед  Ctrl      все
 Оптимизация отклика от IIS  [new]
stenford
Member

Откуда: урал
Сообщений: 2194
Есть метод Web API, который запускается нагрузочным софтом 500 раз одновременно, и согласно внутреннему логу выполняется в среднем 200 мс, в то-же время нагрузочный софт показывает среднее время отклика 2.5 секунды. Т.е. это где-то в IIS что-то не успевает. Как это что-то найти и что можно подкрутить что-б уменьшить время отклика? С увеличением количества одновременных запросов время отклика растет, 1000 запросов в среднем потребляет уже 4.5 секунды
6 сен 17, 07:49    [20774300]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация отклика от IIS  [new]
hVostt
Member

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


Переписать метод WebAPI и сделать его асинхронным. Проблема с ограниченным количеством потоков в пуле уже не раз обсуждалась и мусолилась.
6 сен 17, 08:48    [20774370]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация отклика от IIS  [new]
stenford
Member

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


не оказывает влияния, и даже (правда в пределах погрешности) замедляет среднее арифметическое отклика. Возможно потому, что сам по себе запрос занимает порядка 20-30 миллисекунд (не 200 как сначала написал) и асинхронное исполнение не дает каких-то преимуществ
6 сен 17, 09:31    [20774449]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация отклика от IIS  [new]
handmadeFromRu
Member

Откуда: родина Ленина!
Сообщений: 1605
stenford,

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

пс. включите внутрений лог ииса, может подскажет. insight врядли покажет к примеру так как вы говорите что у вас там 20мс
6 сен 17, 09:43    [20774469]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация отклика от IIS  [new]
stenford
Member

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

пс. включите внутрений лог ииса, может подскажет. insight врядли покажет к примеру так как вы говорите что у вас там 20мс

инфа оттуда, что заменил в EF метод на асинхронный и запустил через нагрузочый софт, который мне и показал статистику. Я так понимаю асинхронность надо пихать не в каждый метод, а там, где запросы медленно выполняются. 30 миллисекунд судя по всему достаточно быстро что-бы никаких выгод не было, и даже возможно наоборот идет просадка из-за записка асинхронного потока
6 сен 17, 09:48    [20774480]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация отклика от IIS  [new]
hVostt
Member

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


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

stenford
Я так понимаю асинхронность надо пихать не в каждый метод, а там, где запросы медленно выполняются.


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

Крайне редко «медленно» связанно именно с вычислениями. Что ты там делаешь, факториалы рассчитываешь что ли?

stenford
даже возможно наоборот идет просадка из-за записка асинхронного потока


Просадка, значит? Ну это конечно да, просадка дело такое..
6 сен 17, 09:59    [20774511]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация отклика от IIS  [new]
hVostt
Member

Откуда:
Сообщений: 11641
stenford,

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

Статья от бородатого 2012 года.
6 сен 17, 10:01    [20774518]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация отклика от IIS  [new]
oaken
Member

Откуда: Kiev
Сообщений: 472
hVostt
https://habrahabr.ru/post/142372/

Статья от бородатого 2012 года.
Статья, мягко говоря, "так себе".
6 сен 17, 10:21    [20774574]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация отклика от IIS  [new]
hVostt
Member

Откуда:
Сообщений: 11641
oaken
hVostt
https://habrahabr.ru/post/142372/

Статья от бородатого 2012 года.
Статья, мягко говоря, "так себе".


Нормальная статья, на хабре придолбались к квалификации автора.
6 сен 17, 10:36    [20774640]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация отклика от IIS  [new]
handmadeFromRu
Member

Откуда: родина Ленина!
Сообщений: 1605
stenford
инфа оттуда, что заменил в EF метод на асинхронный и запустил через нагрузочый софт, который мне и показал статистику. Я так понимаю асинхронность надо пихать не в каждый метод, а там, где запросы медленно выполняются. 30 миллисекунд судя по всему достаточно быстро что-бы никаких выгод не было, и даже возможно наоборот идет просадка из-за записка асинхронного потока


про асинхроност ну чет аргумет слабенький с таким то тестом, я уже писал асинхроность не панацея и надо понимать зачем.
ну 30мс эт 1 метод в бд или что? у тебя есть время ответа полное страницы со всеми запросами? чем мерил то? у тебя там какой нить Glimpse или MiniProfiler стоит?
6 сен 17, 10:41    [20774666]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация отклика от IIS  [new]
stenford
Member

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

ок, асинхронное или нет не так и важно. Почему IIS из 40 миллисекунд делает 2 секунды? Чем он там занимается? Это при асинхронном запуске если что. Как можно это дело оптимизировать? Или только лоад балансер с несколькими серверами тут поможет?
6 сен 17, 11:17    [20774870]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация отклика от IIS  [new]
stenford
Member

Откуда: урал
Сообщений: 2194
hVostt
https://habrahabr.ru/post/142372/

Статья от бородатого 2012 года.

thanks, прочитаю
6 сен 17, 11:17    [20774873]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация отклика от IIS  [new]
stenford
Member

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


30 мс - это целиком весь процессинг web api, от момента первого message handler'a, до его-же но уже на выходе, я там лог привинтил который меряет затраченное время. Т.е. сам непосредственно запрос к БД еще меньше будет.
Нагрузочный софт это jmeter. Но похожих результатов можно и в фиддлере добится, если ты скажем запустишь такой метод:
  [Route("{id}")]
        public async Task<Book> Get(int id)        
        {            
            System.Threading.Thread.Sleep(20);
            //await Task.Delay(20);

            return new Book() { Name = "xxx"};
        }


раз 400, то разницы между блокирующим и асинхронным результатом в проиводительности почти не будет. Вот где-то с 50 миллисекунд она начинает появлятся, и скажем если поставить 300, то будет уже совсем чувствительно
6 сен 17, 11:28    [20774933]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация отклика от IIS  [new]
skyANA
Member

Откуда: Зеленоград
Сообщений: 22781
stenford,

воспользуйтесь Performance Monitor-ом, возможно запросы встают в очередь
6 сен 17, 11:57    [20775072]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация отклика от IIS  [new]
handmadeFromRu
Member

Откуда: родина Ленина!
Сообщений: 1605
stenford,

ок понял. а пробовал config.EnableSystemDiagnosticsTracing(); и логи смотреть?
6 сен 17, 12:17    [20775164]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация отклика от IIS  [new]
handmadeFromRu
Member

Откуда: родина Ленина!
Сообщений: 1605
stenford,

https://robinsedlaczek.com/2014/05/20/improve-server-performance-with-asynchronous-webapi/ эт по поводу асинхронсти статья подробненькая
6 сен 17, 12:31    [20775205]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация отклика от IIS  [new]
hVostt
Member

Откуда:
Сообщений: 11641
handmadeFromRu
stenford,

https://robinsedlaczek.com/2014/05/20/improve-server-performance-with-asynchronous-webapi/ эт по поводу асинхронсти статья подробненькая


Эта статья лучше, чем я привёл, но суть та же
6 сен 17, 13:10    [20775422]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация отклика от IIS  [new]
handmadeFromRu
Member

Откуда: родина Ленина!
Сообщений: 1605
hVostt,

да но если у него очередь забилась но поможет. надо увеличивать тридпул (дешевое решение вертикальное) или размазывать по сервакам. я вот не нашел инфы как с 4.0 считается кол-во потоков в пуле на процесс. раньше было 1 ядро процессора = 20-25 потоков. по умолчанию, конечно можно увеличить цифру ценой памяти 1 поток 1 мб памяти.
6 сен 17, 13:27    [20775483]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация отклика от IIS  [new]
hVostt
Member

Откуда:
Сообщений: 11641
handmadeFromRu
да но если у него очередь забилась но поможет. надо увеличивать тридпул (дешевое решение вертикальное) или размазывать по сервакам. я вот не нашел инфы как с 4.0 считается кол-во потоков в пуле на процесс. раньше было 1 ядро процессора = 20-25 потоков. по умолчанию, конечно можно увеличить цифру ценой памяти 1 поток 1 мб памяти.


Можно и размазать по сервакам. Но это ни разу не отменяет, что по умолчанию при работе с I/O операциями надо делать асинхронные экшены. Это сильно оттянет необходимость масштабироваться и тюнить количество потоков. Так-то их лучше и не трогать вовсе.
6 сен 17, 14:24    [20775676]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация отклика от IIS  [new]
stenford
Member

Откуда: урал
Сообщений: 2194
Пока читал тут ссылки по поводу потоков, нашел одно очень полезное замечание

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 потоков запрашивается один для генерации ответа.
Отсюда следует, что сам я недолжен создавать никакие потоки т.к. эффект будет аналогичен блокирующему методу. Смысл асинхронных методов исключительно в том, что для ожидания ответа от другого сервера поток не нужен. Если для обработки метода создается поток на этой-же машине - то толку от такого асинхронного метода тоже нет. Все верно?
7 сен 17, 06:57    [20777064]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация отклика от IIS  [new]
Алексей К
Member

Откуда: Новосибирск
Сообщений: 13535
stenford
По сути оно означает, что утверждение о необходимости асинхронного выполнения в asp.net не всегда верно.
Асинхронное выполнение в Asp.Net это не необходимость, это способ оптимизации, позволяющий повысить производительность при определённых условиях.
7 сен 17, 07:40    [20777111]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация отклика от IIS  [new]
hVostt
Member

Откуда:
Сообщений: 11641
stenford
По сути оно означает, что утверждение о необходимости асинхронного выполнения в asp.net не всегда верно.


Где утверждается подобное? Чёт я такого не видел.

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


Речь идёт только о I/O bound операциях. Для сложных вычислительных задач асинхронность не нужна. До тех пор, пока она не будет вынесена в отдельный сервис.


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


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

Короче хватит выдумывать. Есть простой правило: CPU bound синхронно, I/O bound асинхронно. И ничего не надо придумывать и фантазировать. Точка.
7 сен 17, 07:51    [20777125]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация отклика от IIS  [new]
hVostt
Member

Откуда:
Сообщений: 11641
stenford
Отсюда следует, что сам я недолжен создавать никакие потоки т.к. эффект будет аналогичен блокирующему методу. Смысл асинхронных методов исключительно в том, что для ожидания ответа от другого сервера поток не нужен. Если для обработки метода создается поток на этой-же машине - то толку от такого асинхронного метода тоже нет. Все верно?


Не верно ни разу.
7 сен 17, 07:51    [20777126]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация отклика от IIS  [new]
stenford
Member

Откуда: урал
Сообщений: 2194
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 потоков и не морочило нам голову.
7 сен 17, 08:09    [20777140]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация отклика от IIS  [new]
stenford
Member

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

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

50 мс исходя из моих тестов. Вопрос не в конкретно 50 мс, а в том, что на краткосрочную операцию переключение контекста перевесит выгоду от неиспользования потока
7 сен 17, 08:11    [20777143]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3 4 5   вперед  Ctrl      все
Все форумы / ASP.NET Ответить