Как продлить жизнь моему домену приложения?

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

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

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

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

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

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

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

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


.net architecture c# appfabric
person kepung    schedule 26.07.2011    source источник
comment
Вы имеете в виду клиентское приложение вашего клиента или службу поиска?   -  person Kev    schedule 27.07.2011
comment
Для клиентского приложения моего клиента.   -  person kepung    schedule 27.07.2011
comment
Основная проблема заключается в том, что у вас нет контроля над хостом/клиентом, что определяет продолжительность жизни. В принципе - можете/разрешите ввести какой-нибудь прокси-клиент/хост?   -  person Adrian K    schedule 27.07.2011
comment
Возможно внедрение клиентского прокси.   -  person kepung    schedule 27.07.2011
comment
затем посмотрите на удар - прокси-сервер может быть даже в файле DLL в качестве встроенного ресурса, поэтому для развертывания не потребуется ничего особенного.   -  person Yahia    schedule 27.07.2011
comment
@Yahia - Вы правы, наличие клиента помогло бы. Просто этот ответ может быть быстрее, используя кеш памяти.   -  person kepung    schedule 27.07.2011
comment
Спасибо за все ваши ответы. У меня есть идея, что делать дальше.   -  person kepung    schedule 27.07.2011

Ответы (2)


arrow_upward
2
arrow_downward

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

Одним из вариантов может быть - хотя тоже грязный - реализовать какой-то "сохраняющийся кэш памяти"... для достижения производительности вы могли бы/использовали бы ConcurrentDictionary, сохраняемый в MemoryMappedFile...

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

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

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

person Yahia    schedule 27.07.2011

arrow_upward
1
arrow_downward

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

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

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

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

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

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

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

person Adrian K    schedule 27.07.2011