Повысит ли производительность кэширование данных на сервере?

Question

У меня есть webservice (WCF) и MembershipProvider / RoleProvider для проверки учетных данных.

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

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

Список пользователей не большой.Я не думаю, что это когда-либо будет больше, чем 100-200.

С одной стороны - я знаю, что SQL Server кеширует небольшие таблицы и разработан для того, чтобы заботиться об этих выборках.OTOH - я вижу это в профилировщике :) И память на стороне веб-сервера будет занята.Кроме того, поиск на веб-сервере все еще необходимо выполнить (ЦП / память).

Я думаю, я хочу услышать о вашем опыте, и стоит ли мне вообще беспокоиться об этом?Я разместил теги «стратегически», так что, надеюсь, и администратор базы данных, и разработчики предоставят мне некоторую информацию:)

Answer 1

Абсолютно, избежание возврата в оба конца на сервер БД окупается.Это не только проблема кеша памяти.Выполнение запроса, даже тривиального, довольно сложный процесс:

• соединение должно быть открыто и аутентифицировано.Это амортизируется с помощью пула соединений, правда, но даже для пулированного соединения все еще требуется одна дополнительная передача туда и обратно для sp_reset_connection во время открытия.
• запрос должен быть составлен и отправлен на сервер
• задача должна быть выделена для запроса, и рабочий должен ее взять.работники являются очень ценным ресурсом в SQL Server, так как их так мало, что .
• SQL должен анализировать ваш запрос.В лучшем случае он может пропустить синтаксический анализ, но все еще должен хэшировать вводимый текст, см. Динамически создаваемый SQL и параметры в SQL Server
• запрос должен быть выполнен, блокировки получены, страницыв памяти посмотрел вверх.Блокировка особенно дорога, потому что она может конфликтовать с другой операцией и должна ждать.Использование изоляции моментальных снимков может помочь в некоторой (большой) степени.
• результат должен быть перенаправлен обратно клиенту.
• клиент должен проанализировать метаданные ответа.
• клиент должен обработать ответ.

Локальный поиск в памяти выиграет в большинстве случаев.Даже поиск в удаленном кэше, например memcached , выиграет запрос к БД, независимо от того, насколько тривиален запрос.Так почему бы не всегда кэшировать локально?Из-за одной из самых сложных проблем в CS: когерентность и аннулирование кэша.Это проблема, которая на намного сложнее, чем вы думаете, сейчас, независимо от того, насколько сложна она для вас;).Вы можете взглянуть на собственное решение SQL Server для аннулирования активного кэша, Query Notifications , которое довольно хорошо работает для довольно статичных наборов результатов.У меня есть интеграция LINQ с проектом Query Notification, LinqToCache .

Answer 2

Зависит. Что происходит, когда вы хотите удалить или отключить учетную запись пользователя и сразу же вступить в силу?

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

Скорее всего, оно того не стоит.

Answer 3

У нас есть служба на основе http - тонны запросов, и каждый запрос должен быть аутентифицирован (90% очень маленькие запросы, а остальные довольно большие). Даже после размещения БД на одной и той же машине (24 ГБ ОЗУ, быстрые диски и т. Д.) Мы могли бы улучшить масштабируемость на 100%, внедрив кэш (на основе ConcurrentDictionary) - таким образом, имея возможность удвоить запросы на одной машине.

Для немедленного вступления в силу изменений в пользователях / логинах и т. Д. Мы внедрили веб-сервис (SOAP), который используется для такого рода вещей и поддерживает кэш в режиме «сквозной записи».

Так что в целом мы действительно довольны кэшированием.

Answer 4

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

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

Answer 5

Я создал несколько крупных веб-сайтов с использованием различных провайдеров ASP.Net.Я написал их для хранилища таблиц Azure, Oracle, серверов LDAP и различных пользовательских серверных частей.

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

1. Инвалидация кэша.Пользователь уволен, а вы обновляете БД через внеполосный процесс.Как вы обновляете кеш вашего веб-сервера?
2. Ошибки.Хотя кэширование не сложно, чем меньше строк кода вы должны написать, тем лучше.
3. Безопасность.Есть проблемы безопасности, которые вы, вероятно, не заметите.
4. Время.Работа над функциями клиента.Это намного важнее.

Оптимизация, если / когда вам нужно.До этого добавляйте функции, чтобы сделать ваши вещи лучше.

Если вас беспокоит масштаб, поместите таблицы User / Role в отдельную БД из остальных ваших данных.Если вы начинаете перерастать этот сервер, вы можете легко перенести ваши пользовательские данные в большую БД.