Кэширующая архитектура для Memcached/wcf/web/ravendb

Question

У меня есть вопрос архитектуры, связанный с моей установкой на основе ravendb.

я следующее:

ravendb -> ФОС сервис -> (веб/iphone/Android)

веб/iphone/андроид уровень на самом деле (на данный момент - это растет) соединения до 7 wcf-сервисов

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

Мой вопрос заключается в следующем:

Я смотрю с помощью Memcached - в каких точках (у меня есть небольшой опыт установки это вверх) может я/я должен использовать Memcached?

между ravendb и wcf? между wcf и (web/iphone/android)?

между всеми?

Могу ли я столкнуться с проблемой простоя данных? это позаботится об упрощении?

Answer 1

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

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

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

Answer 2

В качестве дополнительного указателя интерфейс RavenDB REST использует ETags для поддержки HTTP-возможностей cahing. Если ваш HTTP-клиент хорошо работает с этими механизмами, у вас будет отличное кэширование из коробки.

Я не знаю, как это играет со стеком WCF, хотя