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, до этого регулировались именно "потоки", а сейчас они абстрагировались в "реквесты", что вносит эту путаницу.

hVosttКоторое не имеет никакого отношения к реальности.
раз уж существуют стресс-тесты, значит к реальности это какое-то отношение имеет

skyANAВсего 8 657 139 активных зарегистрированных пользователей.
То будет downtime :) Но это фантастика.

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

skyANAstenford,

Вы только никому не рассказывайте, как потратили время и деньги на это Ваше стресс-тестирования, а потом оказалось, что в пиках у заказчика 5-10 запросов в секунду :)
никому кроме заказчика, уговорили. Если вы никогда не сталкивались с требованиями к пиковым нагрузкам, то зачем флудить? Мир не ограничивается одними соцсетями с картинками.
Юзеры может и не нажмут одну и ту-же кнопку, а вот системы могут выдать спайк запросов в короткий промежуток времени, и обьясняться потом почему лег сервер будет тот, кто говорил о ненужности стресс-тестов ;)

hVosttДа нет никакого стресс-тестирования, очередной выдумщик и фантазёр.
Или компания настолько тупая, чтобы нанять полного профана, или в компании это настолько не приоритетное направление, что даже если бы этим занималась обезьяна, всем было бы пофигу.
меня очень сложно обидеть, так что не старайся. Обычно, когда вместо аргументов и каких-то фактов идут оскорбления, то сразу четко видно человека с сильным комплексом неполноценности. Ты, претендуя на авторитета на данном форуме, даже и понятия не имел почему IIS затыкается на стресс-тесте, и не знал как это дело фиксить, и какие у этих фиксов плюсы и минусы. То, что с реальными задачами по производительности ты никогда не имел дело вполне очевидно. Но гонора зато в тебе много, да

handmadeFromRu хотите тз просто сделать ок добавьте балансировщик и 2-3 инстантс и все готово. можно на одно к примеру на чтение кеш чтоб уменьшить 50мс до 1-2 доступа из кеша
все-ж уже выяснилось, для того, что-бы "сделать тз" в конкретно моем случае достаточно увеличить число поток CLR. Не потребуется ни лоад балансера, ни каких-то других приседаний. Нужно-ли это в реальном продакшене данной системы - вопрос открытый, да, скорее всего не надо, но это пусть сам клиент решает. А вот для других систем подобные настройки вполне будут нужны и в продакшене, где спайки активности вешь регулярная, и вызваны они не столько юзерами, сколько активностью других систем.

skyANAДа я прекрасно понимаю, что у Вас требования. Но вот честно, откуда Вы взяли, что в пиках будет достигаться 500 запросов в секунду?
Ведь простая арифметика говорит, что это 30000 запросов в минуту. Вот объясните мне, себе и заказчику, как 500 пользователей могут её создать?

вот не в курсе вы, что такое внезапные пики активности, нету их видимо в соц сетях. А вот я такие системы видел, и не одну. Что-бы получить 500 запросов в полсекунды, не надо десятки тысяч запросов в минуту. Надо 500 запросов в полсекунды и ничего более, компрехэнд? И если система ляжет, то половина из этих запросов выдет за пределы лимита, все приехали. Никого не волнует, что остальные минуты система не получает столько запросов и справляется с нагрузкой. Волнует то, что пара сотен запросов в те полсекунды теперь за лимитом, и кто-то за это будет отвечать. Возможно тяжело понять, если не сталкивался с этим, я согласен

skyANAЧто за системы Вы видели, если не секрет, можете кокнретные примеры привести?
А то с одной стороны у Вас всего 500 пользователей, и предметную область Вы не раскрываете, потому как не важно это.
А с другой какие-то финансовые транзакции, системы с 1000 запросов в секунду в пиках.

Выглядит так, будто Вы понимаете, что у заказчика сайт взлетит и на табурете, но хотите помечтать о чём-то большом :)

как я уже говорил, в конкретно этом случае я согласен, что стресс тест тут довольно искуственнен, и вряд-ли будет хорошей идеей тьюнить потоки CLR пула на продакшене. Но это, как я уже тоже говорил, не отменяет того факта, что системы где отклик будет критичен существуют, и мне важно было понять что-же тут происходит.
Конкретные примеры легко, практически все финансовые системы с которыми я работал являлись критичными к времени отклика. Мне не надо про них мечтать, я с ними не один год работал, и провел массу своего рабочего времени занимаясь их перформанс тьюнингом.
Самый легкодоступный пример пожалуй именно с финансовыми транзакциями. Вот есть у тебя кредитка, которой ты платишь где-то в интернете. Когда ты нажал кнопку Оплатить, эти данные отправились в твой банк-провайдер для авторизации. Банк не просто проверил твой баланс и отправил ответ, он еще много чего с этой транзакцией сделал. Например проверил на мошенничество, на случай если хакер украл номер твоей кредитки и пытается ей заплатить от твоего имени. Эта проверка не пара хранимых процедур в базе перед инсертом. Это - полноценная система, которая живет на своей виртуалке, имеет свою базу и прочее. Она будет давать простой ответ - насколько транзакция подозрительная на основании ряда правил и политик. Но есть условие - ответ должен быть получен в течении 2-4 секунд, если ответ не получен в течении этого времени - результат проверки уже не будет никого интересовать. Никто этой системе не даст думать 10 секунд пока IIS тупит с потоками. Шина, в которую встроена эта система просто пойдет дальше и в зависимости от бизнес правил одобрит транзакцию или отклонит. В случае если одобрит, а транзакция была от хакера - банк с определенной вероятностью эти деньги потеряет. В случае сотни транзакций по штуке баксов - потеря будет 100 тысяч долларов. У меня ломали кредитку несколько лет назад - попытались снять 6 тысяч баксов. К счастью она была отклонена. И это я еще не говорю про политики той-же Мастеркард например, и что она делает с нерадивыми провайдерами