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Т.е. не позволяют вам работать в потолок ресурсов?

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