В блоге разработчиков системы микроблогов Twitter опубликован (http://engineering.twitter.com/2012/11/bolstering-our-infras...) отчёт о том, как сервису удалось справиться со шквалом публикации сообщений во время проведения выборов президента США. В день выборов интенсивность публикации достигала 327 452 твитов в минуту, а пиковое значение составило 15 107 твитов в секунду. Для того чтобы обеспечить непрерывную работу сервиса при подобной нагрузке разработчики предприняли ряд мер, в том числе связанных с заменой критичных к производительности компонентов инфраструктуры с изначальной используемой реализации на языке Ruby на варианты, переписанные на языке Java.
В качестве основной причины перехода на Jаva называется излишне высокая нагрузка на CPU при выполнении интерпретатора Ruby, вызванная в основном особенностями работы сборщика мусора. Для решения данной проблемы в недрах Twitter ведётся (http://engineering.twitter.com/2011/03/building-faster-ruby-...) разработка собственного сборщика мусора для Ruby - Kiji и проводится оптимизация runtime-компонентов, но несмотря на это начались действия по постепенному переходу с Ruby на Java. В настоящее время стеком на базе JVM уже обслуживаются запросы мобильных клиентов.Одновременно можно отметить информацию, опубликованную (http://www.theregister.co.uk/2012/11/09/facebook_open_source.../) социальной сетью Facebook. За день Facebook приходится сохранять пол петабайта данных, за год хранилище увеличивается примерно на 180 петабайт. Для поддержания хранилища такого размера в Facebook используется (https://www.facebook.com/notes/facebook-engineering/under-th...) модифицированная версия открытой платформы для распределённой обработки данных Apache Hadoop, развиваемая под именем Hadoop Corona. Реализация от Facebook отличается переработанным механизмом Map-Reduce, оптимизированным для одновременного отслеживания большего числа задач, повышения масштабируемости и уменьшения задержек. Отныне Hadoop Corona вышел за рамках внутренней разработки Facebook и доступен всем желающим. Код проекта опубликован (https://github.com/facebook/hadoop-20/tree/master/src/contri...) на GitHub.
URL: http://engineering.twitter.com/2012/11/bolstering-our-infras...
Новость: https://www.opennet.ru/opennews/art.shtml?num=35277
Что только не придумают лишь бы не писать на нормальном компилируемом языке.
Впрочем, пусть развлекаются.
А зачем им компилятор? у них нет сложных задач для CPU по большому счёту (нет расчётов нет преобразований которые бы делались не оптимизированными библиотеками), им нужна масштабируемость по данным и по потокам, а так же независимость от аппаратной составляющей (завтра вдруг у АМД выхорит с x86+ARM? или ещё у когото...)
ты чо думаешь ты умнее инженеров твиттера? я сомневаюсь...
А я не сомниваюсь, что он так думает.
> ты чо думаешь ты умнее инженеров твиттера?вообще-то человек соглашается с их решением, а не критикует и предлагает что-то иное
Согласен полностью. Java отличный выбор для проектов такого масштаба. Вообще, новость о том что они начали уходить от Ruby проскакивала уже давно — http://readwrite.com/2011/04/11/twitter-drops-ruby-for-javaПросто в Twitter'е правильно выбирают инструменты. Ruby хорош на старте. А по мере роста потребностей переходят к более производительным платформам.
поддерживаю, в таких высоко нагруженных проектах нужно уходить на jvm. Ну уних там clojure в storm есть.
> завтра вдруг у АМД выхорит с x86+ARM... то под неё из воздуха тут же материализуется jvm? вряд ли
На "нормальном копилируемом языке" они бы тоже самое писали лет 20, а еще лет 10 потом это отлаживали.
> На "нормальном копилируемом языке" они бы тоже самое писали лет 20За 20 лет целый Linux отбабахали. Вы такую монстряку и на яве будете писать не меньше. А потом еще полвека в профайлере упираться - скорость повышать до минимально приемлимой.
Вы не находите, что Twitter и Linux — это «немного» разные вещи?
> Вы не находите, что Twitter и Linux — это «немного» разные вещи?По масштабу проекта и сложности - пингвин сделает любого твиттера раз в 100500.
> За 20 лет целый Linux отбабахали.Дырка на дырке, кривизна на кривизне.
> скорость повышать до минимально приемлимой.
Вы идиот. Они JVM используют не для вычислений, а для организации данных.
>> За 20 лет целый Linux отбабахали.
> Дырка на дырке, кривизна на кривизне.Ну вы же на вашей яве лучше почему-то не написали. Кстати в каждом апдейте явы почему-то фиксят столько дырок что на пятерых линуксов хватит. WTF? :)
:-)
Java компилируется в байткод.
Байткод компилируется в нативный код.
Перед компиляцией происходит анализ конкретного оборудования и конкретного приложения.HotSpot сейчас компилит всё быстрым компилятором, а когда обнаруживаются места, которые требуют оптимизацию, то происходит их перекомпиляция сложным компилятором. Сложный компилятор генерирует код на уровне GCC -O3 или лучше.
Какой "нормальный язык" позволяет реализовать подобное ??
>Java компилируется в байткод. Байткод компилируется в нативный код. Перед компиляцией >происходит анализ конкретного оборудования и конкретного приложения. HotSpot сейчас >компилит всё быстрым компилятором, а когда обнаруживаются места, которые требуют >оптимизацию, то происходит их перекомпиляция сложным компилятором. Сложный компилятор >генерирует код на уровне GCC -O3 или лучше. Какой "нормальный язык" позволяет реализовать >подобное ??Не ну это то все понятно, непонятно как-раз почему "нормальный язык" все равно быстрее.
>> переписанные на языке Java.у них там кажеться scala использовалась
суть JVM, а на чес писать без разницы
если быть точным - не всегда так
например груви в 50-500 раз медленее
уже нет
http://objectscape.blogspot.de/2012/08/groovy-20-performance...
ага, Twitter был первым кто начал использовать Скалу в продакшне (если я правильно помню книгу Одерского)
Почему-то мне трудно переход с Ruby на Java удачным решением или хотя бы приемлемым.
Расскажите нам, какое же решение по-вашему удачное? С или ASM?
вы сами ответили на свой вопрос.
И никакой это не Golden Hammer.
> И никакой это не Golden Hammer.Golden, не golden, а что-то кодеки никто на яве не пишет. Си и куски SIMD асма. Вот там да, за скорость рубятся. Потому что в отличие от твиттеров для пользователя аргумент вида "ой, докупите еще серверов, нам влом оптимизировать" как-то не очень катит :)
Пора вылезать из танка. Кодеки сейчас пишут уже даже на JavaScript.
> Кодеки сейчас пишут уже даже на JavaScript.И где это барахло применяется? Ах, чисто академический интерес - показать что в принципе и на нем что-то такое можно накорябать? Ну да, чисто теоретически и на брейнфаке можно, не то что на JS. С точки зрения теории все ЯП равноправны. С точки зрения практики - что-то желающих использовать тормозилово на JS именуемое кодеком что-то не густо пока.
Академический интерес - это зачатие вас. А эта кодовая база начнет активно применяться в следующей пятилетке. И проблема тут не в выборе языка, а в том, что JIT JS уже достаточно для подобных применений.
> а что-то кодеки никто на яве не пишет.А разработчики твиттера кодеки чтоли пишут? Или вы на самом деле не видите разницы? Откуда ж вас столько, упоротых?
>Откуда ж вас столько, упоротых+1
Единственная цель существования кодеков - экономить ресурсы, сжимая контент. Кодек обязан быть производительным, причем более производительным и жмущим, чем предшественники, иначе в нем просто нет смысла.
А кроме кодеков как бы есть еще прикладные программы, делающие сами по себе что-то полезное. Медленная, но написанная до конца прикладная программа гораздо полезнее быстрой, но ничего не умеющей
Common Lisp
SBCL выдает производительность одного порядка с сишной
только если писать уродливый ассемблерообразный код
Ну так. Суровая оптимизация редко делает код красивее и яснее
> Расскажите нам, какое же решение по-вашему удачное? С или ASM?Erlang/OTP ]:->
Трудно потому как есть JRuby, которая в отличии от MRI и REE позволяет решить проблему утилизации всех ядер. Если что, даже Java код можно интегрировать. Теперь особенно странно выглядит то, как программисты твиттера зачем-то развивали сильно отстающую ветку Ruby внося не принципиальный для них изменения. Все это человеко-время можно было спокойно потратить на помощь проекту JRuby.
То есть Ruby слили как тормоза?
Да.
> Да.Рапидная разработка как есть:
0) Быстро налабать на коленке хрень.
1) Забить на архитектуру, дебаг, оптимизацию, профайлинг и прочую ненyжную фигню.
2) Безбашенно вывалить хрень в продакшн, ибо в ж...е свистит ветер.
3) По возмущенным воплям хомячков оставшихся без сервиса осознать что получилась хрень.
4) РеFUCKторинг в надежде что если достаточно посластить какашку то получится шоколад.
5) Оознать что опять получилась какая-то хрень.
6) goto 4.
6) Когда крутиться в цикле 4-6 окончательно задолбало, выкатить то что получилось в виде как есть в продакшн.
7) Осознать что с перфомансом опять Ж и хомячки отщипывают по кусочку, угрожая оставить от авторов хрени лишь обглоданные скелеты.
8) Экстренно докупить серверов чтобы затея не накрылась медным тазом совсем.
9) Понять что не очень помогает, уходит вагон бабла во все щели и по мере роста хомячков все-равно все начинает загибаться.
10) Осознать что архитектура - УГ, но поскольку все уже работает и стадо хомячков уже постит - рыпаться поздно, ибо при любом крупном факапе хомячки разбегутся во все стороны.
11) Попытаться игнорировать проблему.
12) Осознать что хомячки таки обглодают до скелета отщипывая по кусочку.
13) Плюнуть на все и скрипя зубами переписать заново на другом ЯП.
14) To be continued.
Ну да, так и есть. Это же не Open Source и не «Just For Fun». Обычная коммерческая разработка — требуется ровно такое качество, которое устроит пользователей, а они обычно неслишком привередливые. Вообще заметил интересный момент — многие знакомые (далекие от IT), увидев сайт в дауне, вообще думают что это у них самих «инет сломался». У Твиттера довольно часто случаются глобальные (и не очень) факапы. И ничего — пользователи вроде никуда не уходят.
Вот именно. Но людям понятие "коммерчески оправданно" незнакомо, судя по всему. И то, как запускается социальный стартап - тоже. Объясняю. На начальном этапе непонятно, взлетит или нет, поэтому затраты должны быть минимизированы. Запускается едва рабочий прототип. Если интерес есть - начинается раскрутка. Основные затраты идут на неё, на разработку - ровно столько чтобы поддреживалась работа системы на минимально приемлемом уровне. Задача - набрать критическую массу пользователей. И только когда она набрана, когда появляются конкуренты-подражатели, возникает необходиомсть хоть как-то "держать марку". И это не со зла - эта стратегия просто минимизирует шанс прогореть, выпустившись слишком поздно или отдав своих клиентов клону (который разрабатывать всегда проще и быстрее).
Людям надо во что-то верить. Некоторые верят в инопланетян, а некоторые в то, что их любимый язык самый лучший, потому что программы на нем самые быстрые, и неважно, насколько эти программы выполняют свои функции, удобны, безглючны, гибки и легки в поддержке
Про "переписывание" в оригинале ни слова. Сказано только про использование JVM.
Теперь на заявления типа "Ява - Тормоз!", можно смело писать "А твой <язык> сможет обсчитать 15 107 твитов в секунду?!" =))
На 15 107 параллельно работающих серверах с 16 ГБ памяти на каждом? Мммм... дайте подумать... думаю сможет :)
Ну так сделай, если реально можешь.
> Ну так сделай, если реально можешь.У опсосов центры обработки СМСок которые тоже по 140 символов их миллиардами ворочают, и ничо, живые.
Что характерно - обычно как раз на яве и писаные.
Не-не."А сможешь ли ты поддерживать систему, которая может обсчитать 15 107 твитов в секунду на твоем <языке> ?!"
> Не-не.
> "А сможешь ли ты поддерживать систему, которая может обсчитать 15 107 твитов
> в секунду на твоем <языке> ?!"Ещё круче: а создай систему, которая будет обсчитывать... :)
И чего вы "обсчитываете" в тупых 140-символьных сообщениях?
> И чего вы "обсчитываете" в тупых 140-символьных сообщениях?вероятно, гэбистские фильтры на ключевые слова и семантический анализ сообщений (в поисках скрытого смысла :) )
> И чего вы "обсчитываете" в тупых 140-символьных сообщениях?i++ :)
Сохранить, проиндексировать, распарсить на наличие тегов/урлов, сделать ссылки кликабельными.
А ещё отправить обновление всем фолловерам (а их могут быть миллионы).
> Не-не.
> "А сможешь ли ты поддерживать систему, которая может обсчитать 15 107 твитов
> в секунду на твоем <языке> ?!"Не смогу. Ибо она не нужна.
Си, конечно, сможет. И при этом на значительно более слабом железе.
Я бы порекомендовал ASM. В любом случае человек умеет оптимизировать код лучше, чем какой-то тупой компилятор!
> чем какой-то тупой компилятор!Когда как. У компилятора все шансы уделать человека например на глобальной оптимизации распределения регистров. Вы задолбаетесь анализировать мег кода на предмет как он юзает регистры и оптимизить это. А компилеру пофиг - он железный. По поводу чего асм имеет смысл в спецслучаях типа ранней инициализации железа и вставок в наиболее критичных местах кода, как в кодеках. Да, если адресно раскидать SIMD регистры в куске кода на полкило и там наибоелее горячий цикл, кодек может выиграть по скорости в разы. Кстати при том объеме бабла которое твиттерообразные тратят на сервера - оптимизация не является маразмом. Ну по крайней мере фэйсбук транслятор пыха в си++ накатали. Наверное потому что так работает быстрее, да? :)
> У компилятора все шансы уделать человека например на глобальной оптимизации распределения регистров. Вы задолбаетесь анализировать мег кода на предмет как он юзает регистры и оптимизить это
> асм имеет смысл в спецслучаях типа ... вставок в наиболее КРИТИЧНЫХ местах кода, как в кодеках.Взаимоисключающие параграфы
> Взаимоисключающие параграфыНа первый взгляд - да. Но на самом деле человек может сильно уделать компилятор локально, но глобально он проигрывает если кода много, просто не осилив уместить мег кода в свою голову и полностью проанализировать все возможности оптимизации.
Упомянутый подход позволяет сочетать лучшее из обоих подходов. Возможность оного основана на том что можно немного пожертвовать оптимальностью в не сильно горячих местах в пользу оптимальности горячих мест по максимуму. Лишние 2 обращения в регистры в куске кода который выполняется раз в час никто не заметит. Час плюс-минус пол-микросекунды остается для человека часом. А вот лишние 2 обращения в регистры в добавок к всего 2 обращением которые были в цикле - посадят скорость тугого цикла в 2 раза. И человеки очень даже заметят если вместо часа который раньше выполнялся цикл вдруг станет 2 часа.
> Я бы порекомендовал ASM.Это надо говорить с житрожопым выражением лица, иначе люди не поймут.
сишка вполне могла бы взлететь. Видно у твитера просто недобор высококвалифицированных кадров - решили, что лучше купить сотню-другую серверов, чем платить десятку-другому инженеров.
Хм, покажите что-то большое-вебовское, писанное на сишечке. Самое близкое, что приходит в голову - фейсбук, осиливший нанять Александреску и сделавший свой компилятор PHP. Но чтобы на сях саму бизнес-логику писали - и не припомню. А поскольку не верится, чо все поголовно дураки - значит чем-то это не оптимально...
Так а факебук тебя почему не строил?
> PHP. Но чтобы на сях саму бизнес-логику писали - и не припомню.А если поискать немного - окажется что всяких там шаблонизаторов и прочая на си++ есть.
> <язык> сможет обсчитать 15 107 твитов в секунду?!" =))Пардон, а что их там "обсчитывать"? Это ж тупые короткие сообщения. Счет то где?
Диспетчеризация (кому должно прилететь), обработка хэштегов, упоминнаий юзеров на таких количествахв релаьном времени становятся делом... интересным, скажем так. Причём там дело не в объёмах сообщений, а больше в количестве действий, которые нужно на каждое сделать
У меня одного вопрос почему опубликовали на GitHub, а не отдали в Apache???По идее всем (и FB) выгоднее смержиться с основной веткой. Или я не прав? ;)
> Apache???Наверное потому что туда проприетарщики обычно сливают всякую дохлятину. Этакий могильник для отработанного ядерного топлива.
>> Apache???
> Наверное потому что туда проприетарщики обычно сливают всякую дохлятину. Этакий могильник
> для отработанного ядерного топлива.так FB через Apache и получил Hadoop. Значит могилки то свежие, а если некромант опытный, то и оживить получится ;)))
> если некромант опытный, то и оживить получится ;)))Видимо у них мало опыта в некромансии и поэтому они предпочли нечто более живое :)
шило на мыло)
Где по ссылке хоть одно слово про язык java?
дауж! автор новости (переводчик на русский язык) -- явно выдаёт действительное за Желаемое....ни один трезвый человек, писавший ранее код на Ruby (или Python) -- уже больше никогда не сможет что-то писать на Java :-)... он уже исколечен -- неизлечимо!
Scala (или Groovy) -- вполне возможно, ещё.. но точно не Java :-D
> уже исколечен -- неизлечимо!^^^^^^^^^^^ Натурально.
>Для того чтобы обеспечить непрерывную работу сервиса при подобной нагрузке
>разработчики предприняли ряд мер, в том числе связанных с заменой критичных к
>производительности компонентов инфраструктуры с изначальной используемой
>реализации на языке Ruby на варианты, переписанные на языке Java.Быстро однако на явку переписали... меньше чем за час полагаю:)
Этак до них через пару лет допрет что можно еще раза в 3 быстрее сделать, если на плюсы переписать :). Ну вон до фэйсбука дошло =)
> Этак до них через пару лет допрет что можно еще раза в
> 3 быстрее сделать, если на плюсы переписать :). Ну вон до
> фэйсбука дошло =)Дошло и они сделали эпический костыль. Написали транслятор пхп-скриптов в плюсы, что уже изврат. Так оно ещё и далеко не совместимо с обычным пхп. Не слышал, чтобы кто-то им пользовался кроме создателей.
В проектах таких масштабов поголовно какая-нибудь своя экзотика, которая никому больше не нужна. Ибо за счёт величины окупается. А что до костыля - судя по всему, осознали, что PHP обойтись не удастся, слишком поздно - слишком резко пользовательская база выросла. А потом оказалось дешевле костылить, чем рисковать, что какие-то другие скрипты окажутся несовместимыми и наделают проблем. А вот в плюсы для Александреску оттранслировать не слишком большая сложность. Что до несовместимости - на высоких нагрузках и больших проектах всё равно разные eval не используются, медленные они и чреватые.
> Дошло и они сделали эпический костыль. Написали транслятор пхп-скриптов в плюсы, что уже изврат.Ну, когда тебе придется за свое бабло покупать в 3 раза больше серверов - ты еще и не так раскорячишься :)
чтото я не увидел в оригинале чтоб разговор был про жабу. а только лишь про jvm.
Они вроде на скале писали, думаю, так и продолжили
Ага, и тут же баги посыпались "В Twitter официально сообщили, что ситуация со сбросом паролей возникла из-за технической ошибки в системе и фактического взлома не было" http://www.cybersecurity.ru/crypto/163959.html
Есть вероятность, что это не связанные между собой события, но также есть вероятность, что связанные ;)
Это прорыв!
> Это прорыв!А что именно прорвалось-то?
Java, Ruby, Twitter ― три одинаково нужные вещи.
Ненужно
> НенужноКапитан, я вас узнал! :)
Ruby - отличная вещь и нужна
А вот в тексте пишут что тормоза.
По сравнению с языком, который ориентирован на компиляцию, а не интерпретацию? Возможно. А вот по сравнению с php/perl/python/etc очень даже не тормоз.
Это не доказано.
Не доказано, что ты имеешь какое-то представление о том, что ты пишешь, а моё сообщение выше является отражением истины.
Между прочем питон шустрее намного чем руби.
Только в твоих фантазиях.
> Между прочем питон шустрее намного чем руби.А вам не кажется что громкие заявы надо бенчами подкреплять? Будет любопытно посмотреть на битву слоупоков :)
Запусти JRuby.