Есть система из следующих составляющих:
— веб-сервис, написанный без использования .net и сам по себе работающий более-менее стабильно.
— некий хендлер, сделанный довольно хитро: .net-based web server extension на верхнем уровне, которое функционально ничего не делает, а только вызывает внешний mixed dll, т.е. managed C++ вместе с обычными плюсами.
— Dll этот, в свою очередь, пользуется внешним .net assembly для своих целей (для чего он, собственно, и был переделан в managed, до этого он был обычным dll), и в конечном счете вызывает вышеупомянутый веб-сервис тупо через сокет.
Хендлер функционально призван выполнять процедуру аутентикации/авторизации/логгинга и тому подобных общих задач для всех запросов, поступающих к веб-сервисам. Попутно он занимается и диспетчеризацией запросов, отправляя их куда надо. Все это работает, и даже относительно стабильно.
Забавность ситуации заключается в том, что в случае, когда целевой веб-сервис находится на том же компе, что и сам хендлер, то производитльность всей этой системы падает катастрофически. Если, скажем, хендлер принимает запрос и диспетчеризует его сервису на другой сервер, то вся бадяга занимает порядка 4...6 секунд в пиковом случае (в основном работа веб-сервиса), а если сервис крутится там же, где и хендлер, то есть хендлер открывает сокет на localhost, то это уже тянется 13 сек. Полный абзац наступает, если эта система крутится под VMWare — тогда запрос обрабатывается больше 2-х минут. Затык в коммуникации между веб-сервисом и хендлером.
При этом в таск-манагере на сервере (W'2000, IIS 5.0, .NET-FW 1.1) видно, что проц нехило загружен процессом aspnet_wp.exe (хотя, возможно, это тут ни при чем).
В общем, буду благодарен, если кто-нибудь из гуру сможет что-то по этому поводу заметить.
