Блог

Я размещаю службу WCF, где требования заключаются в том, чтобы вызывался объект типа, на который служба WCF не ссылается напрямую, и на нем выполнялись некоторые (распространенные) методы. Тип создается с помощью отражения и AssemblyResolve: это нормально.

Затем я задумался — мы ожидаем, что, возможно, поступит 50-100 таких сборок / типов, особенно когда мы устанавливаем их версии. Предположительно, это должно привести к увеличению объема памяти и производительности приложения service host (все еще в теории, а не на практике) из-за того, что на все эти сборки ссылаются в mem.

В результате мы должны выгрузить — но единственный способ сделать это — через appdomain. Предполагается, что каждая сборка каким-то образом будет выполняться в своем собственном appdomain, а служба WCF на самом деле просто передает сообщения в соответствующий appdomain. Если appdomain не используется в течение some_period_of_time, то мы просто выгружаем appdomain.

Некоторые рекомендации были бы полезны по:

1. это безумная идея?
2. должен ли процесс нормально выполняться с ~ 100 сборками в памяти?
3. связь с appdomains, предположительно, обойдется в некоторую стоимость (через удаленные / именованные каналы): дисквалифицирует ли это идею?
4. создание appdomain для обслуживания одного типа .dll потребовало бы многих appdomain; это плохая идея?

У меня нет опыта в этой области. Меня беспокоит размер и производительность приложения, если я не сделаю что-то подобное. Однако, с идеей домена приложения, это в основном звучит как массовое перепроектирование. Требование для размещения этого неизвестно.библиотеки DLL — это не то, что я могу изменить.

Действительно ли эта идея так плоха, как кажется, и какие плюсы и минусы с ней связаны?

должен ли процесс нормально выполняться с ~ 100 сборками в памяти?

Вам придется попробовать (создать макет несложно), но вы застряли только с кодом. Таким образом, при 1 МБ за единицу вы бы использовали 100 МБ освобождаемой памяти, я не ожидаю проблем.

При условии, что ваши экземпляры будут выпущены и собраны.

Если у вас есть доступная память и вы хотите повысить производительность, вы можете либо подождать, пока не будет выполнен первый вызов, и сборки будут загружаться медленно (последующие вызовы будут быстрее), либо, если вы не хотите, чтобы выполнялись какие-либо медленные вызовы, вы можете быстро загрузить сборки при запуске службы. Я не вижу причин загружать / выгружать сборки при каждом вызове, когда память дешевая. Если вы заметили проблему с производительностью, я бы посоветовал подумать о выгрузке сборок, когда они не используются.

По сути, это то, что делают пулы приложений IIS и рабочие процессы. Возможно, это не безумие, но здесь есть много возможностей для реализации, которые могут привести к счастливым или несчастливым результатам.