Подсказки для веб-службы с высоким трафиком, c # asp.net sql2000

Question

Я разрабатываю веб-сервис, методы которого будут вызываться из «динамического баннера», который будет отображать своего рода очередь сообщений, прочитанных из таблицы сервера SQL.

Баннер будет оказывать сильное давление на домашние страницы сайтов с большим трафиком; Каждый раз, когда баннер будет загружен, он будет вызывать мой веб-сервис, чтобы получить новую очередь сообщений.

Теперь: я не хочу, чтобы весь этот трафик отправлял запросы к базе данных каждый раз, когда загружается баннер, поэтому я думаю использовать кэш asp.net (т.е. HttpRuntime.Cache [cacheKey]), чтобы ограничить базу данных доступ; Я постараюсь обновлять кеш каждую минуту или около того.

Очевидно, я постараюсь как можно меньше сообщений, чтобы ограничить трафик.

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

Решением является c # веб-сервис, asp.net 3.5, sql server 2000.

Есть подсказка? Другие подходы?

Спасибо

Andrea

Answer 1

Это зависит от многих вещей:

• Если в данных есть небольшие изменения (например, бэкэнд с кнопкой «Опубликовать» или ежедневные пакеты), то я бы определенно использовал статические файлы (обновляемые с помощью push из бэкэнда). Мы использовали это решение на нескольких крупных сайтах и ​​работали очень хорошо.
• Если данные достаточно малы, кэширование памяти (например, Http Cache) является жизнеспособным, но следует остерегаться проблем с блокировкой, а также помнить, что Http Cache не будет работать так хорошо при большой нагрузке на память, поскольку элементы могут истекает рано, если фреймворк нуждается в памяти. Я был укушен этим раньше! С вышеупомянутыми предостережениями Http Cache работает довольно хорошо.

Answer 2

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

Кэширование ASP.NET: зависимость кэша SQL с SQL Server 2000

Answer 3

Если вы идете по пути к файлу, помните об этом.

http://petesbloggerama.blogspot.com/2008/02/aspnet-writing-files-vs-application.html

Answer 4

Запись файла является лучшим решением IMHO - он обслуживается кодом ядра IIS без огромных накладных расходов asp.net, и вы можете скопировать файл в CDN позже.

Кэширование зависимостей AFAIK не очень эффективно в SQL Server 2000.

Answer 5

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

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

Больше информации на домашней странице библиотеки SixPack . Обратите внимание, что код (особенно прямой кеш) тестируется под нагрузкой.

Вот пример простого кэширования:

    [Cached]
    public class MyTime : ContextBoundObject
    {
            [CachedMethod(1)]
            public DateTime Get()
            {
                    Console.WriteLine("Get invoked.");
                    return DateTime.Now;
            }
    }

Answer 6

Спасибо всем, так как данные имеют небольшой размер, но базовые таблицы изменятся, я думаю, что я пойду по пути HttpCache: мне нужен способ сокращения доступа к БД, даже если данные меняются это причина того, что мы не используем прямую зависимость от Sql, как предлагает @Bloodhound).

Я сделаю стресс-тест перед выходом в свет, я думаю.

Еще раз спасибо всем.

Answer 7

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