Да, я уже потом понял, что считать то надо не коннекшны, а сырой C на транскодировании спикса. Я предоставлю этот бенчмарк.

Ещё сколько-то уйдет на эходав, я его пока не завел.


Что до utf8, то вообще в эрланге есть библиотека для работы с ним, но я просто не могу себе даже представить, зачем вообще на сервере может потребоваться обработка юникода (кроме как для полнотекстового поиска). Ведь не на буквы же резать. Даже в UCS32 нет соответствия между графическим символом и одним кодпойнтом.

Нужно учесть, что эходав тоже будет жрать ресурсы компа. Полюбому надо будет держать в памяти какое-то количество фреймов, которое теоретически должно зависеть от RTT конкретного коннекта.
Хорошо бы получить бенчмарк на реальной нагрузке или на имитаторе таковой не в лабораторных условиях. Ну чтобы сетевые задержки тоже оказали должное влияние на результат бенчав


Про утф8: по замыслу медиастриммер должен плотно работать с базой, которая в utf8.

P.S. офтоп: эрланг написан на эрланге или на с++ ?

Давай я как получу результаты, тебе расскажу. Но оно не должно отличаться от других решений, потому что самое долгое*— это транскодирование.

Про utf8: binary никак не интерпретируется и магических разваливаний текста не будет. Вопросы про utf8 чаще всего возникают, когда хочется парсить текст регекспами. Вот чего с ними будет*— просто не проверял.

Сам эрланг внутри написан на С и чуточку ассемблера, как и всё остальное в этом мире =)