У нас была похожая проблема, и я не знаю, поможет ли вам наш опыт. К счастью, это произошло в то время, когда мы впервые исследовали сервис-ориентированную архитектуру, поэтому нас очень интересовало, как использование веб-сервисов влияет на производительность по сравнению с другими методами получения данных.
Я не говорю, что наши результаты будут вам полезны, но, возможно, методология .
Мы фактически провели два полных 8-часовых дня, ничего не делая, кроме тестирования различных сценариев подключения. Нам было особенно интересно узнать о дополнительной пропускной способности, связанной с получением данных через XML, в отличие от двоичных данных. Мы полностью ожидали снижения производительности просто из-за получения данных XML, которые, как мы предполагали, будут иметь больше байтов в сети.
Я не буду вдаваться в результаты, поскольку это был сам по себе 10-страничный документ, но мы ДЕЙСТВИТЕЛЬНО обнаружили интересную задержку, которая произошла, когда мы получали данные из веб-службы, написанной на языке .Net, который осуществлял доступ к данным. на iSeries (AS / 400, System i или любой другой новый термин в эти дни). Как вы и описали, первый вызов для получения данных занял некоторое время, но последующие вызовы были быстрее.
Оказалось, что тип соединения, которое мы использовали (ODBC предоставлен Microsoft), был виновником в нашем случае при просмотре сетевых пакетов.
Мы измерили сетевые пакеты между клиентом и веб-службой, а также между веб-службой и iSeries (хранилищем данных) и обнаружили, что происходит задержка, потому что веб-служба впервые установила соединение с iSeries. несколько ненужных пакетов были отправлены туда и обратно.
Короче говоря, сторона Windows отправит запрос на подключение, подождет несколько миллисекунд, а затем отправит еще один. Между тем, iSeries реагировал медленно, поэтому при первой попытке подключения было четыре вызова для соединения со стороны Windows на сторону iSeries, а затем четыре ответа от iSeries, которые были проигнорированы стороной Windows (поскольку сторона соединения Windows отказалась). Наконец, после 4-6 попыток соединение было установлено. После этого соединение должно было быть объединено, потому что последующие соединения в течение короткого времени были быстрыми. Однако по прошествии времени (мы так и не определили, сколько времени понадобилось для этого), медленное начальное соединение вырвалось наружу.
Итак, после всего этого долгого изречения @Aggelos Mpimpoudis предложил профилировать ваш собственный код. Мое предложение было бы найти кого-то, кто имеет опыт и инструменты для анализа сетевых пакетов и анализа всего процесса. Вы можете отследить виновника таким образом.
Кстати, наша проблема стала лучше после того, как мы переключились на подключение к iSeries с использованием Ibm.Data.Db2.iseries вместо драйвера System.Data.Odbc И после того, как у нас было достаточно веб-сервисов, записавших такую частоту обращений к iSeries этого было достаточно, чтобы пул соединения оставался открытым.