[глобально и надежно][ненависть] За что еще я ненавижу PHP

>точнее, у либ, ради которых РНР и юзают

Да какие там либы то. По сравнению с тем же питоном, пхп явно проигрывает по количеству и полезности либ.

> Посмотри, сколько памяти расходует типовой апач+пхп

11 метров на процесс, со всякими mod_security, mod_ssl, mod*cache, и php с модулями поддержки gd, mysql, posgres, ldap и еще много-много всего. И? Один рабочий день программиста обходится в 500 рублей, плюс налоги, плюс управленческие расходы. Один гигабайт памяти стоит тупо дешевле.

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

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

ну ты даёшь. Сервер приложений на скриптовом языке? Это жуткое извращение.
Возьми Neko из http://haxe.org , mod_neko оттудова. Будет почти как PHP, только нормальный компилируемый язык в отдельной VM. Из которого при желании можно генерить и клиентский JS или "ничего_не_поделаешь".

Афтор топика!

Я экспериментировал с технологией, о которой ты пишешь, с полгода назад. На пайтоне. Столкнулся с такой проблемой - когда количество одновременно висящих клиентов переваливает за пару сотен, коннект от некоторых клиентов до сервера происходит с лагом от трех до девяти секунд. А когда клиентов с тыщу - до 21 секунды! Все коннектились на один порт, получается, в один сокет. Тестовая сборка - wsgiserver.py из CherryPy + ab с клиентской стороны.

Вопрос: как побеждать? Разделять на несколько доменов, которые можно потом уже роутить возможно даже на один сервак, но на разные порты? Не нравится :( Ты вообще пробовал хотя бы черновую реализацию этой кометы сваять?

Ты пробовал привесить Psyco? По идее — должно отсрочить неизбежное.

Причина лага в том, что постановка ввода-вывода начинает становиться затратным процессом и в главном цикле проводится больше времени, чем позволительно.

При таком числе коннектов я бы начал чесать репу в сторону тредов, но где-то так, чтобы каждый функционал (а не клиент) сидел в своем треде. Главная задача — облегчить реактор.

Я пока что убедил клиента, что Comet на данном этапе ему не нужен. Потом точно будет нужен Bonjour (для того, чтобы, например, для синхронизации ноута, на который данные собирались весь день, с основным хранилищем, достаточно было воткнуть ноут в ту же сеть, что и хранилище), и тогда от кометы не денешься никуда (потому что UI должен сообщить хозяину).

> При таком числе коннектов я бы начал чесать репу в сторону тредов, но где-то так, чтобы каждый функционал (а не клиент) сидел в своем треде. Главная задача — облегчить реактор.

Да куда уж легче, тестовое приложение делало time.sleep(5) и потом возвращало респонз в три байта длиной. А вообще черрипайский серваг создает пул обработчиков (в отдельном потоке каждый), которые выбирают коннекты из одного сокета в бесконечном цикле.

Я тогда заметил, что лаг для 95% клиентов был сравним с таковым для одного клиента, и для пяти процентов существенно выше, причем был дискретной величиной - 3 секунды, 9 секунд и 21 секунда, плюс-минус пара миллисекунд. Подумал тогда, что эти мэджик намберс не просто так, и это предсказуемое поведение сокета, когда к нему ломится сразу 100/500/1000 клиентов. Но дальше копать тогда не стал, забросил эксперимент.

Короче, реализуешь комету для пайтона, не лагающую при пятистах перзистентных коннектах, обладающую терпимостью к клиентам за нетерпеливыми натами и проксями - поделись кодом с общественностью :)

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

Насчет же комета — я на полном серьезе предлагаю посмотреть на http://divmod.org/, там оно есть в виде Athena (там виджеты, которые комет и делают). Можно хотя бы попробовать.

> А вообще черрипайский серваг создает пул обработчиков (в отдельном потоке каждый), которые выбирают коннекты из одного сокета в бесконечном цикле.

Ах да, незачет. Сокетов — много. По одному на коннект. И выборка событий изо всех них.

Порт — тот один.

ребят, а нафига вам отдельные треды? конечный автомат как в прокси oops-cache не пробовали сделать?

во, на флэймили ...
не проще ли написать апаче модулёк и всё держать в своих руках,
в том числе "отваливание клиентов"