Сообщение Re[24]: Почему Эрланг от 15.06.2015 17:23
Изменено 15.06.2015 17:28 Sinclair
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, so5team, Вы писали:
S>>Зависит и от задачи, и от платформы. Озвучьте граничные условия, можно будет пообсуждать.
S>Задача — простая: отдавать контент. 80% запросов — статика (т.е. отдаются с диска), 20% — динамика (т.е. генерируются приложением, которое само по себе большую часть времени спит в ожидании IO от диска или внешнего веб-сервиса).
S>Характерное время подготовки динамического респонса при рендере с нуля — 1600мс. Характерный размер статического респонса — 100кб. Количество одновременных пользователей — 50К. Платформа — пусть будет линукс.
S>>Я не в курсе, как сконвертированный из PHP в C++ код для Web-а запускается в FB. Может за каким-то готовым сервером, может быть поднимался standalone-приложением, открывающим порт для приема HTTP-запросов.
S>Очень сомневаюсь. В PHP нет прмитивов, нужных для разработки standalone-приложения, "открываюшего порт". В какой язык ты его ни конвертируй, ничего интересного не выйдет.
S>>Это просто был пример того, как C++ использовался в нагруженном Web-е.
S>Ну, а пример того, как Erlang используется в нагруженном вебе, мы имеем в лице web.whatsapp.com.
S>>Нет, услуга оказывалась сразу, информация о ней фиксировалась в биллинге с некоторой задержкой.
S>Какое отношение к этому имеет парсинг огромных текстовых файлов?
S>>Парсинг файлов очень похож на парсинг некоторых протоколов, таких как UCP. Динамика одинаково тормозит и на строках из текстовых файлов, так и на PDU-шках из UCP.
S>Вы опасно приближаетесь к фейспалму. Относительные тормоза динамики будут совершенно разными для случая, когда у вас данные приходят по 200 байт раз в секунду, и для случая, когда вы можете линейно сканировать диск мегабайтными блоками. Эрланг, к примеру, не разрабатывался для супербыстрого парсинга текстов в одном потоке.
S>Зато подходы, которые хорошо работают для однопотокового парсинга 100мегабайтного текста, будут гораздо хуже работать для параллельного парсинга 100к запросов по 1кб каждый.
S>>Может вы сначала чем-нибудь докажете, что вы что-нибудь понимаете в real-time?
S>Переход на личности засчитан.
S>>Рассказывайте. Форумные Ыксперты такие Ыксперты... На Erlang-е сами не пишут, замеры используют от 2009-го года, сколько можно поднять нитей на современных ОС и современном железе не в курсе...
S>Переход на личности засчитан.
S>Аргументы будут?
S>>Было бы достаточно, если бы вы привели какие-то замеры, хотя бы от 2013-го или 2014-го года, а не 2009-го.
S>>А то ищешь что-нибудь свежее, а находится что-то вроде https://github.com/jakubkulhan/hit-server-bench
S>Да, там мерится не тот сервер на эрланге.
S>>Ну или https://synrc.com/apps/n2o/
А здесь-то вам что не понравилось? строготипизированный D слил динамике вчистую.
S>Здравствуйте, so5team, Вы писали:
S>>Зависит и от задачи, и от платформы. Озвучьте граничные условия, можно будет пообсуждать.
S>Задача — простая: отдавать контент. 80% запросов — статика (т.е. отдаются с диска), 20% — динамика (т.е. генерируются приложением, которое само по себе большую часть времени спит в ожидании IO от диска или внешнего веб-сервиса).
S>Характерное время подготовки динамического респонса при рендере с нуля — 1600мс. Характерный размер статического респонса — 100кб. Количество одновременных пользователей — 50К. Платформа — пусть будет линукс.
S>>Я не в курсе, как сконвертированный из PHP в C++ код для Web-а запускается в FB. Может за каким-то готовым сервером, может быть поднимался standalone-приложением, открывающим порт для приема HTTP-запросов.
S>Очень сомневаюсь. В PHP нет прмитивов, нужных для разработки standalone-приложения, "открываюшего порт". В какой язык ты его ни конвертируй, ничего интересного не выйдет.
S>>Это просто был пример того, как C++ использовался в нагруженном Web-е.
S>Ну, а пример того, как Erlang используется в нагруженном вебе, мы имеем в лице web.whatsapp.com.
S>>Нет, услуга оказывалась сразу, информация о ней фиксировалась в биллинге с некоторой задержкой.
S>Какое отношение к этому имеет парсинг огромных текстовых файлов?
S>>Парсинг файлов очень похож на парсинг некоторых протоколов, таких как UCP. Динамика одинаково тормозит и на строках из текстовых файлов, так и на PDU-шках из UCP.
S>Вы опасно приближаетесь к фейспалму. Относительные тормоза динамики будут совершенно разными для случая, когда у вас данные приходят по 200 байт раз в секунду, и для случая, когда вы можете линейно сканировать диск мегабайтными блоками. Эрланг, к примеру, не разрабатывался для супербыстрого парсинга текстов в одном потоке.
S>Зато подходы, которые хорошо работают для однопотокового парсинга 100мегабайтного текста, будут гораздо хуже работать для параллельного парсинга 100к запросов по 1кб каждый.
S>>Может вы сначала чем-нибудь докажете, что вы что-нибудь понимаете в real-time?
S>Переход на личности засчитан.
S>>Рассказывайте. Форумные Ыксперты такие Ыксперты... На Erlang-е сами не пишут, замеры используют от 2009-го года, сколько можно поднять нитей на современных ОС и современном железе не в курсе...
S>Переход на личности засчитан.
S>Аргументы будут?
S>>Было бы достаточно, если бы вы привели какие-то замеры, хотя бы от 2013-го или 2014-го года, а не 2009-го.
S>>А то ищешь что-нибудь свежее, а находится что-то вроде https://github.com/jakubkulhan/hit-server-bench
S>Да, там мерится не тот сервер на эрланге.
S>>Ну или https://synrc.com/apps/n2o/
А здесь-то вам что не понравилось? строготипизированный D слил динамике вчистую.
Re[24]: Почему Эрланг
Здравствуйте, Sinclair, Вы писали:
S>>Ну или https://synrc.com/apps/n2o/
А здесь-то вам что не понравилось? строготипизированный D слил динамике вчистую.
S>>Ну или https://synrc.com/apps/n2o/
А здесь-то вам что не понравилось? строготипизированный D слил динамике вчистую.