Родная стихия для С++

О профессионалы в треде, надо сообщить компании эриксон, что они ничего не понимают.

Еж на ерланге

Суть токова... Резервируешь массивы под будущие патчи, патчишь бинарь джампами на области памяти с новым кодом... Вуаля :) http://moss.csc.ncsu.edu/~mueller/seminar/fall06/BartonMiller.pdf А потом берешь dyninst и оно делает это за тебя http://www.dyninst.org/

Эрланг сейчас развивает эриксон. Для эриксона основным направленеим является телеком. Вот типичные примеры приложений - софтсвитчи, IMS, PCRF, PCEF, MME, SGW и куча других абревеатур из области 3gpp стандартов. Возьмем за образец то что мне близко - PCRF. Это такая железка, которая управлет доступом пользователя. Когда пользователь подключается к сети, в ней создается запись о сесси пользователя. Там хранится всевозможная инофрмация и текущее состояние пользователя. Периодически от оборудования в pCRF приходят сообщения. Например, пользователь перешел на другоую базовку или скачал очередные 10 мб. Иногда сам PCRF посылает сигнал оборудованию, что надо, например, поменять доступ пользователю т.к. он нажал турбокнопку или у него кончился оплаченный пакет.

Можно было бы на каждого пользоваетля запускать процесс и в нем все обрабатывать. Но делается несколько по другому. Инофрмация о сессии заносится в какое-либо хранилище и там и лежит. При приходе сообщения вычитывается, обрабатывается и если надо сохраняется. В результате получается, что любой поток может обрабатывать любую сессию. Более того, сервер вообще можно перезапустить и все будет продолжать работать. Более, того состояние можно среплицировать на другой узел кластера и тогда можно вообще гасить сервер.

Количестов потоков делаем равным количеству ядер и получаем уменьшение затрат на переключение потоков.

Можно, конечно, что-то подобное делать на java - но производительность упадет весьма существенно. Да и всякие другие особенности С/C++ позволяют писать более быстродействующие приложения. Например, в телекоме принято не злоупотряблять динамическим выделением памяти. В качестве примера, в нашем приложении за несколько лет не было проблем связанных с утечкой памяти. Единственный случай, когда просто битый пакет полученный по сети привел к закцикливанию и выжирании памяти (там как раз был случай с использованием vector).

Есть уверенность, что они по прежнему широко продолжают юзать эрланг? Или поигрались и бросили?

Так а почему нет?

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

Почему бы не переложить написание стейтмашин на автоматику? Сколько стейтмашин ты сможешь написать руками?

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

Количестов потоков делаем равным количеству ядер и получаем уменьшение затрат на переключение потоков

про green threads в эрланге что-нибудь слышал?

Можно поручить и автомату. Но это стоит денег, и обычно стейтмашин нужно не так и много. У нас их штуки три-четыре вроде. Короче, написать вручную будет бустрее и дешевле с точки зрения затрат. Если бы их было больше, я бы конечно подумал об использовании какого-либо инструмента для автоматизации создания стейтмашины.

Их PCRF не использует их же эрланга. Там используется С++ и java. Для гугления можно использовать строчку «ericsson service-aware policy controller opensaf»

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

Во всех. Альтернатив нет.

Гугление показывает твою правоту. Впрочем, я уже говорил, это выходит как за рамки моей компетенции, так и за рамки моих интересов. А тут на ЛОРе был один регистрант, который пишет на эрланге для телекома (видел его в лиспотредах). К сожалению, не помню ник.

Да, был не прав. Интересно, почему они решили уйти от erlang.

Думаю, что если решение работает на 10000 сессиях оно может не работать на ляме. Т.е. наступил предел масштабирования по потокам. А если потоки не работают то в чем кайф эрланга?

Ну, 10000 далеко не предел.

В качестве примера, в нашем приложении за несколько лет не было проблем связанных с утечкой памяти.

Valgrind юзали?

