AppDomain связь и производительность

Question

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

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

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

Я, вероятно, получу оценку за это, но некоторые советы будут полезны:

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

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

Полагаю, мой общий вопрос:

Является ли эта идея настолько идиотской, насколько это звучит, и с чем связаны "за" и "против"?

Answer 1

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

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

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

Answer 2

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

Answer 3

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