Тайм-аут BookSleeve Wait() на странице Razor при тестировании производительности
Я только начинаю бездельничать с BookSleeve (и redis) в Windows и просто хотел узнать, смогу ли я получить какое-то указание о том, что я могу делать здесь неправильно. Используя следующий код, а затем запустив ab против него, я могу обработать ~500 запросов до того, как w3wsvc.exe выйдет из строя. Когда я присоединяюсь к процессу для отладки, я вижу, что время запроса к серверу redis истекло.
@using (var conn = new BookSleeve.RedisConnection("localhost"))
{
conn.Open();
var catgrabber = conn.ListRange(0,"categories",0,-1);
byte[][] categories = conn.Wait(catgrabber);
foreach (byte[] category in categories)
{
<h3> @System.Text.UTF8Encoding.UTF8.GetString(category) </h3>
var actgrabber = conn.ListRange(0, String.Format("activity:{0}",
System.Text.UTF8Encoding.UTF8.GetString(category).Replace(' ', '_')), 0, - 1);
byte[][] activities = conn.Wait(actgrabber);
foreach (byte[] activity in activities)
{
<label for="@System.Text.UTF8Encoding.UTF8.GetString(category).Replace(' ', '_'):@System.Text.UTF8Encoding.UTF8.GetString(activity):12345">
<input type="checkbox" id="@System.Text.UTF8Encoding.UTF8.GetString(category).Replace(' ', '_'):@System.Text.UTF8Encoding.UTF8.GetString(activity):12345" value="@System.Text.UTF8Encoding.UTF8.GetString(activity)"/>
@System.Text.UTF8Encoding.UTF8.GetString(activity)
</label><br />
}
}
}
Я еще не установил.NET async/await CTP.
Теперь, для всего лишь одной веб-страницы, это прекрасно работает. Я просто хотел ударить по серверу, на котором это делается, поэтому я сделал...
ab -n 1000 -c 5 http://server/page.cshtml
Он будет обслуживать 500-700 запросов, а затем потерпит крах. Хотя я не уверен, что у меня когда-либо будет такая нагрузка, я считаю, что это указывает на явный недостаток в моем коде, и хотел бы, чтобы кто-то умнее, чем я, указывал на то, что я делаю неправильно.
Спасибо!
1 ответ
Первое, что я замечаю, это то, что этот код слишком сложен, чтобы его можно было увидеть в бритве, - его нужно перенести на контроллер. Это само по себе, вероятно, не является проблемой.
Проблема, вероятно, заключается в большом количестве создаваемых соединений, которые могут быть не полностью очищены перед загрузкой следующего. С сайта BookSleeve:
Соединение является поточно-ориентированным и (за исключением Wait) неблокирующим, поэтому вы можете разделить соединение между любым количеством вызывающих абонентов, сколько вам нужно - это позволяет веб-сайту очень эффективно использовать только одно соединение Redis. Кроме того, переключение баз данных (12 в приведенных выше примерах) обрабатывается на уровне сообщений, поэтому вам не нужно вводить отдельные команды SELECT - это позволяет использовать многопользовательский режим для набора баз данных без необходимости синхронизировать операции.
Это означает, что вы, вероятно, получите лучшие результаты, если создадите одно общее соединение для обработки 1000 запросов, чем если вы создадите 1000 соединений для обработки одного запроса каждый.