В результате преимущество эрланга оказывается невостребованным, либо востребованным среди ленивых

Да? Ммм.. А в фейсбуке чат на нем написан

Нет. Просто стараемся не использовать динамическую память. Сейчас есть несколько крупных мест, где используется динамическая память (vector, string). Думаю, как от нее избавиться, но пока это тяжело. Там что-то вроде парсинга бинарного XML (Diameter) c валидацией и поддержкой вложенных структур. Также гоняем нагрузку и стабильность. Т.е. вот прямо сейчас идет 8-й день работы новой версии сервера под нагрузкой в 8 тысяч в секунду. Обработано 4 841 408 819 запросов, в лог записано 9684686618 строчек.

Вот я смотрю эту презентацию - http://www.erlang-factory.com/upload/presentations/31/EugeneLetuchy-ErlangatF... на 13-й странице вижу следующие цифры - 800 000 000+ сообщений в день. 100+ серверов. Охренеть!!! Просто супер производительность! Мы для такой-же нагрузки используем кластер из ДВУХ десктопов. Причем, у нас сообщения это не «привет!», а существенно более сложные. И алгоритмы посложнее. Итого эрланг в 50-100 раз тормознее с/с++.

Да, дурачки. К чему такая избыточность, если можно написать на плюсах и использовать пару машин загруженных на 100%, которые физически никогда не упадут. И еще, гляньте в jabberd на обработку «привет!»-логики.

использовать пару машин загруженных на 100%, которые физически никогда не упадут

предлагаешь везде ставить в 50+ раз больше серверов для надежности?

А если потоки не работают то в чем кайф эрланга?

тов. unfo довольно точно заметил. Я бы ещё добавил сетевую прозрачность между нодами и встроеный маршалинг.

Вот тут ты описал идеальную задачу для эрланга. Все требования и идея, которые ты описал, в эрланге есть из коробки. Кроме того, имхо, всякие syslogd и dbusd и всё остальное ивент бейсейд идеально вписывается в то, что могло бы быть написано на нём за более короткие сроки и работало бы не хуже и стабильнее. Я не говорю, что его надо пихать куда только можно, я о том, что возможности, которые он предоставляет очень часто начинают велосипедить на том же спп. Я даже уверен, что многие фичи, которые есть в твоей pcrf, точно так же навелосипедены. Вот тебе ещё баянистая и знаменитая success story и ещё тред на почитать (он правда 3х годичной давности), если интересно конечно.

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

Вероятно, не такая уж легкая обработка этих чат-запросов. И сама логика чатов падучая при требованиях быстрой разработки. Плюс оверхед на греп по ключевым словам для сотрудников АНБ :)
Лучше рекорды пепякомерки смотреть в приложениях, использующих RabbitMQ.

Покажите мне бенчи этого jaberd и я посмеюсь вместе с вами.. То что я видел, и что тестировала моя жена, выглядело очень плохо. 100 серверов то они сделали не потому, что хотят держать нагрузку в 1%, а потому что иначе не тянет.. Метод такой - выбрать говнотехнолoгию, а потом компенсировать это количеством железа. В телекоме так не получается. Причины следующие:

• Более дорогое железо. В связи с высокими требованием к надежности используется дорогое оборудование с резервными питанием итд. Например, погуглите на слово ATCA.
• Снова требования надежности. Например, у оператора может быть несколько узлов по стране. В каждом узле ставится по комплекту оборудования, чтобы в случае падения межгородских линков все продолжало работать локально. Предложите ставить рядом с каждой корой по 100 серверов? не поймут.
• И еще аспект надежности.. Если в чатике не доставится сообщение - ничего старшного. Если пользователю не будет дан доступ к интернету - уже хуже. Если у него спишутся деньги еще хуже. Т.е. просто цена ошибки и прстоя становится выше.

Вопрос, почему сам эриксон написал эту задачу не на эрланге, а на С/C++ и java ? :)

