|
Привет всем.
Кто-нибудь использует Nginx HTTP Push Module ?
Мы его используем в качестве основы для доведения сообщений на клиент.
В принципе все хорошо. Но настораживает следующая вешь:
Раньше мы и спользовали back-end в качестве comet-сервера.
Но потом, для экономии ресурсов (памяти и количества открытых сокетов) реорганизовали
систему под использование вышеназванного плагина.
------------------
Наше окружение:
nginx: 0.7.65 (RHEL, CentOS x86, X86-64);
nginx_http_push_plugin: 0.692b;
------------------
часть nginx.conf:
-----------------
#proxy pass for comet
# internal publish endpoint (keep it private / protected)
location /app1/v1/informing/pub {
set $push_channel_id $arg_id; #/?id=239aff3 or somesuch
push_publisher;
push_store_messages off; # enable message queueing
push_message_timeout 2h; # expire buffered messages after 2 hours
push_max_message_buffer_length 10; # store 10 messages
# push_min_message_recipients 0; # minimum recipients before purge
}
# public long-polling endpoint
location /app1/v1/informing/sub {
set $push_channel_id $arg_id;
push_subscriber;
# how multiple listener requests to the same channel id are handled
# - last: only the most recent listener request is kept, 409 for others.
# - first: only the oldest listener request is kept, 409 for others.
# - broadcast: any number of listener requests may be long-polling.
push_subscriber_concurrency broadcast;
#push_authorized_channels_only on;
#push_max_channel_subscribers 1;
default_type application/x-_javascript_;
}
----------------
Так вот, если посмотреть на приложенный график статистики, но видно что до использование плагина, количество Client Stat было небольшим.
Теперь же оно увеличились значительно и продолжает расти.
С чем это может быть связано.
ID канала у нас равно ID Http Session.
Может быть плагин не очищает устаревшие каналы?
Кто-нибудь может ответить на этот вопрос.
Сейчас один процесс nginx потребляет около 64 мб RAM.
--
Best Regards, Eugene Batogov
| 
