S>Т.е. не какого-то набора из элементов списка, а всех элементов. Следовательно, ваша картина мира базируется на уверенности, что все элементы вашего списка актуальны для Erlang-а. И эта картина будет разрушена, если это не так.
Все элементы этого списка (возможно, кроме софт-реалтайма, и то — время ответа должно хоть как-то гарантироваться) актуальны для любого приложения/языка, которые претендуют на параллельность и распределенность. В Эрланге это просто поняли раньше всех.
S>2. Где ответ на вполне конкретный вопрос? Знаете -- отвечайте, не знаете -- вычеркивайте данный пункт.
Я пока жду ответов на вопросы от вас. Все, что вы можете предложить, — это «а вот у нас можно создать 100500 потоков, Эрланг не нужен». Только говоришь: «Эрланг — это не только возможность создать 100500 потоков», как вы все скопом дружно сливаетесь в кусты.
Здравствуйте, Ночной Смотрящий, Вы писали:
I>>В нативных тредах у тебя есть колстек. В асинхронном коде его нет ни капли. Что откуда каким путём пришло — ахез.
НС>https://msdn.microsoft.com/en-us/library/dd998369.aspx
Так себе. Win.js применяется чуть менее чем нигде, а бОльшую часть js кода вижла даже дебажить толком не умеет.
JDV>А что еще тогда задачи нужно решать для создания распределенной базы данных? Доступ системным вызовам для работы с файловой системой у Эрланга наверное есть... JDV>Что из стандартной поставки эрланга мне нужно использовать, если я хочу реализовать репликацию машины состояний? Paxos из коробки там есть?
Я перестал понимать людей. Вместо того, чтобы сесть и подумать, что пишет оппонент, они берут один пункт или пример из сообщения и возводят его в абсолют. А потом начинают обсуждать только этот абсолют.
(Без надежды даже на попытку понимания) В стандартной поставке Эрланга есть множество вещей, которые делают создание concurrent и distributed приложений легким и быстрым. Например, супервизоры. Даже если хочется реализовать свой мегагипералгоритм, да тот же Paxos, в 90% случаев для реализации достаточно использовать то, что предлагает стандартная поставка, потому что она предоставляет прекрасные, выверенные практикой базовые блоки. Которых в других языках и библиотеках банально нет, но они там медленно и верно появляются.
M>>Не как-то. И не только передачу. Подавляющее большинство библиотек, как тут уже выяснили, упирается строго в «создать миллион корутин». Остальные библиотеки — это, я так понимаю, Кафка и прочие сотоварищи. Ну-ну. Хорошее «решение».
JDV>Задача «создания миллиона корутин» лишена смысла т.к. это техническая деталь работы отдельной платформы — если в эрланге, чтобы обработать поток из N сообщений, нужно обязатательно создать N эрланговских «процессов», то это не означает, что для решения такой же задачи на другом ЯП нужно также копировать решение на эрланге.
О. Как раз то, о чем говорил. Я пишу: в Эрланге есть не только создание миллиона процессов. О чем предпочитает говорить Joie de vivre? Ах, да. Строго о создании миллиона процессов. /o\
JDV>А Kafka это очередь, которую написали в Linkedin(?) что ли? Если да, то тогда ее нужно сравнивать с Rabbitmq, а не эрлагом.
Это ты не мне говори.
M>>При желании. Можно нписать. В упрощенном виде. Ага-ага. Свежо предание, только нифига не существует. JDV>Различные схемы failover-а люди и без эрланга реализовывают.
На любом Тьюринг-полном языке можно реализовать то, что реализовано на другом Тьюринг-полном языке. И? Простой failover есть в OTP из коробки. Чтобы это реализовать на любом другом языке, тебе надо сначала реализовать половину Эрланга.
S>>Т.е. не какого-то набора из элементов списка, а всех элементов. Следовательно, ваша картина мира базируется на уверенности, что все элементы вашего списка актуальны для Erlang-а. И эта картина будет разрушена, если это не так.
M>Все элементы этого списка (возможно, кроме софт-реалтайма, и то — время ответа должно хоть как-то гарантироваться) актуальны для любого приложения/языка, которые претендуют на параллельность и распределенность. В Эрланге это просто поняли раньше всех.
Тут вот какое дело: два Ыксперта по Erlang-у, вы и neFormal, привели два списка требований и объявили, что все ваши требования должны поддерживаться. Только сразу же обнаруживается казус: рекламируемый вами Erlang сам не выполняет вами же продекларированных требований. В случае с neFormal-ом -- это надежность "в принципе". В случае с вами -- это реал-тайм.
Поневоле задаешься вопросом: а вы вообще чем занимаетесь -- рекламой или антирекламой? Erlang -- это отличный инструмент, в который множество далеко неглупых людей вложили столько труда и времени, зачем же вы их достижения так убого дискредитируете?
S>>2. Где ответ на вполне конкретный вопрос? Знаете -- отвечайте, не знаете -- вычеркивайте данный пункт.
M>Я пока жду ответов на вопросы от вас. Все, что вы можете предложить, — это «а вот у нас можно создать 100500 потоков, Эрланг не нужен». Только говоришь: «Эрланг — это не только возможность создать 100500 потоков», как вы все скопом дружно сливаетесь в кусты.
Вам уже ответили. То, что ответ вас не устраивает и вы повторяете свой вопрос -- это уже, вероятно, ваши личные проблемы. Тем не менее, повторю: те же самые задачи, для которых предназначен Erlang, успешно решали, успешно решают и будут успешно решать, но по-другому. Поэтому приведенные вами и neFormal-ом списки, может и актуальны для Erlang-а, но не являются таковыми для других языков и платформ.
Однако, если вы так настаиваете на своем списке, то раскройте, пожалуйста, тему реал-таймовых гарантий в Erlang/OTP. Если можете, конечно.
А то вам третий раз прямой вопрос задали, а никакого ответа, даже "я не знаю" нет. Судя же по вашей оговорочке "и то — время ответа должно хоть как-то гарантироваться", а "хоть как-то" в разговорах про реал-тайм -- это просто песТня какая-то, вы таки не знаете.
Здравствуйте, so5team, Вы писали:
S>Однако, если вы так настаиваете на своем списке, то раскройте, пожалуйста, тему реал-таймовых гарантий в Erlang/OTP. Если можете, конечно. S>А то вам третий раз прямой вопрос задали, а никакого ответа, даже "я не знаю" нет. Судя же по вашей оговорочке "и то — время ответа должно хоть как-то гарантироваться", а "хоть как-то" в разговорах про реал-тайм -- это просто песТня какая-то, вы таки не знаете.
Мне бы тоже хотелось узнать, как эрланг обеспечивает реалтаймные гарантии, с его fault-tolerance искаропки.
Как это все вписывается в CAP-теорему Брюера. Fault-tolerance дает P, стало быть приходится выбирать между C и A. Consistency как бы нужно , тогда на Availability можно забить.
Пудозреваю, ответ в архитектуре эрланга и конкретного приложения. Мамут аки мальчиш-кибальчиш, не выдаёт военную тайну.
Здравствуйте, Ikemefula, Вы писали:
I>Мне бы тоже хотелось узнать, как эрланг обеспечивает реалтаймные гарантии, с его fault-tolerance искаропки.
Выше уже кто-то, вроде бы Wolfhound уже поднимал тему производительности selective receive. Если receive не дает никаких временных гарантий, то про реал-тайм вообще можно забыть. Но и кроме receive важен вопрос количества поддерживаемых VM приоритетов для процессов и способы защиты от priority inversion. И как это все сочетается с необходимостью использовать C-шные NIF-ы или даже драйвера, когда производительности pure-Erlang кода не хватает.
Здравствуйте, so5team, Вы писали: S>Отлично, продолжайте строить свои выводы на результатах пятилетней давности.
Я и не переставал.
S>>Отлично. Покажите мне высокопроизводительный веб-сервер на C++, и мы поговорим об этом. S>При чем здесь пример веб-сервера на C++?
Ну, а на чём вы предлагаете писать веб-сервер?
S>Поскольку от темы веб-серверов я сам довольно далек, единственное, что вспоминается про веб-сервера на C++ -- это Google-овские сервера, а так же работы в Facebook по переводу PHP-шного кода на C++ные рельсы (как в виде более производительной PHP VM на C++, так и в виде трансляции PHP кода в C++).
На всякий случай: PHP — это не веб-сервер. Теоретически, сейчас можно написать весь веб-сервер самостоятельно с нуля. На практике сейчас это мало кто делает. При наличии на рынке Apache, IIS, nginx, и lighttpd. Пишут свои веб-приложения, которые крутятся в рамках какого-то сервера.
В PHP, к примеру, ничего про HTTP-сервер нету. Не больше, чем, скажем, в JavaScript.
S>Чтобы бросаться фразами вроде "риторический вопрос" неплохо было бы сначала научиться отличать роутинг от роуминга.
Опечатка. S>Ключевое слово мной было упомянуто: биллинг. Имеющий непосредственное отношение к роутингу. Настолько непосредственное, что роутинг без биллинга просто никому не нужен.
И всё же: какое место в роутинге GSM занимает парсинг CDR-файлов? У вас же он занимал 24 часа. Неужели клиенты вашего сервиса набирали телефонный номер, а потом 24 часа ждали, пока пакет данных найдёт своего абонента?
S>Очевидно, что мы не делали софт для такого же телефонного свитча, какой выпустил давным давно Ericsson.
Да, это заметно.
S>У нас был свой софт для роутинга, который решал свой спектр задач. И результаты я вам привел из нашего собственного опыта.
Задача, которую вы привели, не имеет никакого отношения к real-time routing. Вы мне рассказывате про непригодность динамических языков к разработке высоконагруженных коммуникационных серверов на примере задачи низкоприоритетного data crunching. И то, я подозреваю, что тормоза в руби были не в руби — парсинг текстовых файлов на более-менее любом современном языке упирается в скорость чтения с диска.
S>Кроме того, информация из категории "был вот такой телекомовский софт на технологии X, его полностью переписали на технологии Y и получили выигрыш в N процентов" попадается на глаза очень и очень редко. Потому что в серьезных задачах объемы таковы, что big rewriting инициируется очень редко, и еще реже он завершается удачно.
Это правда. Поэтому, скажем, HTTP-сервер — это редкий случай, когда в забеге участвует более 1 платформы.
S>Как вы там говорите: "Если вам они не нравятся, то это ваша задача аргументировать своё недоверие — желательно при помощи каких-то более других результатов." S>Вам привели результаты одного из самых известных бенчмарков для Web-фреймворков последних лет. Вам не нравится, вы не находите там Erlang-а -- ваши проблемы
И тем не менее, из отсутствия там эрланга глупо делать какие-либо выводы о производительности эрланга.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S>Выше уже кто-то, вроде бы Wolfhound уже поднимал тему производительности selective receive. Если receive не дает никаких временных гарантий, то про реал-тайм вообще можно забыть. Но и кроме receive важен вопрос количества поддерживаемых VM приоритетов для процессов и способы защиты от priority inversion. И как это все сочетается с необходимостью использовать C-шные NIF-ы или даже драйвера, когда производительности pure-Erlang кода не хватает.
Простите, а что вы все к real-time'у в контексте Эрланга привязались. real-time -- это ограничение на io сверху. Их венда
и линупс дать не могут, какой уж тут Эрланг.
Здравствуйте, Sinclair, Вы писали:
S>>>Отлично. Покажите мне высокопроизводительный веб-сервер на C++, и мы поговорим об этом. S>>При чем здесь пример веб-сервера на C++? S>Ну, а на чём вы предлагаете писать веб-сервер?
Зависит и от задачи, и от платформы. Озвучьте граничные условия, можно будет пообсуждать.
S>На всякий случай: PHP — это не веб-сервер. Теоретически, сейчас можно написать весь веб-сервер самостоятельно с нуля. На практике сейчас это мало кто делает. При наличии на рынке Apache, IIS, nginx, и lighttpd. Пишут свои веб-приложения, которые крутятся в рамках какого-то сервера. S>В PHP, к примеру, ничего про HTTP-сервер нету. Не больше, чем, скажем, в JavaScript.
Я не в курсе, как сконвертированный из PHP в C++ код для Web-а запускается в FB. Может за каким-то готовым сервером, может быть поднимался standalone-приложением, открывающим порт для приема HTTP-запросов. Это просто был пример того, как C++ использовался в нагруженном Web-е.
S>>Ключевое слово мной было упомянуто: биллинг. Имеющий непосредственное отношение к роутингу. Настолько непосредственное, что роутинг без биллинга просто никому не нужен. S>И всё же: какое место в роутинге GSM занимает парсинг CDR-файлов? У вас же он занимал 24 часа. Неужели клиенты вашего сервиса набирали телефонный номер, а потом 24 часа ждали, пока пакет данных найдёт своего абонента?
Нет, услуга оказывалась сразу, информация о ней фиксировалась в биллинге с некоторой задержкой.
Парсинг файлов очень похож на парсинг некоторых протоколов, таких как UCP. Динамика одинаково тормозит и на строках из текстовых файлов, так и на PDU-шках из UCP.
S>Задача, которую вы привели, не имеет никакого отношения к real-time routing.
Может вы сначала чем-нибудь докажете, что вы что-нибудь понимаете в real-time? А то в теме уже есть один Ыксперт по софт реал-тайму. Не хотелось бы иметь дело с еще одним.
S> И то, я подозреваю, что тормоза в руби были не в руби — парсинг текстовых файлов на более-менее любом современном языке упирается в скорость чтения с диска.
Не, не в Ruby. Рассказывайте еще. И про скорость чтения диска, и про обработку прочитанной информации, и про взаимодействие с БД. Рассказывайте. Форумные Ыксперты такие Ыксперты... На Erlang-е сами не пишут, замеры используют от 2009-го года, сколько можно поднять нитей на современных ОС и современном железе не в курсе...
S>И тем не менее, из отсутствия там эрланга глупо делать какие-либо выводы о производительности эрланга.
-- это один из пунктов, удовлетворение которого требует Mamut:
Properties of the Erlang system
— Lightweight, massive concurrency
— Asynchronous communication
— Process isolation
— Error handling
— Continuous evolution of the system
— Soft real-time
Собственно, хочется выяснить, за счет чего этот пункт удовлетворяется в Erlang-е.
Ну и, если он таки удовлетворяется, почему Mamut считает, что этот пункт в других платформах в зачаточном состоянии.
Здравствуйте, so5team, Вы писали:
S>Зависит и от задачи, и от платформы. Озвучьте граничные условия, можно будет пообсуждать.
Задача — простая: отдавать контент. 80% запросов — статика (т.е. отдаются с диска), 20% — динамика (т.е. генерируются приложением, которое само по себе большую часть времени спит в ожидании IO от диска или внешнего веб-сервиса).
Характерное время подготовки динамического респонса при рендере с нуля — 1600мс. Характерный размер статического респонса — 100кб. Количество одновременных пользователей — 50К. Платформа — пусть будет линукс.
S>Я не в курсе, как сконвертированный из PHP в C++ код для Web-а запускается в FB. Может за каким-то готовым сервером, может быть поднимался standalone-приложением, открывающим порт для приема HTTP-запросов.
Очень сомневаюсь. В PHP нет прмитивов, нужных для разработки standalone-приложения, "открываюшего порт". В какой язык ты его ни конвертируй, ничего интересного не выйдет. S>Это просто был пример того, как C++ использовался в нагруженном Web-е.
Ну, а пример того, как Erlang используется в нагруженном вебе, мы имеем в лице web.whatsapp.com.
S>Нет, услуга оказывалась сразу, информация о ней фиксировалась в биллинге с некоторой задержкой.
Какое отношение к этому имеет парсинг огромных текстовых файлов? S>Парсинг файлов очень похож на парсинг некоторых протоколов, таких как UCP. Динамика одинаково тормозит и на строках из текстовых файлов, так и на PDU-шках из UCP.
Вы опасно приближаетесь к фейспалму. Относительные тормоза динамики будут совершенно разными для случая, когда у вас данные приходят по 200 байт раз в секунду, и для случая, когда вы можете линейно сканировать диск мегабайтными блоками. Эрланг, к примеру, не разрабатывался для супербыстрого парсинга текстов в одном потоке.
Зато подходы, которые хорошо работают для однопотокового парсинга 100мегабайтного текста, будут гораздо хуже работать для параллельного парсинга 100к запросов по 1кб каждый.
S>Может вы сначала чем-нибудь докажете, что вы что-нибудь понимаете в real-time?
Переход на личности засчитан. S>Рассказывайте. Форумные Ыксперты такие Ыксперты... На Erlang-е сами не пишут, замеры используют от 2009-го года, сколько можно поднять нитей на современных ОС и современном железе не в курсе...
Переход на личности засчитан.
Аргументы будут?
S>Было бы достаточно, если бы вы привели какие-то замеры, хотя бы от 2013-го или 2014-го года, а не 2009-го. S>А то ищешь что-нибудь свежее, а находится что-то вроде https://github.com/jakubkulhan/hit-server-bench
Да, там мерится не тот сервер на эрланге. S>Ну или https://synrc.com/apps/n2o/
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали: S>>Ну или https://synrc.com/apps/n2o/
А здесь-то вам что не понравилось? строготипизированный D слил динамике вчистую.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>>Зависит и от задачи, и от платформы. Озвучьте граничные условия, можно будет пообсуждать. S>Задача — простая: отдавать контент. 80% запросов — статика (т.е. отдаются с диска), 20% — динамика (т.е. генерируются приложением, которое само по себе большую часть времени спит в ожидании IO от диска или внешнего веб-сервиса). S>Характерное время подготовки динамического респонса при рендере с нуля — 1600мс. Характерный размер статического респонса — 100кб. Количество одновременных пользователей — 50К. Платформа — пусть будет линукс.
И все это на raspberry pi?
Собственно, поскольку тут явно не подразумевается использование встраиваемых устройств с ограниченными ресурсами, то я пас в выборе программной платформы для такой задачи. Никогда такими вещами не занимался.
S>>Это просто был пример того, как C++ использовался в нагруженном Web-е. S>Ну, а пример того, как Erlang используется в нагруженном вебе, мы имеем в лице web.whatsapp.com.
И? Я разве отрицал возможность использования Erlang-а в Web?
Вопрос был всего лишь в актуальных сравнениях, коих вы привести не можете.
S>>Нет, услуга оказывалась сразу, информация о ней фиксировалась в биллинге с некоторой задержкой. S>Какое отношение к этому имеет парсинг огромных текстовых файлов?
Вам, походу, не понять.
S>Вы опасно приближаетесь к фейспалму. Относительные тормоза динамики будут совершенно разными для случая, когда у вас данные приходят по 200 байт раз в секунду, и для случая, когда вы можете линейно сканировать диск мегабайтными блоками.
Кто вам сказал, что данные приходят по 200 байт раз в секунду? Или у вас опять информация из 2009-го года?
S>>Может вы сначала чем-нибудь докажете, что вы что-нибудь понимаете в real-time? S>Переход на личности засчитан.
Это вы употребили термин real-time, за язык вас никто не тянул. Будьте любезны, покажите, что имеете представление о том, о чем говорите.
S>Да, там мерится не тот сервер на эрланге.
Ну так покажите тот. А то вы кроме yaws ничего и не знаете.
Здравствуйте, Joie de vivre, Вы писали:
JDV>Мне интересно как решит эрланг задачи вроде стандартной (в распределенном системе) схемы лидер + последователи, когда один процесс принимает от клиентов команды и реплицирует их на остальные машины, падение лидера должно запустить процесс выбора нового лидера, который потом также начнет принимать команды и т.д. и т.п. JDV>Куда мне смотреть если я такое хочу реализовать на эрланге?
из коробки нет. есть разные библиотеки типа gen_leader.
Здравствуйте, so5team, Вы писали:
S>И все это на raspberry pi?
Не обязательно. Но желательно, чтобы ваше решение не отжирало 7GB RAM только под initial stack commit.
S>Собственно, поскольку тут явно не подразумевается использование встраиваемых устройств с ограниченными ресурсами, то я пас в выборе программной платформы для такой задачи. Никогда такими вещами не занимался.
Подразумевается использование рэковых серверов с ограниченными ресурсами. Но вы, похоже, просто вообще не понимаете, как устроен современный высокопроизводительный сетевой сервер, и в чём тут специфика задачи.
Заметьте, я не говорю, что парсинг больших файлов — это какой-то низкий жанр. В 2009 году народ даже диссертации защищал на парсинге XML при помощи всяких MMX и прочих SSE
Там выжимались такты, не то что "компилятор vs интерпретатор". Очень интересная штука, чо. Вот только опять же — большого выигрыша для разбора тысяч мелких файлов это не даёт.
S>Кто вам сказал, что данные приходят по 200 байт раз в секунду? Или у вас опять информация из 2009-го года?
Это типичная ситуация для тех задач, под которые проектировался Эрланг. И, например, для современных высоконагруженных веб-приложений. Ну, в смысле, что могут и не по 200, а по 1200 байт. Но принципа это не меняет — нету у вас роскоши накормить CPU одной простой задачей на триллион тактов. У вас много мелких задач по сотне тысяч тактов. А между зависимыми задачами — дооолгое ожидание. Которое нужно суметь использовать с умом.
S>Ну так покажите тот. А то вы кроме yaws ничего и не знаете.
Я тот показал. Но вы полагаете, что nginx за пять лет ускорился в разы, а yaws на это неспособен. Что ж, ваше право заблуждаться у вас никто не отнимет.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, so5team, Вы писали:
S>Вам уже ответили. То, что ответ вас не устраивает и вы повторяете свой вопрос -- это уже, вероятно, ваши личные проблемы. Тем не менее, повторю: те же самые задачи, для которых предназначен Erlang, успешно решали, успешно решают и будут успешно решать, но по-другому.
с куда как большими затратами времени, сил и денег.
но, конечно, если у тебя в руках молоток, то всё вокруг выглядит, как гвозди.
Здравствуйте, netch80, Вы писали:
V>>Про это тоже идут споры не один десяток лет. TCP для HTTP — это для 99% сценариев из пушки по воробьям. Давно уже высказывались мысли, что для HTTP больше подойдет message-oriented протокол, но, в отличие от UDP, чтобы гарантировалась доставка. N>Если бы это было серьёзной проблемой, давно бы в винде встроили SCTP из коробки.
Здравствуйте, so5team, Вы писали:
S>Здравствуйте, Sinclair, Вы писали:
S>>>Зависит и от задачи, и от платформы. Озвучьте граничные условия, можно будет пообсуждать. S>>Задача — простая: отдавать контент. 80% запросов — статика (т.е. отдаются с диска), 20% — динамика (т.е. генерируются приложением, которое само по себе большую часть времени спит в ожидании IO от диска или внешнего веб-сервиса). S>>Характерное время подготовки динамического респонса при рендере с нуля — 1600мс. Характерный размер статического респонса — 100кб. Количество одновременных пользователей — 50К. Платформа — пусть будет линукс.
S>И все это на raspberry pi?
Главное в споре что? Правильно. Наугад давать разнообразные все более идиотские ограничения оппоненту, полностью игнорируя его, оппонента, доводы.
С какого перепугу в споре вдруг появился Raspberry Pi? А потому что некому so5team так ВНЕЗАПНО захотелось. Ведь каких-либо внятных аргументов у него нет. От слова вообще.