у vromanov руками накоженные 3-4 стейт-машины на двух десктопах. Даже вектора и то использует с осторожностью. Т.е. он совершенно не экономит размер кода и время разработки, зато результат у него работает в 10 раз быстрее. Звучит справедливо, не?

Да, абсолютно согласен. Я тогда его сообщение не прочитал ещё.

Это кстати одна из фич спп, которую походу никак и ничем не заменить. Оптимизация.

Я не знаю. Я же не эриксон ;) У них спроси.

У меня куча автогенеренного C++ кода, генератор написан на баше :). Есть еще один прием, который тяжело использовать в других языках типа явы. Например, вам надо распарсить заголовок HTTP запроса. В java у вас будет класс, который содержит срочки с КОПИЕЙ того что пришло в запросе. Правильный парсер на С/C++ для каждого поля будет содержать указатель и длинну поля. Указатель будет указывать на месте в буффере, где лежит весь полученный запрос. Тем самым есть возможность не использовтаь динамическую память, не грузить сборщик мусора и не получать утечек! Профит!

А в чем проблема сделать то же самое на яве, вместо указателей - смещение в буфере?

вот так указатели можно использовать в С++:

...
const char* method() const { return method_; }
const char* url() const { return url_; }
...
printf( "Method: %s, URL: %s\n", conn.method(), conn.url() );

покажи аналог на яве

Основная проблема в том, что это «неправильный» для java путь. Большую часть функций придется писать вручную итд. Т.е. и производительности не получишь, а гемора огребешь еще больше. А если так, то зачем java?

method_
url_

Как называется этот способ именования полей класса? Я тоже такой использую.

class Connection {
	public String method() { return method_; }
	public String url() { return url_; }
	private String method_ = "METHOD";
	private String url_ = "URL";
}

public class Main {
	public static void main(String[] args)
	{
		Connection conn = new Connection();
		System.out.printf("Method: %s, URL: %s\n", conn.method(), conn.url());
	}
}

Где подвох?

А в си есть для этого готовые функции?

Как называется этот способ именования полей класса?

без понятия :)

Как называется этот способ именования полей класса?

«Убей меня жестоко».

SIMD, SSE, NEON

Где подвох?

подвох в том, что в случае С++ ты читаешь заголовок запроса целиком - это одна область памяти, а потом, когда парсишь, просто выставляешь значения указателей + расставляешь \0 прямо в буфере, в итоге нет никаких копирований и ненужных выделений/освобождений памяти

в жабе есть подстроки.

нет никаких копирований и ненужных выделений/освобождений памяти

Но есть нетривиальная и не проверяемая компилятором семантика владения.

Но есть нетривиальная и не проверяемая компилятором семантика владения.

идеальных решений на данный момент не существует

Как раз она очень тривиальная и простая - время обработки запроса. Это на самом деле общепринятая модель. Примеры, где делается так - OpenSER, SER (это сип сервера), nginx

В каких областях программирования С++ незаменим?

незаменимых ЯП нет, доказано Аланом Тьюрингом.

C++ _удобен_ например в сложных GUI приложениях. Например Windows, KDE, Gnome. Но таки есть примеры, когда используют и совсем _другой_ ЯП и в этом случае.

unrdered_map асинхронный я писал на с++ для сайта, где требовалось много чтецов держать, которые редко пишут, и синхронизировать их состояние оптом, например раз в секунду. 1 new/delete на синхронизацию приходилось. в жабе нельзя так, чтоб много объектов в один кусок памяти поместить.

С++ незаменим там, где нужна скорость работы, сравнимая с Си, но с гораздо бОльшей эффективностью разработки.

Здравая мысль в этом есть, но если это правда, то зачем нужен C?

вот в теме «танго», складывается ощущение, что твоя аватара обкакалась :-) Это фича?

По теме, C++11 это конечно хорошо, но не всегда оно нужно. Если _тебе_ нужно, то считай так.

А вот и Д'Артаньяны подтянулись у которых на проде сегфолтов никогда не было