Здравствуйте, Шахтер, Вы писали:

Ш>Ну почему Erlang? Обычный C с поддержкой soft-thread.

Каменный молоток тоже решение когда других под рукой нет.

Здравствуйте, Cyberax, Вы писали:

C>Нет Я бы побоялся чем-нибудь с такого жуткого сайта пользоваться.

уговаривать небуду....

Здравствуйте, Cyberax, Вы писали:

C>При отправке сообщения Erlang-машина смотрит, что если affinity у
C>целевого процесса совпадает с текущим — то никаких блокировок не нужно.

Вероятность этого будет стремительно снижатся с увеличением ядерности процессоров. Сейчас это, допустим, 50-25%, потом будет 12-6%...

C>HTTP-сервер — Apache с mod_jk2-коннектором. Он-то не тормозит (так как
C>работает просто "шлангом").

Собственно, тут NIO особенно и не пахнет. Несмотря на то, что он работает "шлангом" ему нужно держать один поток на каждого keepalive клиента или клиента, который ждет ответа, что уже дорого само по себе.

C>Я хотел сказать, что решения с пулами тоже не всегда блестяще работают.

Естественно, no silver bullet.

C>Вот тут сравнение:
C>http://www.sonicsoftware.com/products/whitepapers/docs/sonic40_vs_mqseries52.pdf

Ну все верно, см. стр. 19 для non-durable pub-sub. И это на оч древнем железе (2xPIII-800Mhz). Там речь идет о 8-10к. Собственно, jabber, скорее всего не персистентный и без acknowledge. Да и размер у них наверняка маленький.

C>Мы тестировали SonicMQ, ActiveMQ и MQSeries. В среднем на разумном
C>железе они отваливаются после 300-400 соединений и обеспечивают всего
C>несколько десятков сообщений в секунду на клиента. А это означало, что

Этот throughput уже выше чем показатели erlang jabber (2к сообщений). Проблемы с соединением решаемы NIO имхо. Кроме того, скорее всего, у вас persistence & acknowledgement используется.

C>Jabber может иметь сложную топологию сети. То есть могут быть
C>промежуточные relay'и и т.п. А еще там есть multicast'овые сообщения, и
C>прочие фичи.

Ну и что? Хочешь сказать реально тяжелые алгоритмы используются, которые дают задержку при обработке ощутимую?

C>Ну так запусти еще парочку сервисных потоков, которые будут кэшировать
C>результаты локально для каждого процессора.

Т.е. процессу Erlang известно на каком он физическом процессоре работает и м/у физическими процессорами миграция невозможна? ИМХО, оба пункта, особенно второй — нехорошо.

>> Когда с SMP будет все в порядке, тогда поверю. Почему тогда thinthreads
>> глючили в JRockit и их оттуда убрали? Кстати говоря, вполне можно
>> достать старую версию JRockit и "наслаждатся" дешевой многопоточностью.
C>Скорее всего, не справились со сложностью системы.

Вот тоже самое сейчас и с SMP Erlang. Или нет?

C>А драйверы для SATA2-чипов, гигабитных контроллеров, I2C-мониторинга там
C>из воздуха появятся?

Почему из воздуха? Их уже давно VMWare сделала.