Лол, ты как бы сам рельсы упомянул

Ты читаешь между строк, я лишь сказал что 200 мс даже для рельсов это много

Достоверных подтверждений этого пока что не обнаружено. Хотя кому и в 30 раз медленнее — это быстрый и «holy crap»

Пример я тебе привел

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

Сервисов!!! Не серверов. Ты явно не в теме

Где ты там видишь Goliath? Ты сравниваешь палец с жопой. Да и вообще к чему эти сравнения? Java быстрее, но это не значит что на ruby нельзя написать быстрый сервер.

Твоя позиция — Java спасет мир, моя — язык не так важен. Каждый выбирает по потребностям и задачам. Тем более что микро-сервисы могут быть написаны на чем угодно.

> Now on the Linux front, we used two equivalent quad-core, 2GB RAM XenServer VMs running CentOS5 to keep our tests as even as possible

Да и логически подумай, 200 ms с “hello, world” даже для рельсового приложения — много.

Да, может

Вкратце, цитирую:
> Our load tests showed that our new Goliath endpoint was handling 4,500 reqs/sec with a 200ms avg. response time. Holy crap! This knocked the socks off our previous go ’round by an order of magnitude — even running on equivalent hardware. Now granted... 200 ms is still not ideal, but it’s a huge step in the right direction

Дело не только в распределении нагрузки.

Смысл в разделении всех частей API на более мелкие мини-серверы которые проще тестируются, управляются и рефакторятся. Эти мини-серверы могут быть написаны на любом языке. Их очень просто масштабировать.

PS: Goliath сервер написаный на руби может обрабатывать более 2500 запросов в сек. Язык тут абсолютно не важен.

Совсем недавно из нашего стартапа образовалась небольшая библиотека (на ruby) помогающая в масштабировании API — rodent.

Принцип ее довольно простой.

Есть HTTP сервер который работает как proxy — переводит каждый запрос в JSON, отправляет его в определенную очередь (по route) и ждет ответа (асинхронно) от микро-сервиса. Микро-сервисы — это небольшие серверы (разделенные по функционалу) которые слушают нужную очередь, обрабатывают их и возвращают ответ для proxy. Каждый микро-сервис работает независимо и может быть запущен Nое число раз — все сообщения балансятся между ними по роуту.

Зачем?
1. Мы делим наше API по функционалу — если вдруг будет найдена ошибка в одном сервисе и он упадет, то все остальные будут работать.
2. Т.к. все сообщения у нас работают через AMQP протокол — мы можем быстро переписать отдельные части нашего API на другие языки для оптимизации (например Go).
3. Мы получаем бесплатный Hot-Reload.
4. Микро-сервисы могут запускаться на разных машинах и в любых количествах — довольно быстро можно распределить нагрузку.
5. Критические баги довольно просто изолировать — просто вырубаем нужный сервис на время.

Работает все на ruby (мы собираемся часть наших сервисов переписывать на Go) и выглядит пока немного сыровато (мы пока не в production). Если есть желание помочь с библиотекой (например добавив клиента для Go/Python/че-нить еще) — welcome.