Есть приложение, которое во множестве потоков подключается в WebService'у и дергает метод. Если приложение запустить на сервере, где расположен сам IIS (и где все это добро компилировалось), то все отрабатывает нормально. Но стоит запустить на другом компе — одновременно работают только 2 потока, остальные ждут. Пробовал запускать несколько экземпляров приложений: все равно в каждом экземпляров работает ровно два потока. В чем причина?
Здравствуйте, ivs13, Вы писали:
I>Есть приложение, которое во множестве потоков подключается в WebService'у и дергает метод. Если приложение запустить на сервере, где расположен сам IIS (и где все это добро компилировалось), то все отрабатывает нормально. Но стоит запустить на другом компе — одновременно работают только 2 потока, остальные ждут. Пробовал запускать несколько экземпляров приложений: все равно в каждом экземпляров работает ровно два потока. В чем причина?
В ограничении на количество активных соединений к одному хосту.
См. http://msdn.microsoft.com/en-us/library/system.net.servicepointmanager.defaultconnectionlimit.aspx.
Его шевелить не рекомендую — лучше найти ServicePoint для своего веб-сервиса и настроить конкретно его:
и http://msdn.microsoft.com/en-us/library/system.net.servicepoint.connectionlimit.aspx
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Спасибо, вроде получилось. С ServicePoint как-то через раз получалось, сделал через ServicePointManager. Причем выставлять параметры, как оказалось, нужно обязательно в основном потоке программы, изменения в потоках, созданных непосредственно для работы, никакого эффекта не дали, хоть и делались до создания экземпляров вебсервиса. Теперь проявилась другая проблема: ограниченно количество одновременных подключений к вебсервису (опытным путем установил — 25 удаленно или 50 локально). Что нужно подкрутить в ASP.NET WebService, чтобы избавиться от ограничений?
Здравствуйте, ivs13, Вы писали:
I>Спасибо, вроде получилось. С ServicePoint как-то через раз получалось, сделал через ServicePointManager. Причем выставлять параметры, как оказалось, нужно обязательно в основном потоке программы, изменения в потоках, созданных непосредственно для работы, никакого эффекта не дали, хоть и делались до создания экземпляров вебсервиса. Теперь проявилась другая проблема: ограниченно количество одновременных подключений к вебсервису (опытным путем установил — 25 удаленно или 50 локально). Что нужно подкрутить в ASP.NET WebService, чтобы избавиться от ограничений?
Вы наступили на ограничение на пул потоков ASP.NET.
Корректировать его без веской причины не рекомендую. Зачем вам удерживать открытые соединения? Работа веб-сервиса — быстро-быстро обслужить и закрыть соединение. Всё равно работать одновременно может не больше потоков, чем ядер. Ну, часть времени обработчик, конечно же, спит. Поэтому ASP.NET выделяет 25 потоков на ядро, а не один.
Подкрутить в вебсервисе лучше его производительность
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Вебсервис используется как шлюз для доступа к базе данных, особой логикой не обладает, все зависит от того, как быстро БД, которая крутится на другом сервере, даст ответ. Т.е. речь идет не о реальной работе, а о простом ожидании, нагрузки никакой. Подскажите, куда ковырять с этим пулом, не получится — так и будет, хоть наковыряюсь
Здравствуйте, ivs13, Вы писали:
I>Вебсервис используется как шлюз для доступа к базе данных, особой логикой не обладает, все зависит от того, как быстро БД, которая крутится на другом сервере, даст ответ. Т.е. речь идет не о реальной работе, а о простом ожидании, нагрузки никакой. Подскажите, куда ковырять с этим пулом, не получится — так и будет, хоть наковыряюсь
Здравствуйте, ivs13, Вы писали:
I>Вебсервис используется как шлюз для доступа к базе данных, особой логикой не обладает, все зависит от того, как быстро БД, которая крутится на другом сервере, даст ответ. Т.е. речь идет не о реальной работе, а о простом ожидании, нагрузки никакой. Подскажите, куда ковырять с этим пулом, не получится — так и будет, хоть наковыряюсь
А какой смысл запскать для такого запроса отдельный поток, если он все равно будет ждать? Недостатки — очевидны (рсурсы на поток, соединение с базой данных), а вот достоинств как-то не видно.
Здравствуйте, Lloyd, Вы писали: L>А какой смысл запскать для такого запроса отдельный поток, если он все равно будет ждать? Недостатки — очевидны (рсурсы на поток, соединение с базой данных), а вот достоинств как-то не видно.
Не совсем понял... На веб-сервисе никаких потоков не запускается. У него всего одна функция, принимающая имя хранимой процедуры и список входных параметров, дергающая БД и возвращающая список выходных параметров. Все. Проблемы начинаются на тестовом клиенте, которым я попытался сэмулировать нагрузку на веб-сервис. Это и позволило выявить ограничение в 25 одновременных подключений к веб-сервису. Теперь вопрос: как заставить веб-сервис отрабатывать без ограничений, создавая столько подключений к БД, сколько нужно мне, сколько выдержит сервер, а не 25, указанные Микрософтом? А вот чтобы моей БД не стало плохо, я регулирую кол-во подключений к ней через параметры ConnectionString.
Здравствуйте, ivs13, Вы писали:
L>>А какой смысл запскать для такого запроса отдельный поток, если он все равно будет ждать? Недостатки — очевидны (рсурсы на поток, соединение с базой данных), а вот достоинств как-то не видно.
I>Не совсем понял... На веб-сервисе никаких потоков не запускается. У него всего одна функция, принимающая имя хранимой процедуры и список входных параметров, дергающая БД и возвращающая список выходных параметров. Все. Проблемы начинаются на тестовом клиенте, которым я попытался сэмулировать нагрузку на веб-сервис. Это и позволило выявить ограничение в 25 одновременных подключений к веб-сервису.
Вы неправильно поняли, что вам ответил Sinclair.
Количество соединений к веб-сервису не ограничено 25-ю. Просто все запросы ставятся в очередь на выполнение и будут обрабатываться тогда, когда освободится поток, который сможет их обработать. А кол-во потоков по умолчанию как раз 25.
I>Теперь вопрос: как заставить веб-сервис отрабатывать без ограничений, создавая столько подключений к БД, сколько нужно мне, сколько выдержит сервер, а не 25, указанные Микрософтом? А вот чтобы моей БД не стало плохо, я регулирую кол-во подключений к ней через параметры ConnectionString.
Если честно, я не понимаю, чего вы хотите добиться. Если у вас и так ограничено кол-во подклюний к базе, то увелиением числа потоков сверх 25-и вы добьетесь только дополнительного расхода памяти и только.
Здравствуйте, Lloyd, Вы писали:
I>>Вебсервис используется как шлюз для доступа к базе данных, особой логикой не обладает, все зависит от того, как быстро БД, которая крутится на другом сервере, даст ответ. Т.е. речь идет не о реальной работе, а о простом ожидании, нагрузки никакой. Подскажите, куда ковырять с этим пулом, не получится — так и будет, хоть наковыряюсь
L>А какой смысл запскать для такого запроса отдельный поток, если он все равно будет ждать? Недостатки — очевидны (рсурсы на поток, соединение с базой данных), а вот достоинств как-то не видно.
у меня похожая проблема: устраиваю стресс-тест для вебслужбы проксирующейь запросы к БД. время исполнения одного запроса от сотых долей до секунды. исходя из задачи на чем стоит сосредоточиться если количество клиентов в момент времени может быть > 1000? какие вообще есть рекомендации по разработке похожих служб?
Здравствуйте, Lloyd, Вы писали:
L>Если честно, я не понимаю, чего вы хотите добиться. Если у вас и так ограничено кол-во подклюний к базе, то увелиением числа потоков сверх 25-и вы добьетесь только дополнительного расхода памяти и только.
База данных позволяет создавать 1000 одновременных подключений (проверено текущим сервером приложений). А веб-сервер не пускает больше 25. Как сделать, чтобы веб-сервис позволял создавать 1000 одновременных подключений к БД? Надеюсь, теперь стало понятней.
Здравствуйте, ivs13, Вы писали:
I>База данных позволяет создавать 1000 одновременных подключений (проверено текущим сервером приложений). А веб-сервер не пускает больше 25. Как сделать, чтобы веб-сервис позволял создавать 1000 одновременных подключений к БД? Надеюсь, теперь стало понятней.
Здравствуйте, Lloyd, Вы писали:
L>Попробуйте параметр maxWorkerThreads элемента processModel. L>Но по-моему, вы зря это делаете, 1000 подключений — это минимум 1GB памяти.
Спасибо. Частично помогло. В документации написано "Значения этого атрибута находятся в диапазоне от 5 до 100". Презрев написанное, указал <processModel autoConfig="false" maxWorkerThreads="1000"/> в надежде получить вожделенную тысячу подключений. В результате опыт показал порядка 350 подключений (сожрав при этом 220Мб памяти). Уже больше, чем 25, но и не указанная тысяча. Что нужно подкручивать дальше?
Здравствуйте, ivs13, Вы писали:
I>Здравствуйте, Lloyd, Вы писали:
L>>Попробуйте параметр maxWorkerThreads элемента processModel. L>>Но по-моему, вы зря это делаете, 1000 подключений — это минимум 1GB памяти.
I>Спасибо. Частично помогло. В документации написано "Значения этого атрибута находятся в диапазоне от 5 до 100". Презрев написанное, указал <processModel autoConfig="false" maxWorkerThreads="1000"/> в надежде получить вожделенную тысячу подключений. В результате опыт показал порядка 350 подключений (сожрав при этом 220Мб памяти). Уже больше, чем 25, но и не указанная тысяча. Что нужно подкручивать дальше?
А смысл ? В реальной жизни тратится какое-то время на обработку запроса самим сервером. И скорее всего просто упирается в производительность. Если задача получить 1000 подключений к sql — поставь 10 серверов у каждого по 100 подключений в ферму
Здравствуйте, Volgaboatman, Вы писали:
V> И скорее всего просто упирается в производительность.
Это не так. Загруженность и до 20% не доходит. Смысл? Смысл простой: от COM-сервера перейти к WebService. Пока все это тестовые задачи, которые, тем не менее, уже выявили проблемы: от того, что рядом стоящий COM делает даже не напрягаясь, ASP.NET WebService становится в позу
Здравствуйте, ivs13, Вы писали:
I>Здравствуйте, Volgaboatman, Вы писали:
V>> И скорее всего просто упирается в производительность.
I>Это не так. Загруженность и до 20% не доходит. Смысл? Смысл простой: от COM-сервера перейти к WebService. Пока все это тестовые задачи, которые, тем не менее, уже выявили проблемы: от того, что рядом стоящий COM делает даже не напрягаясь, ASP.NET WebService становится в позу
