ASP.net серверная задержка. Чат на long polling?

Question

[Алексей Лебедев]

Раньше пользователи чата слали запрос на получение новых сообщений раз в пол секунды. Я хотел бы сократить все это и сделать один запрос в 25 секунд, при простаивании чата или по мере поступления сообщений.

protected void Page_Load(object sender, EventArgs e)
    {
//... Проверка авторизации и прочее...
        using (var conn = new SqlConnection(ConfigurationManager.AppSettings["sql"]))
        {
            conn.Open();
            Response.Write(@"{""chat"":[");
             // Один запрос к БД. Выполняется 1 раз
             // ..................


           // Запрос к БД для получении новых сообщений. Его надо делать раз в пол секунды.
            for(byte i=0; i<50; i++)
           {
                using (var comm = new SqlCommand("...", conn, null))
                {

                    using (var reader = comm.ExecuteReader())
                    {
                        byte i = 0;
                        while (reader.Read())
                        {
                            if (i != 0)
                            {
                                Response.Write(@",");

                            }
                            i++;
                           //Вывод результатов.
                       }
                   }
                 Thread.Sleep(500);
               }
            }
            Response.Write(@"]}");
        }
    }
}

Такой запрос тормозит весь сервер. Я слышал про потоки, но мне кажется здесь можно решить простым способом.

Что лучше сделать в этом случаe?

Answer 1

[Дмитрий Гукетлев]

а) не долбите базу каждые 500 милисекунд. Если у вас в чате 100 человек, получается уже 200 запросов к БД в секунду. Не боитесь что база просядет? Сделайте статик класс, который в котором будет храниться ваш чат. В нем понадобится по сути 2 метода: добавить сообщение (добавляется во внутренее хранилище и в БД) и получить сообщения (из внутреннего хранилища). В статическом конструкторе при старте приложения загружаете последние сообщения в память. Учтите что надо делать класс thread-safe.
б) потоки обработки лочьте на Monitor, а при поступлении сообщения сбрасывайте его из статик класса. (см тут: stackoverflow.com/questions/12522714/thread-syncronization-with-eventhandler )
в) думаю вам идеально подойдут тут Asynchronous Controllers из MVC. Не уверен, что в ASP.NET можно отправить thread в бэкграунд освободив поток обработки.
г) тормозит не «весь сервер», а поток из пула потоков обработки запросов. Хотя если у вас в пуле только 1 поток, то да — весь сервер
д) прежде чем браться за эту задачу рекомендую разобраться с потоками поплотнее чем «я слышал про». Все таки .NET не php, и тут уровень вхождения выше, хотя возможно кажется, что тут все легко.
е) я понимаю когда люди пишут карова или сонце, ну как слышу так и пишу. Но что, скажите, что заставляет вас писать «в этом случаи»? Даже произносится же через е.

Comments

[Алексей Лебедев]

а) У меня около 50 комнат. Т.е. стоит хранить все 50 комнат? В комнате обычно от 1 до 20 человек.
д) я думал, что есть более простое решение.
г) извиняюсь, исправил

[Дмитрий Гукетлев]

В многопоточности ничего сложного нет :) стоит немного разобраться и вы раскроете для себя очень широкие горизонты. Почитайте на русском Трэй Нэш «C# для профессионалов». Там есть глава про многопоточность. А с появлением Task, и async\await писать мнопоточные приложения становится до смешного просто и удобно.

Но к сожалению какой бы сахар не добавляли в язык все равно придется изучить как все устроено внутри.

[Дмитрий Гукетлев]

по а. Смотрите если у вас доступ к данным осуществляется так часто и без сложных запросов, а данных мало, то есть смысл хранить их не в БД, а прямо в оперативке в приложении. Нет ничего предрассудительного в том чтобы хранить 50 или 150 комнат, памяти это много не займет. Список сообщений это List. Допустим комната идентифицируется строкой или номером. Получается все сообщеня можно хранить в Dictionary<string,List>.

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

[Дмитрий Гукетлев]

Парсер съел тэг. Должно быть
Dictionary<string,List<Message>>

Answer 2

[lam0x86]

Советую почитать про библиотеку SignalR.