Кто-нибудь использует Memcached с ASP.NET в распределенной ферме? - PullRequest
5 голосов
/ 21 февраля 2009

У нас есть 22 HTTP-сервера, каждый из которых имеет собственный кэш ASP.NET. Они читают из БД только для чтения, которая обновляется только в часы пик.

Мы используем файловую зависимость для аннулирования кэша, предлагая серверам «обновлять» свои кэши ... Если это происходит случайно в часы пик, это может привести к выходу из строя нашего кластера БД из-за внезапного затопления открытых соединений. .

Кто-нибудь использовал memcached с ASP.NET в этой распределенной форме? Мне кажется, что это могло бы дать огромное преимущество, заключающееся в необходимости создания только одного кэша (и попадания в БД в 21 раз меньше), тогда как memcached будет обрабатывать его распределение по каждому блоку.

Если у вас есть, вы помещаете его в тот же блок, что и блоки HTTP, или вы запускаете отдельный уровень кэша? Насколько хорошо он масштабируется, можем ли мы ожидать, что ему понадобятся мощные серверы? Наш рабочий набор данных невелик (мы отлично вписываем его в 4 гигабайта памяти на каждом HTTP-боксе).

Как вы справляетесь с недействительностью?

В поисках опыта и военных историй.

РЕДАКТИРОВАТЬ: Win2k3, IIS6, 64-разрядные серверы ... 4 гигабайта на коробку (я думаю, мы могли увеличить его до 16 гигов, когда мы изменили на 64-битные серверы).

Ответы [ 5 ]

5 голосов
/ 21 февраля 2009

"memcached будет обрабатывать распределение по каждой коробке"

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

В этой статье более подробно обсуждается архитектура memcached: Как работает memcached .

2 голосов
/ 21 февраля 2009

Лучшая практика (согласно сайту memcached) - запускать memcached в том же окне, что и приложение веб-сервера, иначе вы делаете http-вызовы (что не так уж и плохо, но не оптимально). Если вы используете 64-битный сервер приложений (что вам, вероятно, следует делать, если вы собираетесь использовать memcached), то вы можете загрузить каждый из серверов нагрузками памяти, и он будет доступен для memcached. Существует не так много ресурсов процессора, используемых memcached, поэтому, если ваш текущий сервер приложений не облагается налогом, он останется таким.

1 голос
/ 09 марта 2009

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

1 голос
/ 21 февраля 2009

Я не использовал их вместе, но я использовал их обоих в отдельных проектах.

В последний раз я видел, что в документации явно сказано, что совместное использование с веб-сервером в порядке.

Memcache на самом деле нужна только оперативная память, и если вы вычтете из уравнения asp.net кеш, сколько оперативной памяти использует ваш веб-сервер? Наверное, не очень. Он не будет сильно конкурировать с вашим веб-сервером за процессор, и ему вообще не нужен диск. Возможно, вы захотите сегментировать сетевой трафик (если вы этого еще не сделали) из входящих веб-запросов.

Работало хорошо и быстро, у меня с этим проблем не было.

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

0 голосов
/ 06 марта 2009

Стоит проверить Velocity , который является распределенным кешем, предоставленным Microsoft. Я не могу дать вам поэтапное сравнение с memcached, но Velocity интегрирована с ASP.NET и будет продолжать развиваться и интегрироваться.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...