Кэширование для опроса?

Question

Я создаю виджет опроса, используя элементы управления ASP.NET и Linq-to-Sql для сайта с высоким трафиком. Виджет, фактически, уже построен. Но он еще не использует кеширование.

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

Update, я заново сформулировать следующие вопросы:

1. было бы целесообразно для контроля таких как опрос, чтобы поразить базу данных на каждой странице хитом? Как бы эта производительность увеличилась до примерно 20 000 пользователей. Предположим, сервер имеет 2 сервера, балансировщик нагрузки, современный многоядерный процессор и 2 гигабайта.

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

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

Update:

Итак, давайте перейдем сценарий для кэширования. Можно было кэшировать опросы (вопросы), но по-прежнему нужно было бы, вероятно, попасть в базу данных для опросов, полученных от опросов пользователей. Одна из возможностей - создать тень, записывая как хранилище в памяти, так и хранилище базы данных.

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

Я хочу ознакомиться с подробной информацией о предлагаемой схеме. Например, как вы будете использовать кэширование вывода, кэширование linq-to-sql и т. Д. Не только общие понятия.

Answer 1

Я бы кэшировать следующее:

• Список всех опросы идентификаторов (ключ будет что-то вроде «all_polls»)
• Всех опросов с их результатами (ключ будет «poll_ < ID>»)
• Списков идентификаторов пользователей опроса завершил (ключ будет «users_polls_ < USER_ID>»)

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

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

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

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

Для C# вы можете использовать клиент Enyim Memcached (http://memcached.enyim.com/) для подключения к серверу и сервер Northcale Memcached (http://www.northscale.com/products/memcached .html) для серверов.

Инструменты Enyim и Northscale являются бесплатными (с открытым исходным кодом), и оба они очень стабильны и очень полезны в производстве. И нет, я не нанят ни одной из компаний :-)

Answer 2

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

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

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

1. Постоянная информация, такая как правила, вопросы опроса и т. Д. Может/должна быть кеширована.

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

Answer 3

Сколько хитов базы данных может SQL дескриптор Server/ASP.NET, прежде чем замедление на "типичного" сервера?

Невозможно ответить на этот вопрос, тем более, что вы не даете никакой информации, даже версии используемого вами SQL-сервера.

Что такое "типичный сервер"? Что конкретно попадает в базу данных, о которой вы говорите? Как создается база данных? Какова скорость сети между машиной SQL Server и серверной машиной ASP.NET? Каково же узкое место на самом деле? Что говорит SQL Profiler? (И есть десятки и десятки других вопросов, как это задать)

Какое кэширование для этого сценария вы бы хотели использовать?

Так как вы хотите, чтобы уменьшить количество запросов к базе данных, принять во внимание, что:

• После того, как вы загрузите список опросов, что текущий пользователь не принято, вам не придется перезагрузите этот список, пока пользователь не возьмет пул.
• Если вы кешируете список пулов, чтобы взять, после обратной передачи, вам не нужно проверять, не взял ли пользователь пул: если он в списке, то это нормально.

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

Answer 4

Сколько обращений к базе данных может обрабатывать SQL Server/ASP.NET до замедления на «типичном» сервере ?

Определить типичный сервер. Могу ли я предположить двухъядерный четырехъядерный сервер с 64 ГБ оперативной памяти и достаточное количество дисков для обработки нагрузки ввода-вывода (например, для 24 дисков для автономной системы)? Это моя типичная автономная база данных сервера/производительности. Вы найдете много других людей, здесь есть другие «типичные» серверы, которые сильно различаются.

Какой тип кэширования для этого сценария вы бы использовали?

Старое правило: кешируйте как можно больше, как только сможете. Как и вывод IIS, кэширование превосходит все остальное. Кэширование данных ударяет по базе данных и т. Д.

Итак, попробуйте кэшировать столько, сколько возможно через кеширование вывода IIS.

Update:

Итак, давайте перейдем сценарий для кэширования. Можно было бы кешировать опросы (вопросы), но все равно нужно было бы, вероятно, попасть в базу данных для опросов UserTakes (ответы пользователей).

Нет, вы также можете кэшировать результаты, скажем, одну минуту. Вы действительно думаете, что люди заинтересованы в ПОСЛЕДНЕМ ВТОРОМ АКТУАЛЬНОМ РЕЗУЛЬТАТЕ при активном опросе?Дельвирование новых результатов каждую минуту (или 15 секунд и т. Д.) Полностью прекрасное.

И ЗНАЧИТЕЛЬНО уменьшит нагрузку на сервер.