Кэширование ASP.NET с зависимостью от файла: статическая переменная против AspNet кеш против memcached

Question

TL; DR: что, вероятно, быстрее: доступ к статической локальной переменной, доступ к переменной, хранящейся в HttpRuntime.Cache, или доступ к переменной, хранящейся в memcached?

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

Все различные продвижение определены в файле XML на каждом веб-сервере.У нас есть 12 веб-серверов, обслуживающих один и тот же сайт с одним и тем же XML-файлом.Существует около 50 различных рекламных комбинаций в зависимости от страны / языка.Мы предполагаем, что у нас никогда не будет более 200 (если вообще когда-либо) рекламных акций (комбинаций).

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

Первоначально я написал код так, чтобы содержимое файла XML было проанализировано и затем сохранено в статическом члене класса.FileSystemWatcher отслеживал изменения в файле, и всякий раз, когда файл изменялся, XML-файл перезагружался / анализировался, и статический член обновлялся с новым содержимым.Выглядело как надежное и простое решение для поддержания словаря рекламных акций в памяти в актуальном состоянии с файлом XML.(Каждый сервер делает это независимо со своей локальной копией XML-файла; все XML-файлы одинаковы и изменяются одновременно.)

Другой разработчик, с которым я работал, занимал должность старшего и решил, что этоне было ничего хорошегоВместо этого мы должны хранить все рекламные акции на каждом сервере HttpContext.Current.Cache с зависимостью файла CacheDependency, которая автоматически отслеживает изменения файла, удаляя кэшированные рекламные акции при изменении файла.Хотя мне нравилось, что нам больше не приходилось использовать FileSystemWatcher, я немного волновался, что захват повышений из кэша volitile вместо статического члена класса будет менее производительным.

(Не забудьте прокомментировать этобеспокойство? Я уже отказался от попыток запретить переход на HttpRuntime.Cache.)

Позже, после того как мы начали использовать HttpRuntime.Cache, мы приняли memcached с Enyim в качестве интерфейса .NET для других бизнес-задач (например, поискРезультаты).Когда мы это сделали, этот старший разработчик решил, что мы должны использовать memcached вместо HttpRuntime (HttpContext) Cache для хранения рекламных акций.Представители высшего звена сказали «да, звучит хорошо» и дали ему выделенный сервер с memcached только для этих рекламных акций.Сейчас он внедряет изменения, чтобы использовать memcached вместо этого.

Я скептически отношусь к тому, что это хорошее решение.Вместо того, чтобы оставаться в процессе и получать эти рекламные данные с HttpRuntime.Cache, мы теперь открываем сокет для сетевого сервера memcached и передаем его значение на наш веб-сервер.

Это должно быть менее производительным, право?Даже если кеш мемкашируется.(У меня еще не было возможности скомпилировать какие-либо показатели производительности.)

Кроме того, ему придется разработать собственное решение для файловой зависимости по memcached, поскольку оно не предоставляет такой возможности.

Разве мой оригинальный дизайн не будет лучшим?Вам кажется, что это слишком высокий уровень подготовки?HttpRuntime.Cache кэширование или memcached кэширование даже необходимо?

Answer 1

Очень согласен с Андреем здесь. Несколько дополнений / отклонений:

1. Для небольшого количества редко меняющихся данных статические поля обеспечивают наилучшую производительность. Когда ваше кэширование происходит не на уровне пользовательского интерфейса, оно избегает зависимости от сборки System.Web (конечно, вы можете добиться этого и другими способами). Тем не менее, в общем случае ASP.NET Cache также будет хорошим выбором (особенно, если объем данных большой, кэшированные данные могут истечь, если есть нехватка памяти и т. Д.)

2. Как из-за скорости, так и из-за масштабируемости, кэширование вывода (включая кэширование в браузере и на низком уровне) было бы наилучшим вариантом, и вы должны оценить его. Даже если данные часто изменяются, кэширование вывода в течение 30-60 секунд может значительно повысить производительность при очень большом количестве запросов. При необходимости вы можете выполнить частичное кэширование (пользовательские элементы управления) и / или замены. Конечно, это необходимо сделать в сочетании с кэшированием данных.

Answer 2

Не зная точно, сколько данных вы говорите (при условии, что это не много), я склонен несколько с вами согласиться; Если исходить из скорости, статический элемент должен быть «самым быстрым», тогда Cache. Это не обязательно означает, что это лучший вариант, конечно. Масштабируемость не всегда зависит от скорости. Фактически, то, что мы делаем для масштабируемости, часто отрицательно (незначительно) влияет на скорость приложения.

Более конкретно; Я обычно начинаю с объекта Cache самостоятельно, если только немного «статичных» данных чертовски мало и гарантированно не требуется постоянно (в этом случае я обращаюсь к статическим элементам. Не забывайте и о синхронизации потоков, конечно!)

Со скромным объемом данных, который не будет часто меняться вообще, и может быть легко изменен, когда вам нужно, изменяя файлы, как вы заметили, объект Cache, вероятно, является хорошим решением. memcached может быть излишним и слишком сложным ... но это тоже должно сработать.

Я думаю, что основным возможным «негативом» для решения memcached является проблема единой точки отказа; Использование Cache на локальном сервере сохраняет каждый сервер изолированным.

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