Действительно ли направляющие являются Металлическими (и Стойка) хороший способ реализовать API веб-сервиса интенсивного трафика?
Я работаю над очень типичным веб-приложением. Основной компонент пользовательского опыта является виджетом, который владелец сайта установил бы на их первой полосе. Каждый раз их размещенные на первой полосе загрузки, виджет говорит с нашим сервером и отображает некоторые данные, которые возвращаются.
Таким образом, существует два компонента к этому веб-приложению:
- фронтэнд UI, что владелец сайта использование для конфигурирования их виджета
- компонент бэкэнда, который отвечает на веб-вызов API виджета
Ранее у нас было все это выполнение в PHP. Теперь мы экспериментируем с направляющими, который является фантастическим для № 1 (фронтэнд UI). Вопрос состоит в том, как сделать № 2, заднее обслуживание информации о виджете, эффективно. Очевидно, это - намного более высокая загрузка, чем фронтэнд, так как это называют каждый раз размещенными на первой полосе нагрузками на один из веб-сайтов наших клиентов.
Я вижу два очевидных подхода:
A. Параллельный Стек: Настройте параллельный стек, который использует что-то другое, чем направляющие (например, наш старый основанный на PHP подход), но получает доступ к той же базе данных как фронтэнд
B. Металл направляющих: Используйте Металл/Стойку направляющих, чтобы обойти механизм маршрутизации направляющих, но сохранить респондента вызова API в рамках приложения для направляющих
Мой основной вопрос:
- Действительно ли Направляющие/Металл являются разумным подходом для чего-то вроде этого?
Но также и...
- Будет издержки загрузки среды направляющих все еще быть слишком тяжелыми?
- Существует ли способ стать еще ближе к металлу с направляющими, обходя большую часть среды?
- Производительность Направляющих/Металла приблизится к перфекту подобной задачи на прямом PHP (просто ищущий приблизительную оценку здесь)?
И...
- Существует ли вариант 'C', который был бы намного лучше и, чем A и, чем B? Таким образом, что-то прежде, чем идти в длины кода C, скомпилированного в двоичный файл и установленного как nginx или апачский модуль?
Заранее спасибо за любое понимание.
3 ответа
Я бы начал переносить функциональность в Rack / Metal, только если бы я определил точную причину любой возникающей проблемы с производительностью. В частности, в последних версиях Rails (в частности, 3) и Ruby, стек сам по себе очень редко является узким местом. Начните измерения, получите реальные показатели и разумно оптимизируйте.
Мое практическое правило: если у вас нет показателей, вы не можете разумно рассуждать о своей проблеме с производительностью и о любом возможном решении.
По моему опыту, проблемы почти всегда связаны с представлениями и базой данных.
Как предполагает Райан, кэширование может быть невероятно эффективным ... вы даже можете переместить свою архитектуру на использование обратного прокси перед стеком запросов Rails, чтобы обеспечить еще больше возможностей. Кэш, подобный Varnish, обеспечивает невероятно высокую производительность. Rails имеет встроенную поддержку etags и заголовков HTTP для упрощения решения обратного прокси.
Еще нужно взглянуть на сам слой БД. Кеш здесь может иметь большое значение, но и здесь может быть полезна некоторая оптимизация. Убедитесь, что вы разумно используете Active Record: include - отличный шаг, чтобы избежать ситуаций с запросами N + 1, но в Rails есть фантастическая поддержка для удаления memcached в стек с небольшой конфигурацией или без нее, что может обеспечить отличный прирост производительности.
PHP загружает всю среду по каждому запросу. В производственном режиме Rails загружает всю среду один раз при запуске сервера. Безусловно, существует достаточное количество кода Ruby, выполняемого во время обычных вызовов контроллера. Однако в производственном режиме ни один из этих кодов не связан с загрузкой среды. А использование Rails Metal вместо обычного стека контроллеров Rails удаляет ряд этих слоев, давая несколько дополнительных миллисекунд времени, сэкономленных на запрос.
Не самый подробный ответ, но:
Я бы не стал использовать для этого металл, вместо этого я бы использовал кэширование страниц. Таким образом, запросы будут обслуживаться веб-сервером и никаких динамических языков вообще. Когда вы создаете ресурс, очистите соответствующую индексную страницу. Очень простой пример:
class PostsController < ApplicationController
caches_page :index
def index
@posts = Post.all
respond_to do |format|
format.html
format.xml
end
end
def create
@post = Post.new(params[:post])
respond_to do |format|
if @post.save
expire_page :action => :index
format.html { redirect_to posts_path }
format.xml
else
format.html { render :action => "new" }
end
end
end
end
Для получения дополнительной информации читайте руководство по кэшированию.