Производительность самостоятельного размещения WCF

Я нахожусь в процессе написания приложения уровня предприятия, использующего службы WCF и NetTCP. Сначала я выбрал NetTCP из любопытства, но позже решил, что это лучший вариант для меня, поскольку у меня могут быть вызовы сервисов, которые требуют 5+ часов для возврата результатов из-за объема обработки данных.

То, как я в настоящее время создаю свои услуги, представляет собой многоэтапный процесс. У меня есть часть конфигурации (с использованием System.Configuration), в которой указаны некоторые элементы по умолчанию (номер порта, имя сервера для подключения клиентов, следует ли включать HTTP, а также NetTCP и т. д.), и в нем есть набор «сервисов». Это. Например, вот как выглядит базовый:

<serverConfiguration tcpListenerPortNumber="60000" httpGetEnabled="true" httpListenerPortNumber="6000" serverName="localhost" retryEnabled="true" retryInterval="5" maxRetryAttempts="3">
    <services>
        <add virtualDirectory="Service1" applicationName="Service1" assembly="SampleService" type="SampleService.Service1" />            
    </services>
</serverConfiguration>

По сути, здесь происходит то, что моя служба Windows запускается и просматривает все в коллекции ‹services/› и порождает поток для каждой службы, чтобы ускорить время запуска, и каждый поток содержит AppDomain, где служба действительно живет, поэтому, если служба имеет какой-либо вид по вине он не обрушивает систему.

«Проблема», с которой я сталкиваюсь, заключается в том, что в этом приложении размещено около 20 служб, и для запуска всех служб требуется 15-20 секунд. Я сделал части потоков и AppDomain, чтобы снизить его до этого значения (раньше это занимало больше минуты, так как каждый сервис открывался последовательно), но мне все еще кажется, что на самом деле это могло бы работать намного быстрее.

У кого-нибудь есть предложения? Google В Bing есть множество примеров для хостинга одной службы, но я не нашел много примеров для реальных приложений (к сожалению, «Hello World» просто не нравится конечным пользователям). Если вы в настоящее время размещаете несколько служб через службу Windows и NetTCP, как вы это делаете?


multithreading wcf appdomain windows-services nettcpbinding
person Scott Salyer    schedule 20.06.2009    source источник
comment
Нужно ли должно быть быстрее? Если он запускается только один раз в день, то это 20 секунд в день. Это не долго.   -  person John Saunders    schedule 21.06.2009
comment
В основном во время отладки он работает медленнее, так что это основная область, из которой я пытаюсь выжать производительность. Сами службы будут работать бесконечно долго (конечно, за исключением перезагрузки).   -  person Scott Salyer    schedule 22.06.2009

Ответы (2)


arrow_upward
1
arrow_downward

Наконец-то я понял это, и в конце концов это не имело ничего общего с WCF или моими частями конфигурации. Когда я создавал AppDomain, я украл код из другого нашего проекта, который был намного меньше по размеру, и обнаружил, что раздел, создающий AppDomains, использует опцию SingleDomain. Изменение его на MultiDomain привело к тому, что общая нагрузка увеличилась до> 4 секунд, а использование памяти упало до ~ 40 МБ с ~ 150 МБ.

Спасибо за помощь — по крайней мере, это заставило меня снова просмотреть код!

person Scott Salyer    schedule 25.06.2009

arrow_upward
0
arrow_downward

У меня есть три предложения:

Во-первых, если вызов может занять более 5 часов, я бы рассмотрел архитектуру в стиле очереди/обратного вызова.

Рассмотрите возможность разделения ваших служб на 20 служб Windows, где каждая служба работает в своей собственной службе Windows. Это добавляет сложности и увеличивает использование памяти, но отдельная служба может быть доступна быстрее.

Наконец, проверьте код, который находится в конструкторе службы, на наличие ненужного кода.

person Shiraz Bhaiji    schedule 20.06.2009
comment
20 служб на самом деле неосуществимо, особенно с точки зрения отладки. Мы все еще в разработке, и я предполагаю, что нам еще предстоит создать еще 10-20 сервисов. Сложность чего-то подобного может легко выйти за рамки графика с точки зрения обслуживания. - person Scott Salyer; 21.06.2009
comment
Почему это может быть проблемой обслуживания, если все сервисы были созданы на одной и той же платформе, использовали одну и ту же инфраструктуру, соглашения об именах и т. д. Я имею в виду ту же технологию ведения журналов, конфигурацию и т. д. 40 почти идентичных сервисов не должны быть сложнее поддерживать, чем один или два, которые не идентичны. - person John Saunders; 21.06.2009
comment
Что ж, многие сервисы используют друг друга (т. е. вызов одного может потребовать вызова других и т. д.), поэтому отладка, которая действительно будет болезненной по сравнению с одной конечной точкой, если вы хотите (не настоящая конечная точка, но я думаю, что вы поняли мое точка). Не говоря уже о том, что 40 служб Windows просто кажутся излишними, особенно если меняется основная часть, и мне приходится развертывать эти библиотеки DLL в каждом месте. Я мог бы использовать GAC для основного материала, но это все равно кажется излишним. - person Scott Salyer; 22.06.2009