Что буду делать когда будут тысячи подключений? Включу kqueue бэкендом (сейчас там простой select). Серверная часть является FSM, как nginx, и может спокойно выдерживать тысячи подключений. Возможность масштабирования из коробки, вещь, конечно хорошая, но тут особо не нужная. Этот чат висит на дохлой вдске с 256 метрами памяти и 480 мгц проца, плюс на той же вдске хостится сайт с80к хитов в сутки — и ничего, успешно работает :)

Добавил, чат перезапустил.

Можно, в принципе, на чем угодно. Это вообще как бы пруф-оф-концепт и на полноценный чат не претендует :) Профит использования эрланга по сравнению с перлом вижу разве что в возможности использования многоядерных процессоров (так как текущая реализация на перле выполняется в один поток)

нашел более менее сносное решение проблемы флуда, напишу после того как все флудеры уйдут, ибо при знании конфига nginx оно легко обходится :) сообщения теперь можно слать не чаще 1 раза в 6 секунд, а на long-polling соединения это не влияет

Думаю это из-за того, что для добавления сообщений в чат используется сразу несколько обращений к DOM-дереву. В реальном чате так, конечно, делать не надо, здесь это сделано для того чтобы не преобразовывать спецсимволы на серверной стороне

Поставил.

убрал nodelay и вернул ограничение на 1 запрос в секунду — полегче стало, только сообщения теперь приходят пачками с заметной задержкой. Но это лучше чем стена флуда :)

Она работала, но пришлось повысить лимит до 4 запросов в секунду, ибо при плотном потоке сообщений даже long-polling запросы посылаются чаще — этого не предусмотрел… Защиту от флуда надо делать внутри серверной части, nginx тут не спасет.

Думаю загнется он только тогда когда загнется канал… Будет тормозить — можно подрубить EV и установить бэкендом обработки событий kqueue

поправил, плюс ещё сделал невозможность разуплотнять окно сообщений :)

Если вы про второй недостаток (Отсутствие синхронизации исходящих запросов), то я про отсутствие синхронизации исходящих запросов на стороне клиента, проблема решается просто — небольшим воркэраундом над функцией посылки запроса.

Думаю, в jquery функция $.ajax учитывает особенности IE. Причем из IE все сообщения на сервер уходят, только ответа не видно. Такое ощущение, что просто не срабатывает колбэк success

По поводу ошибки 2.3. Есть такая конструкция: server {
listen 80;
server_name blabla.ru *.blabla.ru "";

if ($host != blabla.ru ) {
rewrite ^(.*)$ httр://blabla.ru$1 permanent;
}

Как тут можно убрать if $host?

Ссылки на сервисы они тоже показывают.
Вы предлагаете весь этот текст вывести в результатах поиска?

А что, надо показывать ответ пользователю на его запрос так, чтобы он его искал по всей странице? Какие плохие Яндекс и Гугл, рекламируют свои сервисы :(

Вероятно, у вас плавающий айпи. Можете привести примеры сервисов, которые правильно определяют ваш город?

А разве что-то неправильно? Если приснилась лошадь, пользователю предлагается пройти по ссылке и посмотреть, что же это значит.

Эх, тогда, видимо, придется оставить использование Catalyst::Plugin::PageCache — абсолютно прозрачно для приложения и можно быстро сменить кеширующий бэкенд с файлов на тот же мемкеш или memory-mapped файлы. Слишком уж негибкое получается кеширование nginx'ом, хоть, наверное, и быстрей на порядок, но мне пока и кеша на уровне приложения хватает.

Спасибо за статью, как раз подумываю переложить кеширование с Catalyst::Plugin::PageCache на nginx, руки не доходили проверить, будет ли кешироваться страница с обработанными SSI-директивами, или без изменений. Было бы замечательно, если:
1. Можно было бы кешировать страницу только для неавторизованных пользователей. Описанный в документации способ fastcgi_cache_key "...$cookie_user";, не подходит — нужно кешировать только в случае пустой куки, а не для каждого её значения. Хотя, можно попробовать загнать директиву fastcgi_cache в if.
2. Была бы возможность принудительно очищать закешированную страницу по запросу из приложения. Надо проверить, будет ли работать просто удаление файла с именем, равным md5 от fastcgi_cache_key.

В моем случае — никак, поскольку отсутствует разделение boss — worker, используется только один процесс. Эта задача отлично решается модулем FCGI::ProcManager.

Насколько знаю, Net::Oscar рабочий. В принципе, можно использовать мой модуль — там реализована отправка сообщений, и колбэк на принятое сообщение (но нет разбора этого сообщения и выдирания текста сообщения из пакета). При желании можно допилить до полноценного icq-клиента и выложить на CPAN, я этим вряд ли буду заниматься