Связь и производительность в домене приложений
Я размещаю службу WCF, где требования состоят в том, чтобы вызывался объект того типа, на который служба WCF не ссылается напрямую, и на нем выполнялись некоторые (общие) методы. Итак, тип создается с помощью отражения и AssemblyResolve: это нормально.
но потом я подумал - что мы ожидаем, может быть, 50–100 таких сборок / типов, особенно когда мы управляем их версиями. по-видимому, это должно привести к раздуванию (все еще в теории, а не на практике) памяти и производительности приложения узла службы из-за того, что все эти сборки упоминаются в mem.
поэтому мы должны выгрузить: но единственный способ сделать это - через appdomain. предполагается, что каждая сборка каким-то образом будет запускаться в собственном домене приложения, а служба WCF на самом деле просто передает сообщения в соответствующий домен приложения. Если appdomain не используется в течение some_period_of_time, мы просто выгружаем appdomain.
я, вероятно, получу пометку за это, но некоторые рекомендации будут полезны:
- это безумная идея?
- должна ли процесс должен нормально работать с ~ 100 сборками в памяти?
- связь с доменами приложений, вероятно, будет иметь некоторую стоимость (через удаленное взаимодействие / именованные каналы): разве это дисквалифицирует идею?
- создание домена приложения для обслуживания одного типа .dll потребует много доменов приложений, это задерживается?
У меня нет опыта в этой области. Меня беспокоит размер и производительность приложения, если я не сделаю что-то подобное. однако с идеей домена приложения это в основном звучит как чрезмерная инженерия. требование разместить этот неизвестный .dll не является чем-то, что я могу изменить.
Думаю, мой общий вопрос:
эта идея настолько идиотична, как она звучит, и какие плюсы и минусы с ней связаны?