ASP.NET (MVC) Outputcache и параллельные запросы
Скажем, это, теоретически, у меня есть страница / действие контроллера в моем веб-сайте, который делает некоторый очень тяжелый материал. Требуется приблизительно 10 секунд для завершения, это - операция.
Теперь, я использую outputcache механизм.NET для кэширования его в течение 15 минут (для примера, я использую [OutputCache(Duration = 900)]) Что происходит, если после 15 минут кэш истекает, и 100 пользователей запрашивают страницу снова в течение тех 10 секунд, которые требуется, чтобы сделать тяжелую обработку?
- Тяжелый материал сделан только в первый раз, и существует некоторый механизм блокировки так, чтобы другие 99 пользователей получили результат кэша
- Тяжелый материал сделан 100 раз (и серверу наносят вред, поскольку он может взять до 100 * 10 секунд),
Легкий вопрос, возможно, но я не на 100% уверен. Я надеюсь, что это - номер один, хотя:-),
Спасибо!
2 ответа
http://www.playframework.org/ имеет режим Scala. Игра - это очень рельсы-иш. Может удовлетворить ваши потребности.
-121--3677783-Ну, это зависит от того, как у вас настроено IIS. Если у вас меньше 100 рабочих потоков (скажем, 50), то «тяжелые вещи» сделано в 50 раз, накипив свой сервер, а затем остальные 50 запросов будут поданы из кэша.
Но нет, нет «механизма блокировки» в результате кэшированного действия; Это было бы контрпродуктивным, по большей части.
Редактировать : Я считаю, что это верно, но тесты Ника говорят иначе, и у меня нет времени, чтобы тестировать сейчас. Попробуй сам! Остальная часть ответа не зависит от вышеизложенного, хотя, и я думаю, что это важнее.
Вообще говоря, однако, нет веб-запроса, кэшированного или иначе, должен занять 10 секунд для возврата. Если бы я был на вашей обуви, я бы посмотрел на каким-то предварительно вычисление жесткой части запроса. Вы все еще можете кэшировать результат действий, если вы хотите кэшировать HTML, но звучит так, как ваша проблема несколько больше, чем это.
Вы Могут также хотят , чтобы рассмотреть асинхронные контроллеры . Наконец, обратите внимание, что хотя IIS и ASP.NET MVC не заблокируются на этих тяжелых вычислениях, вы могли бы. Если вы используете асинхронные контроллеры в сочетании с замком на вычислениях, то вы бы эффективно бы поведен поведение. Я не могу сказать, что это лучшее решение, не зная больше о том, что вы делаете.
Похоже, что заблокирован здесь, выполняет простой тест:
<%@ OutputCache Duration="10" VaryByParam="*" %>
protected void Page_Load(object sender, EventArgs e)
{
System.Threading.Thread.Sleep(new Random().Next(1000, 30000));
}
Первая страница попадает в точку останова, даже если он левый спать ... никакой другой запрос не попадает в точку останова в Page_load Метод ... Он ждет первого для завершения и возвращает этот результат для всех, кто просил эту страницу.
Примечание. Это было проще тестировать в сценарии WebForms, но с учетом этого является общий аспект каркасов, вы можете сделать тот же тест в MVC с тем же результатом.
Вот альтернативный способ тестирования:
<asp:Literal ID="litCount" runat="server" />
public static int Count = 0;
protected void Page_Load(object sender, EventArgs e)
{
litCount.Text = Count++.ToString();
System.Threading.Thread.Sleep(10000);
}
Все страницы, поставившие в очередь, в то время как первый запрос идет спать, будет иметь тот же вывод счетчика.