Как мы перешли с 30 серверов на 2: Go

http://blog.iron.io/2013/03/how-we-went-from-30-servers-to-2-go.html
  • Перевод

Как мы перешли с 30 серверов на 2: Go


Когда мы выпустили первую версию IronWorker около 3 лет назад, она была написана на Ruby, а API было написано на Rails. Через некоторое время нагрузка стала быстро расти и мы быстро достигли предела возможностей наших Ruby приложений. Короче говоря, мы перешли на Go. И если вы хотите узнать подробности — продолжайте читать…

Первая версия

Во-первых, немного истории: мы написали первую версию IronWorker, первоначально названную SimpleWorker (неплохое название, не так ли?) на Ruby. Мы были консалтинговой компанией, создающей приложения для других компаний, и в то время были 2 популярные вещи: Amazon Web Services и Ruby On Rails. И таким образом мы создавали приложения, используя Ruby on Rails и AWS, и привлекали новых клиентов. Причина по которой мы создали IronWorker была в том чтобы «почесать там где чешется». У нас было несколько клиентов, использующих устройства, которые постоянно отправляли данные в режиме 24/7 и нам приходилось эти данные принимать и преобразовывать во что-то полезное. Решалась эта задача путем запуска тяжелых процессов по расписанию, которые каждый час, каждый день и так далее обрабатывали данные. Мы решили создать что-то, что мы сможем использовать для всех наших клиентов, без необходимости постоянно поднимать и поддерживать отдельную инфраструктуру для каждого из них, чтобы обрабатывать его данные. Таким образом мы создали «обработчик как сервис», который мы сначала использовали для своих задач, а затем мы решили, что, возможно, кому то еще понадобится подобный сервис и мы сделали его публичным. Так и родился IronWorker.

Постоянная загрузка процессоров на наших серверах была около 50-60%. Когда нагрузка выросла, мы добавили еще серверов, чтобы сохранить загруженность процессоров примерно на уровне 50%. Это нас устраивало пока нас устраивала цена, которую мы платили за такое количество серверов. Большей проблемой было то, как мы справлялись со скачками нагрузки. Очередной скачок нагрузки (трафика) создавал эффект домино, который мог вывести из строя целый кластер. Во время такого скачка нагрузки, превышающей обычную всего на 50%, наши Rails-сервера начинали использовать процессор на 100% и переставали отвечать на запросы. Это заставляло балансировщик нагрузки думать, что этот сервер упал и перераспределять нагрузку между остальными серверами. И, так как, помимо обработки запросов упавшего сервера, оставшимся серверам приходилось еще обрабатывать пиковую нагрузку, то обычно проходило немного времени до падения следующего сервера, который опять исключался из пула балансировщика, и так далее. Довольно скоро все сервера приходили в нерабочее состояние Это явление также известно как colossal clusterf**k(+Blake Mizerany)



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

Мы переписали его

Мы решили переписать API. Это было простое решение, Честно говоря, наше API, написанное на Ruby on Rails, не было масштабируемым. Основываясь на многолетнем опыте разработки подобных вещей на Java, которые могли обрабатывать большую нагрузку используя куда меньшие ресурсы чем Ruby on Rails, я знал, что мы можем сделать это куда лучше. Таким образом, решение сводилось к тому, какой язык использовать.

Выбор языка

Я был открыт для новых идей, так как последнее, что я хотел сделать — это вернуться к Java. Java есть (был?) прекрасный язык, в котором много преимуществ, таких как производительность, но после написания кода на Ruby в течение нескольких лет, я был восхищен тем, как продуктивно я могу писать код. Ruby это удобный, понятный и простой язык

Мы посмотрели на другие скриптовые языки с лучшей производительностью, чем у Ruby (что было несложно), такие как Python и JavaScript/Node.js. Также мы рассмотрели базирующиеся на JVM — Scala и Clojure, и другие языки, как Erlang (который использует AWS) и Go (golang). Go победил. То, что конкуррентность была фундаментальной частью языка, было отлично; стандартная библиотека ядра содержала почти все что нам нужно было для построения API; он емкий; он быстро компилируется; программировать на Go просто приятно — так же, как и на Ruby, и, в конце концов, числа не лгут. После построения прототипа и тестирования производительности мы поняли, что можем без проблем обрабатывать большие нагрузки при помощи Go. И, после некоторых обсуждений с командой («Все в порядке, его поддерживает Google»), мы решили использовать Golang.

Когда мы впервые решили попробовать Go, это было рискованное решение. Не было большого коммьюнити, не было большого количества open source проектов, не было успешных случаев применения Go в продакшне. Также мы не были уверены, что мы сможем нанять талантливых программистов, если мы выберем Go. Но вскоре мы поняли, что мы сможем нанять лучших программистов именно потому, что мы выбрали Go. Мы были одной из первых компаний, которые публично заявили об использовании Go в продакшне, и первой компанией, которая разместила объявление о вакансии в рассылке golang. После этого лучшие разработчики захотели работать на нас, потому что они смогли бы использовать Go в работе.

После Go

После того как мы запустили версию на Go, мы снизили количество серверов до двух (второй нужен больше для надежности). Нагрузка на сервера стала минимальной, как будто ничего и не использовало ресурсов. Загрузка процессора составляла менее 5%, и приложение использовало несколько сотен КБ памяти (при запуске) в сравнении с Rails приложениями, которые отъедали ~ 50 МБ (при запуске). Сравните это с JVM! Прошло много времени. И с тех пор у нас больше никогда не было colossal clusterf**k.

Мы сильно выросли с тех времен. Сейчас у нас намного больше трафика, мы запустили дополнительные сервисы (IronMQ и IronCache), и сейчас мы используем сотни серверов, чтобы покрыть нужды клиентов. И весь бэкенд реализован на Go. В ретроспективе это было отличное решение — выбрать Go, поскольку это позволило нам построить отличные продукты, чтобы расти и масштабироваться, а также привлечь талантливых людей. И, я думаю, что сделанный выбор будет продолжать помогать нам расти в обозримом будущем.

