comet.c зависает при наличии более 6 подключений

Еще вопрос по поводу coment.c в gwan.
В браузере откройте несколько страниц csp_comet.html, запустите один и тот же канал с той же частотой. 1 сек.
Все вызовы ajax на comet.c с отметкой времени.
Но, когда страниц слишком много (около шести страниц), вновь открытая страница продолжает открываться без отображения каких-либо данных.

В данный момент даже другим браузером другие скрипты и статические страницы того же виртуального хоста недоступны. Браузеры ничего не показывают. Я пытался посетить другие виртуальные хосты (того же слушателя в gwan), все работает нормально, но с задержкой.

Я попытался убить несколько страниц и обнаружил, что некоторые из них мертвы (0 OK вместо времени по Гринвичу в csp_comet.html отображается 0 OK, и прекращено обновление).
Продолжайте убивать страницы, последним зависшим запросом стал ответ на отображение данных. В этом состоянии насчитывается около 6 активных кормящихся комет.

Кто может сказать, что произошло?
Или это можно воспроизвести на вашей стороне?

Моя версия gwan — 4.3.14
Ubuntu 12.04.2 LTS \n \l (3.2.0-49), 64-разрядная версия

результат ../?отчета ---------------------------
Запросы
Все: 39 (76,92 % промахов кэша)
HTTP: 13 (33,33 % всех запросов)
Ошибки: 1 (2,56 % всех запросов) CSP: 50 (128,21 % всех запросов) Исключения: 0

Принятых подключений: 36 (1,08 запросов на одно подключение)
Закрытых: 30
Время ожидания: 9 (25,00%) Принятых:9 Чтение:0 Медленное:0 Сборка:0 Отправка:0 Закрытие:0
Занято: 1 (Ожидание: 0 Чтение: 0 Ответ: 1 Отправка: 0 Нажатие: 5 Ретрансляция: 0 Закрытие: 0)

активный сокет потока lastread тайм-аут отправлен ip:port state request
1 19 00:26:42 00:00:00 00:00:00 0 127.0.0.1:22182 rSEND
1 20 00:26:27 00: 00:00 00:00:00 0 127.0.0.1:22694 rSEND
1 22 00:26:19 00:00:00 00:00:00 0 127.0.0.1:23206 rSEND
0 18 00:01 :09 00:00:00 00:00:00 0 127.0.0.1:48294 rSEND
0 23 00:00:00 00:00:00 00:00:04 0 127.0.0.1:49830 SEND GET /?report
0 27 00:00:53 00:00:00 00:00:00 0 127.0.0.1:48806 rSEND


person k.k. lou    schedule 11.07.2013    source источник


Ответы (1)


Я предполагаю, что ваша проблема отличается от представленной здесь: "comet.c не может работать с более чем одной страницей, открытой в браузере" ... и что вы используете собственное "исправление" (a случайный аргумент URI).

Первый вопрос, который приходит на ум: пробовали ли вы использовать 6 разных клиентов (используя 6 разных IP-адресов)?

Предоставляемые вами данные:

Timeouts:9 (25.00%) 

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

person Gil    schedule 11.07.2013
comment
спасибо за ваше руководство. Буду пробовать много клиентов с разными IP. - person k.k. lou; 12.07.2013
comment
Если это проблема клиента, почему другой браузер не может получить доступ к странице, когда та же самая страница висит в другом браузере? - person k.k. lou; 12.07.2013
comment
На мертвой странице 0 OK заменяет время по Гринвичу. Он должен быть отправлен сервером, чтобы разорвать это соединение. Если это так, это может быть не проблема клиента. Остановка обновления страницы может быть вызвана сервером, а не клиентом. - person k.k. lou; 12.07.2013
comment
Вот что происходит, когда время ожидания клиента истекает. - person Gil; 13.07.2013