То, что вы описали, реализуется практически на любом языке, не только
на Ruby и Rails, а фраза "апи будет использовано большим количеством
различных сервисов в освном игровых" наводит на мысль что вы смотрите
в сторону неправильной технологии
Rails - это для разработки веб-приложений малого и среднего размера, а
не для высоконагрузочных игровых API. Понятно что хочется все делать
на модном и классном руби, но надо понимать чего это вам будет стоить
12 сентября 2011 г. 13:42 пользователь ErMak <email.for.oleg@gmail.com> написал:
> Доброго дня, уважаемые рубисты.
>
> На днях передо мной встала задача реализации быстрого веб-апи для
> работы с базой данных на ruby.
>
> Собственно вот краткое описание задачи и требования к апи:
> - обработка большого количества параллельных запросов
> - выдерживание высоких нагрузок + адекватное потребление ресурсов
> - работа по http
> - работа с бд напрямую, соответственно потребность во встроенном ORM
> отпадает (возможно будет своя ORM)
> - возврат данных в одном из стандартных форматов (например json), т.е.
> исчезает шаблонизатор и т.д.
> - еще одна достаточно важная деталь: апи будет использовано большим
> количеством различных сервисов (в освном игровых, что опять же ведет к
> высокой нагрузке)
> - возможность запуска на нескольких серверах
>
> Информацию по данному вопросу я так же достаточно тщательно изучал.
> Вот некоторые из возможных вариантов ее решения:
>
> nginx + веб-сервер +
> 1 rails. Все необходимые компоненты в нем есть, но смущает
> избыточность фреймворка и вероятно большое потребление ресурсов.
> 2 ruby + fastcgi. Но после просмотра большого количества материала все
> больше убеждаюсь, что это не продакшн решение. Производительность и
> прочие возможности под сильным сомнением. Примеров живых проектов,
> справочным материалов или примеров практически просто нет (за
> исключением hello world).
> 3 ruby + lsapi. Собственно вот описание этой тулзы:
> http://blog.litespeedtech.com/2006/08/31/why-i-dont-think-ruby-fcgi-can-beat-lsapi-benchmark-ruby-fcgi-vs-lsapi/.
> Но сомнения на ее счет так же очень большие.
> 4 ruby + rack (http://rack.rubyforge.org/). Вот этот вариант мне
> нравиться все больше и больше. Фактически он позволяет использовать
> существующие веб-сервера (тот же unicorn должен неплохо подойти) и
> связать его со своим проектом без лишних деталей.
> 5 использовать более легкие фреймворки (sinatra, ...).
>
> Как вариант можно конечно попробовать развернуть это все и
> протестировать (возможно это будет сделано в будущем).
>
> Да и сразу еще один вопрос - про шардинг. Кто чем пользуется (в
> продакшн ессно) и каковы впечатления?
>
> Буду благодарен, если поделитесь любым положительным опытом.
>
> --
> --
> Данное сообщение отправлено Вам, так как Вы являетесь подписчиком группы "RubyOnRails to russian" на группах Google.
> FAQ группы находится по адресу: http://ru.wikibooks.org/wiki/RubyFAQ
>
> Для того, чтобы отправить сообщение в эту группу, пошлите его по адресу
> ror2ru@googlegroups.com
> Чтобы отменить подписку на эту группу, отправьте сообщение по адресу: ror2ru-unsubscribe@googlegroups.com
> Дополнительные варианты находятся на странице группы http://groups.google.com/group/ror2ru?hl=ru
--
Alex V. Dmitriev
Jabber/GTalk/MSN/AIM: rene.dekart@gmail.com
Skype: rene-dekart
Blog: http://railorz.ru
--
--
Данное сообщение отправлено Вам, так как Вы являетесь подписчиком группы "RubyOnRails to russian" на группах Google.
FAQ группы находится по адресу: http://ru.wikibooks.org/wiki/RubyFAQ
Для того, чтобы отправить сообщение в эту группу, пошлите его по адресу
ror2ru@googlegroups.com
Чтобы отменить подписку на эту группу, отправьте сообщение по адресу: ror2ru-unsubscribe@googlegroups.com
Дополнительные варианты находятся на странице группы http://groups.google.com/group/ror2ru?hl=ru
Комментариев нет:
Отправить комментарий