PS Перевод сделан с разрешения Travis, и если возникнут какие либо вопросы, то он и другие члены команды Iron.io с удовольствием ответят на них.
Поделиться публикацией
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама
Комментарии 275
  • +137
    «Все в порядке, его поддерживает Google», и Reader тоже поддерживала Google. Прошу прощения, не могу отойти от сегодняшнего.
    • +3
      Когда Google перестанет поддерживать Google Reader, тот просто перестанет работать.
      Если Google перестанет поддерживать Go, тот будет точно так же работать и дальше.
      • +31
        Вашими бы устами да мед пить. Кому нужна неподдерживаемая платформа?
        • +1
          ну исходники и вики переедут с googlecode на bitbucket, делов-то
          • +23
            А зачем? они могут продолжать гнить и на googlecode.
            • +58
              пока google и его не закроет.
              • +4
                Для гугла не будет большой проблемой к закрутию googlecode, еще бонусом прикупить bitbucket и закрыть его.
                • +1
                  Не думаю, что Atlassian продастся гуглю.
                  • +2
                    «Гугл купил Марсианскую программу… и закрыл как не популярную» :)
          • +1
            Платформа не прекратит существование в один день. Она будет работать и дальше. Ваши сервера не выключатся. Да, вам станет труднее найти новых специалистов для её поддержки в будущем. Но ваш бизнес будет работать, клиенты не убегут узнав, что Google прекратил поддержку Go.

            Или вам в одночасье станет противно работать с платформой, которая ещё вчера всем устраивала? :)
            • +15
              Конечно не убегут, им вообще наплевать на чем вы еще раз перепишете API.
          • +1
            И не будет развиваться, как, например, ReiserFS
          • +11
            Все в порядке, гугл поддерживает gwt. Подсадили пол мира на него и бросили.
            • +2
              Ну Go насколько я помню не так и сильно относится к Google, там основатели языка вроде работают, и на этом все. Вот Dart — это Google.
          • –24
            jruby не не слышали
            • 0
              Минуса за формулировку вполне оправданы, но мне тожe интересно, дал бы эффект переход на jruby.
              • 0
                Я бы хотел посмотреть сравнение скоорости, неужели python сильно медленнее Go, а comunity у него огромное.
                • +1
                  Вы хотите сравнить скорость работы компилируемого и исполняемого языков? Сразу могу сказать, разница будет в 10-20 раз.
                  • +2
                    Нет никакого смысла сравнивать скорость работы кода. Нужно сравнивать скорость работы программ, выполняющих одинаковые задачи. Ну какой прок от того, что go быстрее складывает 2 числа, задача выбрать из базы данные и отдать их в json? И вот тут у go не все так радужно: стандартная библиотека довольно медленная.
                    • 0
                      Это уже частности, в разных языках есть разные косяки в библиотеках, можно для каждого языка подобрать неудачный пример. Последний раз когда я анализировал разные базы данных, у отдельных языков программирования был полный швах в скорости работы с МонгоДБ из-за библиотек. Но в целом компилируемые языки на порядок быстрее просто из-за своей природы.
                      • +1
                        > Это уже частности, в разных языках есть разные косяки в библиотеках
                        Да, и именно это бывает важно для задачи.
                        • 0
                          По вашей логике сравнить один язык с другим вообще оказывается невозможным, только в узких примерах, под конкретную уже поставленную задачу =)
                    • 0
                      Пруф?

                      Разница не будет такой большой. Иногда вообще нет разницы. Иногда байткод быстрее (и теоретически и практически).

                      Но вот в случае с языком Си можно добиться хорошего выигрыша в производительности, по сравнению динамическими языками, управляе выделением и освобождением памяти самостоятельно.
                        • 0
                          Не касаясь остальной ветки, замечу, что в бенчмарках по ссылке стандартная ошибка при тестировании Java: отсутствие прогрева. Может, на тривиальном примере, как там, это бы и не сказалось, а на сравнении любых программ, состоящих более чем из одной функции, это сказывается.
                          • 0
                            Да, действительно в этом примере результат впечатляющий. Хотя сказалась опять же упревление памятью. Вынес декларацию переменных из цикла в Perl, время упало с 19 до 15 сек на моей машине.

                            Вот пример работы со строками raid6.com.au/~onlyjob/posts/arena/ там вообще Perl обгоняет Си.
                          • +1
                            А за счёт чего байткод может быть быстрее?
                            • 0
                              В теории — например, если байткод вместе с его интерпретатором лучше влезают в кэш процессора, чем нативный код.

                              На практике — есть JIT, он сможет скомпилировать часто используемый кусок байткода в нативный, с нужными оптимизациями (он будет знать какая ветвь там чаще выполняется).

                              Или может дело в библиотеках. Например в Perl — массив имеет некоторое количество памяти выделенное до него и после него, поэтому нормально (быстро) работает как стэк или очередь. Так что если взять и написать «простую» программу где используются обычне массивы без всяких библиотек, то Сишный массив может проиграть.

                              А если в Си постоянно использовать библиотеку с самыми умными массивами которые только может быть, Си потеряет преимущество контроля за выделением/освобождением памяти (очень медленная операция по сравнению с арифметикой).

                              вот в примере raid6.com.au/~onlyjob/posts/arena/ показано что Перл быстрее Си в операциях со строками.
                    • 0
                      Кстати, нет… правда не слышали…
                    • +13
                      Кто-то может объяснить, что случилось с руби? Вроде ещё недавно холивары были что лучше руби vs python, если совался с php, то заклевывали моментально.

                      Сейчас такое ощущение, что со всех сторон плевки на руби идут. Что произошло?
                      • +74
                        Мода прошла
                        • +4
                          Ага. Люди поняли, что писать сайтики для двух людей на руби прикольно, а вот высоконагружённые приложения — совсем не айс. И он годится только потешить своё удовольствие.
                          • –3
                            Совершенно не согласен.

                            С Ruby и Ruby on Rails все как раз айс и даже больше!
                            Руби набирает все большую популярность и постоянно развивается в лучшую сторону.
                            Сам пишу на RoR и каких-либо тормозов не замечаю.

                            «Сейчас такое ощущение, что со всех сторон плевки на руби идут. Что произошло? » — не то и не там читаете, вот что произошло. Я не видел вообще никакого негатива в сторону Ruby.

                            Вполне возможно, что идолопоклонники приверженцы php вряд ли могут вам сказать что-то хорошее о Ruby, оно и понятно — Ruby давно уже заткнул за пояс php по производительности, а это был наверное единственный аргумент в пользу php когда-то.
                            • +1
                              Ruby давно уже заткнул за пояс php по производительности

                              benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=yarv&lang2=php
                                • 0
                                  Что сказать-то хочешь?
                                  • –2
                                    хотя бы то, что тесты должны быть абсолютно идентичными в коде, это во-первых
                                    во-вторых — если даже на простейших тестах видна такая значительная разница, я не думаю, что на более сложных тестах что-то должно кардинально измениться.
                                    хотя да, согласен, нужно будет написать еще пару-тройку тестов — структуры (деревья, списки), массивы, строки, регулярки — чтобы уж точно было более убедительно
                                    • +4
                                      > тесты должны быть абсолютно идентичными в коде
                                      Тесты должны использовать все преимущества языка.
                                      • 0
                                        назовите мне хоть одно преимущество php, по которому он будет проходить тест быстрее других языков программирования?
                                        именно поэтому я и написал тесты, которые повторяют код друг друга в точности, но на разных языках
                                        • +1
                                          преимущества, говорите?

                                          вот специально сейчас глянул на исходники тестов на benchmarksgame.alioth.debian.org и сравнил…

                                          совершенно странно, почему обычные циклы в php сравниваются с итераторами в Ruby? Итераторы — это более медленный механизм, хотя и более мощный несомненно. Давайте тогда уж будем до конца честными — заменим все итераторы в коде теста Ruby на обычные циклы и тогда уж сравним.
                                          • 0
                                            Замените. Насколько я знаю, патчи приветствуются.
                                            • –2
                                              Оно мне надо?
                                              Мне достаточно собственной уверенности, а остальным стоит задуматься — а всему ли надо так безоговорочно верить? Зачастую не лишне и перепроверять.
                                              • +8
                                                Ну гундеть и порть горячку вам надо, а поправить не надо. Вот так и живем.
                                                • –1
                                                  Стандартный ответ: «Сам дурак!», когда нечего уже возразить, остались лишь эмоции и слюни. Знакомо ;-) Не утруждайтесь в оскорблениях — все-равно мимо.

                                                  Просто я всегда пытаюсь разобраться, а не просто верить всему на слово.
                                                  • +1
                                                    Просто я всегда пытаюсь разобраться, а не просто верить всему на слово.


                                                    Пока что ваша теория подкреплена только вашими словами и больше ни чем. Так что, большинство поверить тем тестам, а не вам. Хотя возможно вы и правы.
                                                    • –1
                                                      Я не собираюсь разбиться об стену, только лишь кому-то доказать свою правоту. Дело каждого — кому и во что верить.

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

                                                      Моя теория подкреплена абсолютно идентичным кодом на разных языках программирования, в отличии от абсолютно различной реализации алгоритмов тестов на benchmarksgame.alioth.debian.org. Зачем вводить в заблуждение? Там более, что такой (вроде как) авторитетный источник.
                                                  • +2
                                                    Вы сами патчи туда присылали? Подтверждаю что это не правильные бенчмарки (по собственному опыту) +
                                                    habrahabr.ru/post/119579/
                                                    • 0
                                                      Во!.. «А мужики-то не знают...» ;-)
                                                • –1
                                                  Да сами проведите замеры и представьте публике, если лень патчи делать.
                                                  • +1
                                                    Вот, не поленился. Спасибо доброму человеку — предоставил код теста mandelbrot.

                                                    Сравнение производительности Ruby и PHP.

                                                    Не стоит все же всему безоговорочно доверять.
                                                    • 0
                                                      Мне казалось, в Руби jit. И всего 20%?
                                                      • 0
                                                        Вам именно казалось, а желательно все-таки знать.
                                                        А 20% на таком тесе — это очень даже не мало.
                                                        • 0
                                                          Действительно, не могу найти точного указания на этот факт, хотя есть много упоминаний вскользь (хотя бы вот). Значит на самом деле там нет jit?
                                                        • 0
                                                          В тестах, где производится вызов метода объекта, пройгрыш PHP составляет около 50%, что фактически в 2 раза медленнее, чем Ruby.
                                                          Еще какие-то вопросы есть?
                                                          • +1
                                                            Напомню, что реализаций ruby несколько.

                                                            MRI — JIT'а нет, его пока пытаются пилить.

                                                            JRuby — JIT самой JVM, сам JRuby пытается оптимизировать довольно много, чтобы позволить лучше работать JIT'у JVM. Дополнительно можно посмотреть здесь: github.com/jruby/jruby/wiki/JRubyInternalDesign.

                                                            Rubinius и MacRuby — имеют свой JIT.

                                                            IronRuby и Ruby.NET — используют JIT .NET CLR, насколько понимаю.
                                                            • 0
                                                              Я имел в виду ту реализацию, которую использовал Sega100500, MRI.
                                                              • –1
                                                                Спасибо за напоминание, Капитан Очевидность!

                                                                Если бы я имел ввиду какую-то иную реализацию, я бы так и написал, тем более, что у них у всех различные названия, не так ли?

                                                            • 0
                                                              Поскольку сам пишу на node.js, решил проверить, как дела в нём:

                                                              gist.github.com/AlexeyKupershtokh/5180271
                                                              • –3
                                                                совсем некорректное сравнение, мне кажется
                                                                в JS используется JIT — конкретно в NodeJS — V8
                                                                я не специалист в NodeJS, поэтому эти выводы только с помощью гугл сделал
                                                                • +1
                                                                  > совсем некорректное сравнение, мне кажется
                                                                  лол
                                                                  > тесты должны быть абсолютно идентичными в коде
                                                                  • –2
                                                                    да, но на подобных друг другу языках…
                                                                    вы не путайте, пожалуйста
                                                                    проще можно было бы тогда сравнить PHP и C
                                                                    • +1
                                                                      да, но на подобных друг другу языках…
                                                                      проще можно было бы тогда сравнить PHP и C
                                                                      Поскольку сам пишу на node.js
                                                                      • –1
                                                                        Писали бы Вы на C, все вообще бы в шоке были, насколько тормоза эти PHP/Ruby/Python ;-) )))
                                                                • –2
                                                                  для примера, небольшое добавление простейшего динамизма в код JS:

                                                                  var $test = 'abcde';



                                                                  и внутри цикла:

                                                                  var $tr = $zrzr — $zizi + $cr;
                                                                  var $ti = 2.0 * $zr * $zi + $ci;

                                                                  $test = $test[3] + $test[0] + $test[4] + $test[1] + $test[2];

                                                                  тут же увеличивает время выполнения кода JS на порядок (в 10 раз)!

                                                                  для примера, время выполнения идентичного кода на Ruby увеличилось в 6 раз.
                                                                  • 0
                                                                    тут же увеличивает время выполнения кода JS на порядок (в 10 раз)!
                                                                    То, что нода с палками в колёсах все равно ездит в 3 раза быстрее ruby и php, как-то должно меня от нее отпугнуть? :)
                                                                    • 0
                                                                      Конечно же нет!
                                                                      Вообще выбор ЯП — дело сугубо каждого.

                                                                      Разве я собирался кого-то пугать? Вообще не агитирую за смену ЯП или системы разработки. Каждому — свое! К слову, JS мне вообще не нравится, я могу его терпеть только в виде JQuery максимум.

                                                                      В начале я вообще привел сравнение 2-х (истинно) скриптовых ЯП, не предполагал, что это вот в такую ветку обсуждений растянется, да еще и придется дополнительные эксперименты проводить.

                                                                      Но вывод я сделал — на хабре всем троллям не угодишь, которые норовят шмякнуть минус и вякнуть что-то.

                                                                      Побольше бы таких, как вы — которые хотя бы реальные эксперименты проводят, чтобы убедиться в чем-то.
                                                                      • –1
                                                                        так, для общего развития… на простейших тестах JS проигрывает по производительности Ruby в 6-8 раз… проверил только на 1-ом тесте.
                                                                        И, кстати, в фреймворках как раз достаточно интенсивно используются вызовы методов объектов и функций.

                                                                        Все по-честному, без обмана у Волшебника Сулеймана — никаких «с палками в колёсах».

                                                                        Но это ни в коем случае не должно Вас отпугнуть от использования NodeJS. Боже упаси!

                                                                        Это просто я все пытаюсь провести разностороннее тестирование.
                                                                        • 0
                                                                          … хотя не везде так. В разных браузерах совершенно разная скорость. NodeJS не установлен, поэтому скорость проверяю в браузерах FireFox, Opera, Chrome.
                                                                          • 0
                                                                            провел еще несколько тестов…
                                                                            нет, все же Javascript с V8 быстрее (что нисколько не удивляет, если верить Википедии: «Компиляция исходного кода JavaScript непосредственно в собственный машинный код, минуя стадию промежуточного байт-кода.».

                                                                            Но самое интересное в том, что в Ruby запросто можно использовать этот движок V8, т.е. какие-то особо критичные до скорости алгоритмы можно запросто реализовать на нем, оптимизировать. Тест вычисления Фибоначчи с использованием V8 выполняется примерно в 7 раз быстрее. Такие вот дела.
                                                                            • 0
                                                                              1) Вы недавно говорили, что сравнивать компилируемые языки с некомпилируемыми, а теперь сравниваете.
                                                                              2) Вы недавно говорили, что вам JS не нравится, а вот вы уже готовы писать на нём, да еще и без JQuery. Не говоря уже о том, что это будет внутри руби, что имхо еще хуже, чем писать на чистом языке.
                                                                              • –3
                                                                                1. Такой уж пытливый ум у меня — попытался выяснить причину этого превосходства. Всегда считал JavaScript скриптовым, а он вон как — перекочевал с помощью V8 практически в нишу компилируемых языков. Все потому, что никогда особо не интересовался JS, и не собираюсь в дальнейшем.

                                                                                2. Не только говорил, но и говорю — не нравится мне JS, и воспринимаю его максимум в виде JQuery. На нем писать не собираюсь, не более того, чем это нужно будет в веб-приложении — всегда хватает небольших JS-вставок. Просто нашел способ оптимизации «узких мест» в программе на Ruby. Совершенно даже не призываю использовать это, просто такой способ есть — как факт.

                                                                                Меня Руби устраивает во всем и полностью.
                                                                • +2
                                                                  Плюсую. benchmarksgame.alioth.debian.org — это не бенчмарк.

                                                                  Это бенчмарк * соревнование программистов что в итоге переодически даёт 0.

                                                                  Видел как сравнивается одно выражение на ruby с циклом на perl, что явно фейк. Так же много где не удалось увидеть исходник (сайт глючил).

                                                                  И судя по отзывам автор не очень дружелюбен, и в место того чтобы обеспечить честность бенчмарков говорит «присылайте патчи» и сам их отвергает если они лично ему не нравятся.
                                                                  • 0
                                                                    Вообще сама идея делать такой сайт… Это всё равно что написать критичеси важную программу на 10 языках одновременно, которых сам не знаешь.

                                                                    В случае критического бага отвечать «пришлите патч, сделайте форк» и ничего самому не делать.

                                                                    Весь такой «продукт» можно отправлять в корзину, поэтому и патчи туда присылать даже не хочется.
                                                      • +3
                                                        Синтетические тесты — ничто. Не устану этого повторять. Пиши код на том, что знаешь.
                                                        • 0
                                                          Я знаю и php, и Ruby, но вот на php возвращаться уже нет совершенно никакого желания. Единственное, что меня сейчас связывает с php — это предыдущие разработки, которые так или иначе надо совершенствовать… пока не найду время все это переписать на Ruby.
                                                          • +1
                                                            У рубистов столько времени на холивары, а на то, чтобы напрочь забыть php и «переписать все это» на руби, времени нет… Зачем разводить бессмысленные языковые войны и поддерживать извечное противостояние «такого плохого» php и «такого замечательного, чмок-чмок-чмок его во все места» руби в посте… про go.
                                                            • –2
                                                              Я не сказал, что php — плох. Просто желания уже возвращаться к нему нет, пройденный этап.
                                                              Php вполне себе приличный язык. Про php я вообще упомянул вскольз.

                                                              Но то, что надо бы переписать во-первых слишком объемное, а во-вторых — текущих проектов на Руби достаточно для того, чтобы не было времени отвлекаться на что-то еще.
                                                              • +1
                                                                На что-то еще кроме холиваров, видимо…
                                                                • 0
                                                                  Холивар я не собирался разводить, честное слово!
                                                                  Как говорится, это Вы меня неправильно поняли ;-)

                                                                  На самом деле работы предостаточно!
                                                    • –1
                                                      да-да, просто кто-то из разряда «ниасилил» сказал, что это уже не модно и двинул туда, где попроще ;-)
                                                      • –3
                                                        Куда уж проще Руби?
                                                        • +1
                                                          Лично я ничего плохого к руби не испытываю, стараясь во всем найти здравый смысл. И вместо обсуждения языков, хотел бы заметить, что рубисты все чаще стали напоминать мне… знаете, есть такие владельцы айфонов, которые уже на том основании, что у них «телефончик с яблочком» считают себя людьми высшего сорта.

                                                          Руби — круто. Рубизм головного мозга — очень плохо.

                                                          И вообще — на мед слетается мух столько же, сколько на навоз… но только это мухи разного вида.
                                                          • –1
                                                            Решаюсь улететь в минуса, но все же продолжу Вашу гениальную мысль…

                                                            А PHP-изм головного мозга — это…

                                                            варианты ответов не предлагаю.

                                                            Согласитесь, сколько холивара было начато именно на почве PHP.
                                                            • +3
                                                              Я вообще сейчас улечу в минуса. Я считаю, что сравнивать языки надо не с позиции «быстро/медленно» или «модно/не модно», а с позиции выгоды. То есть, надо трезво оценивать — сколько может принести использование каждого конкретного языка за единицу времени. Тогда и с холиварами проблем не будет — эти цифры будут сугубо индивидуальными.
                                                              • 0
                                                                Лично мой опыт, только мой — на написание сайта средней сложности на php у меня уходило 1.5 — 2 недели, на Ruby — 1 — 1.5.
                                                                И кода значительно меньше получается.
                                                                • 0
                                                                  А еще я бы хотел заметить, что то, что выгодно фрилансеру не всегда выгодно заказчику… даже если предположить, что обе стороны стремятся реализовать проект наилучшейшим образом. Безотносительно языков или платформ.
                                                                  • –4
                                                                    1. Я не фрилансер
                                                                    2. Я всегда стараюсь выполнить именно пожелания заказчика, потому как продукт пишется именно для него. Конечно, исключая случаи, когда требуется реализовать уж какой-то совершенно бред.
                                                                    3. Преимущества сайта на Ruby, я думаю, будут очевидны даже заказчику.

                                                                    Для заказчика прежде всего важны: соответствие проекта его пожеланиям, скорость исполнения проекта, надежность его работы, мне так кажется. А вот исполнителю как раз важно показать, что он сможет все это реализовать с помощью того инструмента, которым пользуется — в данном случае — система разработки, выбранная для реализации проекта. И желательно, чтобы потом не пришлось переписывать все на Go ;-)
                                                                    • 0
                                                                      Кроме перечисленного для заказчика важна также легкость дальнейшей поддержки и быстрая замена в случае чего одного разработчика на другого. Найти хорошего пхп-программера, имхо проще чем просто рубиста.

                                                                      Но тут не только пхп, есть ещё питон, который как мне кажется более популярен чем руби с рельсами, но имеет те же преимущества.
                                                                      • 0
                                                                        Хороших разработчиков примерно везде одинаково, независимо от языка программирования. Тем более, тенденция последнего времени такова, что очень часто, начав с php, разработчики предпочитают сменить язык на Python или Ruby.
                                                                        • +1
                                                                          >Хороших разработчиков примерно везде одинаково, независимо от языка программирования.

                                                                          То есть, на брейнфаке хороших программистов тоже самое количество, что и например, на сях?
                                                                          • 0
                                                                            Да, примерно одинаково. Именно хороших, а не всяких. И, как правило, первоклассные специалисты владеют несколькими языками программирования.
                                                                            Я знаю (и имею опыт разработки) на Assembler, Pascal, C, C++, Delphi, C++ Builder, но для веб выбрал сначала Perl, потом PHP, сейчас Ruby.
                                                                            И хочу сказать, что Ruby тем и хорош (ко всему прочему), что если заказчик нашел программиста на Ruby, то он с бОльшей уверенностью может предполагать, что это программист по крайней мере среднего уровня.
                                                                            Это не голословные утверждения — мне доводилось сталкиваться с тем «кодом», который написал один деятель, закончивший 3-месячные курсы по PHP и считавший себя программистом. Контора до сих пор разгребает то дерьмо, что он понаписал. А я им сразу сказал, что в этом навозе я ковыряться не собираюсь — я не сантехник, мне гораздо проще было взять и написать все заново.
                                                    • +24
                                                      А откуда ещё плевки? Если можете, покидайте ссылочек.

                                                      А по теме, то кажется, всё в порядке: ребята быстро написали продукт на Rails, пришла пора масштабироваться — выбрали более подходящее решение.

                                                      Во-первых, не факт, что они не могли всё оптимально переписать на Ruby (например, используя другой фреймворк, активнее используя кеширование, переработав логику и т.п.). Во-вторых, даже, если и не могли, то, кажется, ничего страшного. У каждого языка\фреймворка должна быть своя ниша. Судя по тому, что их сервера перестали справляться Ruby\Rails прекрасно выполнили свою функцию.
                                                      • +36
                                                        Судя по тому, что их сервера перестали справляться Ruby\Rails прекрасно выполнили свою функцию.

                                                        Хорошо сказано :)
                                                        • 0
                                                          Я не рубист, поэтому особо не запоминаю ссылки. Но как-то из обсуждений, комментариев и и.т.д сложилось такое впечатление.
                                                          • +2
                                                            Очень много, порой, обсуждают и комментируют (негативно) как раз те, кто вообще мало представления имеет о Ruby — чаще всего это какое-то абстрактное мычание, совершенно не подкрепленное практическим опытом.
                                                        • 0
                                                          Сейчас все больше склоняются к тому, что Ruby и Ruby on rails больше подходят для быстрой разработки прототипа. Написали, выкатили потестировали, переписали, потестировали и т.д. На больших нагрузках, как правило выбирают другое решение, либо комбинируют…
                                                          • +4
                                                            Так и есть.

                                                            Быстро написали — быстро выкатили — получили Proof of Concept — быстро нарастили клиентскую базу — у вас завелись деньги — нанимаете толпу инженеров и меняете платформу на более серьезную, если простая оптимизация узких мест не спасает.
                                                            • –1
                                                              гугол вот уже.давно использует питон для быстрого прототипирования, потом все на яву перегоняют.
                                                            • +3
                                                              Это совершенно не плевки в сторону Ruby. Ребята быстро написали прототип, выкатили в production, подняли на этом деньги и переписали сервис на инструменте, который к конкретно их задаче подходит лучше.

                                                              Ruby или Rails сами по себе не плохи, и там где надо, они справляются лучше всех. Но если какая-то компания отказалась от Rails в сторону чего-то быстрого, вероятно они просто адекватно оценивают задачи и подбирают инструменты. Не более, не менее.
                                                              • +1
                                                                Ничего не случилось. Автор не говорит про ruby, он говорит про рельсы. А рельсы пишуться с идей «перформанс оставляем на потом, сейчас главное, чтобы всё было красиво».
                                                              • +27
                                                                We decided to rewrite the API. This was an easy decision

                                                                Мы решили переписать API. Это было непростое решение

                                                                • +3
                                                                  спасибо, поправил, скорее всего Travis опечатался, решение насколько я помню было не простое )
                                                                • +4
                                                                  Было бы интересно узнать подробнее — как выбирали язык. Интересно, почему отказались от erlang
                                                                  • +1
                                                                    Это же перевод.
                                                                    • +2
                                                                      тем не менее ответить на вопросы мы можем :)
                                                                      PS думаю через пару часов, когда проснутся
                                                                    • +1
                                                                      Могу предположить, что переписывать с Ruby на Go всё-же проще, чем на Erlang. Проще в смысле проще переносить код 1 в 1. На Erlang/OTP придётся существенно перерабатывать.
                                                                      • 0
                                                                        Нынче уже есть elixir-lang.org/
                                                                        • 0
                                                                          перенос кода 1 в 1

                                                                          Предположу существование еще одного важного фактора, действующего против Erlang — это отсутствие встроенных в язык словарей (aka dict, HashMap, map)
                                                                          • +2
                                                                            Я для маленьких использую orddict:, для покрупнее dict:. Если нужен O(1) доступ — можно ETS использовать. Возможно, конечно, есть проблема что они не встроены в язык, но как-то обходимся.
                                                                      • +9
                                                                        Производительность 1 к 32, это чего это Ruby такой медленный то и в Ruby ли дело?
                                                                        • +9
                                                                          Ruby достаточно быстр, дело больше в Rails – его разработчики никогда не чесались о производительности. Плюс если IronWorker спасла конкуррентность — скорее всего производительность упёрлась в GIL
                                                                          • 0
                                                                            GIL, как мне кажется, вообще всю идею конкурентности на корню убивает. Тогда уж проще на процессы разбивать все и не использовать нити вовсе.
                                                                            • 0
                                                                              Ну, т.е. они упёрлись в стенку так как concurrency в ruby и не пахло
                                                                              • 0
                                                                                wut? Fibers — самые что ни на есть корутины.
                                                                                • 0
                                                                                  И что? Корутины != конкарренси
                                                                                  • 0
                                                                                    Через корутины реализуется конкурентное программирование.
                                                                              • +1
                                                                                а при чем здесь GIL и конкуренция?
                                                                                concurrency != threads
                                                                              • 0
                                                                                Где там сказано что у них был один процесс? Не ужели бы они не заметили что только одно ядро используется?
                                                                                • 0
                                                                                  GIL не позволяет потокам работать на разных ядрах, поэтому профиты от многопоточности сводятся почти к нулю. Из за GIL такие языки, как Ruby, Python, PHP, никогда не будут быстро работать в случае многопоточного программирования. Это ограничение by design, нужно или на процессы переходить, или на другие языки программирования.
                                                                                  • +1
                                                                                    В языке Python архитектурно нет никакого GIL, он есть в реализации CPython. В IronPython глобальных блокировок нет (мелкомягкие его поматросили и бросили, но он всё ещё рабочий). В Jython тоже такого анахронизма нет.

                                                                                    Подозреваю, аналогичная история с Ruby — не все реализации одинаково полезны.
                                                                                    • +2
                                                                                      Да, в Ruby, как я помню, только в MRI (референсная реализация) есть GIL. А jruby, rubinius — без GIL.
                                                                                    • НЛО прилетело и опубликовало эту надпись здесь
                                                                                      • 0
                                                                                        Большое спасибо за расказ о GIL.
                                                                                        Я как раз про то и говорю, что у них явно был не один процесс, а много. Соответсвенно GIL тут не причём.
                                                                                        • +1
                                                                                          В JRuby есть честные потоки, а в офф интерпретаторе уже ввели или почти ввели.
                                                                                    • +2
                                                                                      Думаю дело в тяжеловестности/оверхеде Rails и всяких других гемов.
                                                                                      • –1
                                                                                        Думаю дело вот в этой шляпе.
                                                                                        habrahabr.ru/post/84629/
                                                                                        • +5
                                                                                          Т.е. Вы хотите сказать, что серьёзные, взрослые люди, запустили один процесс, на сервере, посокрушались что он занимает аж целых 50 мегабайтов памяти, посмотрели что он занимает одно ядро максимум, и решили переписать всё на Go, на узнав что такое GIL?
                                                                                    • +109
                                                                                      Смешная история. Если отбросить мусор, звучит она примерно так:

                                                                                      Мы решили сделать сервис под себя для агрегации данных.
                                                                                      В то время хиповыми трендами были Amazon-овские облака и Ruby, и мы выбрали их, потому что в Java нам обои надоели, а инструменты под задачу мы выбираем по принципу «это модно».
                                                                                      Когда сервис заработал, выяснилось, что производительность Ruby вообще никакая, хуже чем даже JS, сервера у Амазона очень дорогие, а архитектура нашего балансира нагрузки такова, что при первом же пике у него случается каскадный отказ серверов (это вообще шикарно!). Поскольку наш код конечно же был очень качественным, то мы решили, что во всем виноват Ruby!
                                                                                      Тогда мы решили подвигать кровати и сменить язык программирования, на ещё более экзотический GO.
                                                                                      Сначала мы боялись, что не сможем нанять крутых спецов по нему, но потому выяснилось, что даже крутые спецы по нему сидят без работы и прибежали к нам по первому зову. Среди них нашлись нормальные программеры, которые исправили нашу кривую архитектуру, и оказалось, что под нашу задачу с головой хватает 2 серверов. Вот такой волшенбый GO!

                                                                                      Короче, как в анекдоте. Ребята при составлении т.з. оперируют понятием «модные технологии» и думают, что отравились овсяным печеньем.
                                                                                      • +1
                                                                                        Справедливости ради речь шла о недостатках масштабируемости RoR, а не Ruby, и выбирали скриптовый язык (для задач iron.io, наверное, имеет смысл). Хотя, конечно, дело навряд ли было в переходе на Go.
                                                                                        • –1
                                                                                          модные технологии это достаточно важный критерий, для некоторых, хотя я тоже с ним не согласен
                                                                                          • –21
                                                                                            По правде говоря, производительность кода зависит в первую очередь от компилятора, потом от программиста потом от железа!!!
                                                                                            Если железо не тянет меняем железо, если код тормознутый меняем код, если код не тянет меняем компилятор.
                                                                                            Только вот жаль что еще нету одного пункта «Поменять МОЗГИ»

                                                                                            Может быть они имели виду что GO создавался компанией ГУГЛ как раз для больших нагрузок ??
                                                                                            Ведь не секрет что сервера гугл тоже падают!!!
                                                                                            • +18
                                                                                              Как вы тут оказались, если не секрет?
                                                                                              • +7
                                                                                                По правде говоря, производительность кода зависит в первую очередь от компилятора, потом от программиста потом от железа!!!

                                                                                                В теме элитный специалист в области компиляторостроения, все в виртуальную машину! Его компиляторы настолько интеллектуальны, что даже bubble sort компилируют в набор инструкций работающий за n*log(n).

                                                                                                А программисты не нужны, вот.
                                                                                                • 0
                                                                                                  bubble sort? не, не слышал. Есть же mySuperArray.sort(), нету никакого метода bubble_sort…
                                                                                                  кхм, простите, это я к тому, что интерпретируемые языки обычно способствуют не думать о сложности алгоритмов, может автор это имел ввиду. Хотя кто ж его знает :)
                                                                                              • +6
                                                                                                > Мы были консалтинговой компанией, создающей приложения для других компаний, и в то время были 2 популярные вещи: Amazon Web Services и Ruby On Rails. И таким образом мы создавали приложения, используя Ruby on Rails и AWS

                                                                                                Для консалтинговой компании более чем нормально использовать то, что модно — ведь частенько со стороны заказчиков использование модных и известных технологий заявляется как необходимое условие. Т.е. в данном случае компания умело использовала тренды.
                                                                                              • +3
                                                                                                Спасибо комрад, вы написали то что я хотел. У меня вообще всегда ощущение от таких вот кейсов (уже второй на моей памяти) очень печальное.
                                                                                                Я CTO и я выбираю технологии исключительно с подхода моды. Я сделал первую версию весьма плохой. Но не могу же я признать, что взял совершенно не верные инструменты в виде rails? Может быть мне стоит не тратить деньги фирмы. не выбрасывать наработки и опыт людей? может стоит оставить все на руби, но переписать на EventMachine или fibers. Может хотя бы провести тесты..? эмммм, неееет, лучше перепишем все на новом модном языке. И чудо, чудо правильно выбраная парадигма жрет разумное количество ресурсов. Стоит ли теперь признать, что я некомпетентен? эммм, неее, лучше обвиню неверно мной выбранный инструмент.

                                                                                                В прошлый раз, тоже ктото из Linked рассказывал, как он заменили синхронный rails на асинхронный node.js для чата (или чего то подобного) и тоже как дети радовались что заработало быстрее.

                                                                                                Ну тут же все взрослые люди, прирост производительности в 15 раз, только за счет языка? верится с трудом. Сложно судить не зная задачи, но почти уверен, что перепиши они задачу на fibers, нууу 4 бы сервера использовали. Зато сколько денег на разработке бы сэкономили.
                                                                                                • 0
                                                                                                  С другой стороны веб-приложения с претензией на динамичное развитие написанные на Java доставляют. Правда проблем разработчикам, которые не успевают угнаться за рынком.
                                                                                                  • 0
                                                                                                    Почему Вы решили что дело в модели многопоточности? Да ruby код не в вакуме живёт. Использует библиотеки, гемы, решающие всякие практические задачи, которые тоже могу влиять на производительность.
                                                                                                    • 0
                                                                                                      Основная проблема, что статья скорее вброс чем источник информации. Любой компетентный человек сделал бы две вещи:
                                                                                                      1)Хотя бы _попробовал_ бы пофиксить архитектуру на текущей платформе. Ну чисто изза экономических соображений.
                                                                                                      2) Произвел бы хотя бы минимальные бенчмарки на каком то подмножестве своей задачи и получил бы конкретные _цифры_

                                                                                                      Оперирование фактами и цифрами, вот что отличает компетентного инжинера, от фанбоев. Если автор не приводит все эти «несущественные детали», то конечно можно предполагать что он все это делал… но известная бритва требует признать, что скорее все намного проще и это просто не делалось.

                                                                                                      В целом, следуя собственной логике, я считаю обсуждать тут нечего — ни фактов, не цифр в статье нет. Как оно там было на самом деле, можно только предполагать.
                                                                                                    • +2
                                                                                                      Вообще-то, производительность легко может вырости в несколько раз только за счет использования другого компилятора. Например, по этой ссылке в последней таблице некоторые программы, скомпилированные Intel C++ Compiler, в 3 раза быстрее, чем скомпилированные GCC (да, это не 15 раз, но тем не менее).
                                                                                                      • +4
                                                                                                        Да как же с этим поспоришь, от оптимизатора много зависти. Я понимаю разницу между интерпретируем Ruby и компилируемым go. И собственно на счет скорости ruby иллюзий в принципе не имею. :)
                                                                                                        Но уважаемые комрады… увеличение производительности в 30 раз (он пишет что второй сервер для резерва и в комменте выше я это не учел) просто за счет смены языка. Я верю в это с трудом. Скорее всего все же были и какие то архитектурные изменения которые позволили такого добиться.
                                                                                                        • 0
                                                                                                          В go нет особо развесистых фреймворков, в которых чтобы добраться до целевой части нужно выполнить тыщу и одно действие. Плюс, все что нужно можно пустить асинхронно через go. Так что не чего там удивительного нет. Менять скорей пришлось не архитектуру, а структуру кода, что как бы и так понятно…
                                                                                                          • +2
                                                                                                            Ну а в rails к руби гвоздями что ли прибит? Что мешало убрать его. Легковесных фремворков в руби достаточно. Включая асинхронные.
                                                                                                            И вынужден с вами не согласится — переход на асинхронную парадигму, это архитектурное решение. Иначе вообще любые изменения в приложение, можно было описать как «изменение структуры кода». Что в целом конечно правда, но слишком широкое определение что бы было полезным.
                                                                                                            мое имхо, что статья должна называться «как мы переписали код используя асинхронный подход (ну и кстати перешли на go) и уменьшили потребляемые ресурсы».
                                                                                                          • 0
                                                                                                            Как-то раз (для выбора на чем писать) на Python 2.7 измерял скорость цикла с небольшими арифметическими выражениями (сложение, умножение, деление). Потом сделал тот же цикл на делфи. Скорость была почти в 100 раз больше. Далее сделал библиотеку с этим же циклом на Cython'е и вызывал функцию из питоновского скрипта. Таким образом увеличил скорость выполнения скрипта в 20 раз. А Вы говорите в 30 раз не может…
                                                                                                            • +1
                                                                                                              Веб-сервера редко занимаются арифметикой. А скорость работы с текстом (http, html, json) отличается уже не так сильно и узкие места в основном вынесены в оптимизированные модули.
                                                                                                          • +1
                                                                                                            Это синтетические числодробильные тесты. В реальной жизни всё упирается в работу с БД или в работу с памятью.
                                                                                                          • +4
                                                                                                            Ну тут же все взрослые люди, прирост производительности в 15 раз, только за счет языка? верится с трудом.

                                                                                                            Очень даже может быть, однако go как раз-таки и создавался для написания сильно нагруженных веб-сервисов.
                                                                                                            И то, что ruby — это «вечный тормоз прогресса», тоже ни для кого не секрет, интерпретируемый язык с динамической типизацией. Тогда как go — компилируемый язык со статической типизацией. Поправьте меня, если я не прав. Вот если бы увидеть реальный бенчмарк сравнения двух языков, тогда было бы о чем говорить, а так — сплошные догадки.
                                                                                                            • +1
                                                                                                              поправляю: со строгой динамической типизацией

                                                                                                              • –1
                                                                                                                У Go — статическая типизация. Программы на этом языке получаются очень шустрыми, такой язык, как Ruby, легко может слить Go по скорости в 10 и более раз. Советую всем (программистам, которых интересует данная тема) прочитать откровения Роба Пайка от том, как, для чего, и каким образом создавался этот язык и его компилятор. Многие вопросы отпадут.

                                                                                                                p.s.: здесь неплохо написано про Go: хабрастатья
                                                                                                                • +1
                                                                                                                  очень хотелось бы увидеть пример кода с 10-кратным превосходством производительности, очень!
                                                                                                              • +1
                                                                                                                В статье, как раз, речь идет именно о «реальном бенчмарке». Нет?
                                                                                                                • 0
                                                                                                                  В статье речь о том, как один серьезный большой проект переписали на другом языке (другие люди). То есть функционал остался тот же, а начиника изменилась. Таким образом, здесь значительную роль сыграл динамический фактор. В моем понимании бенчмарк — это несколько другое.
                                                                                                                  • 0
                                                                                                                    не динамический фактор, а человеческий :)
                                                                                                                    • 0
                                                                                                                      На всех не угодишь. Напишут бенчмарк — скажут, что это синтетические тесты, вот если бы на боевом сервере — тогда б да. Напишут success story про успешный опыт оптимизации сменой тормозной платформы на менее тормозную — скажут подавай бенчмарки ибо у авторов success story руки кривые.

                                                                                                                      Я не про вас — я про общий настрой комментариев в этом посте.
                                                                                                                      • +2
                                                                                                                        Ну дык и бенчмарк и саксес стори показывают тормознутось Руби, имхо)
                                                                                                                  • –2
                                                                                                                    у руби ведь есть jit тоже…
                                                                                                                • +10
                                                                                                                  Хорошо передёргиваете, с огоньком.
                                                                                                                  в Java нам обои надоели
                                                                                                                  «Java is (was?) a great language» не значит, что «Java превосходна» — это значит «не будем заострять внимание на недостатках Java, чтобы не провоцировать оффтопичный срач»
                                                                                                                  инструменты под задачу мы выбираем по принципу «это модно»
                                                                                                                  ведь не может же быть, чтобы эти тупыепиндосы исходили из скорости разработки или вообще каких бы то ни было рациональных соображений.
                                                                                                                  • 0
                                                                                                                    Скролил вниз в поисках такого камента. Сам руби разработчик, но для агрегации данных никогда бы не вырал руби.
                                                                                                                    • 0
                                                                                                                      Спасибо, Вы очень подняли мне настроение с утра своим комментарием! :)
                                                                                                                      • +2
                                                                                                                        Я конечно понимаю что целью было максимальное передергивание и гипербола, но все же
                                                                                                                        Сначала мы боялись, что не сможем нанять крутых спецов по нему, но потому выяснилось, что даже крутые спецы по нему сидят без работы и прибежали к нам по первому зову.

                                                                                                                        Вы правда думаете что есть крутые спецы, которые знают Go и только его?
                                                                                                                        Вы правда думаете что перспектива работать (а не только писать для себя) на языке, который тебе больше по душе — это не аргумент?
                                                                                                                        Короче, как в анекдоте. Ребята при составлении т.з. оперируют понятием «модные технологии» и думают, что отравились овсяным печеньем.

                                                                                                                        У ребят все отлично :) Они написали штуку на RoR, которая быстро стала популярной, появилась проблема с производительностью, переписали (язык имхо вообще не ключевой фактор, хотя Go в их случае — хороший выбор), тем самым избавились от проблемы. Классика.