Как заставить мое приложение жить дольше?

Question

Вот ситуация, в которой мы находимся.

Мы распространяем наши сборки (исключительно DLL) среди наших клиентов (у нас нет контроля над их средой).

Они звонят нам, передавая список идентификаторов товара, и мы ищем в нашей огромной базе данных и возвращаем товары с самой высокой ценой.Поскольку у нас есть SLA (30 миллисекунд), мы кэшируем наши элементы в кэш-памяти (используя Microsoft MemoryCache ). Мы кэшируем около миллиона элементов.

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

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

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

Мы используем AppFabric в качестве распределенного кэша, но единственный способ достичь SLA - использовать кэш-память.

Любая помощь будет принята с благодарностью.Спасибо

Answer 1

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

Одним из вариантов может быть - хотя и довольно грязный - реализовать какой-то «постоянный MemoryCache» ... для достижения производительности вы можете / могли бы использовать ConcurrentDictionary, сохраняемый в MemoryMappedFile ...

Другим вариантом будет использование локальной базы данных - может быть даже Sqlite и реализация для кэширования интерфейса в памяти, так что все операции записи / обновления / удаления являются «сквозными», а чтения - чистым доступом к ОЗУ. .

Другим вариантом может быть включение EXE (как, например, встроенного ресурса) и запуск его из библиотеки DLL, если она не запущена ... EXE предоставляет MemoryCache, связь может быть через IPC (например, разделяемая память ...). Поскольку EXE - это отдельный процесс, он останется в живых даже после выгрузки вашего домена приложений ... проблема заключается в том, нравится ли клиенту и / или разрешению разрешено клиенту ...

Мне действительно нравится подход Windows Service, хотя я согласен, что это может привести к путанице при развертывании ...

Answer 2

Основная проблема заключается в том, что у вас нет контроля над Хостом во время выполнения - именно это контролирует продолжительность жизни (и, следовательно, кеш).

Я бы исследовал создание какого-то рода(облегченный?) хост - может быть .exe или служба.

Большая часть ваших DLL будет зависать от нового хоста, но вы все равно можете развернуть «фасадную» DLL, которая в свою очередь называется вашей главнойрешение (привязано к вашему хосту).Да, внешние клиенты могли бы вызывать ваш новый хост напрямую, но это означало бы изменение / переконфигурирование тех внешних вызывающих абонентов, когда сохранение исходной библиотеки DLL / API на месте изолировало бы внешних вызывающих абонентов от ваших внутренних изменений.

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

Производительность

Межпроцессное взаимодействие обходится дороже, чем удержание его внутри процесса - я не уверен, как изменение подхода повлияет на вашу производительность и способностичтобы достичь SLA.

В частности, запуск нового экземпляра хоста приведет к снижению производительности.