Стратегии кэширования для приложений конечных пользователей Windows?

Question

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

Однако не всегда понятно, как управлять этими кэшами. В настоящее время некоторые кэши сбрасываются всякий раз, когда среда выполнения простаивает, тогда как другие кэши никогда не сбрасываются или сбрасываются только при достижении некоторого настраиваемого, но произвольного предела. Мы, очевидно, хотели бы хранить как можно больше данных в памяти, но я не уверен, как сделать это так, чтобы это хорошо сочеталось с Citrix, что очень важно для наших клиентов.

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

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

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

TL; DR : у кого-нибудь есть хорошие идеи по управлению кэшами в памяти под Windows?

Answer 1

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

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

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

И последнее, конечно, иногда приходится искать компромисс между производительностью и использованием памяти. Здесь снова, если экземпляры могут взаимодействовать каким-либо образом, они могут регулировать свой максимальный размер кэша в зависимости от количества экземпляров и объема памяти, доступного на машине, на которой они работают. Таким образом, если запускается больше экземпляров, все они немного уступают, чтобы приспособиться к новичку, без риска перегрузки памяти сервера.

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