2016-11-11 4 views
1

Так что, возможно, это не очень хорошая практика, но на данный момент мое веб-приложение сосуществует со своим API в том же приложении/под тем же сервером. Мне интересно, есть ли способ ускорить процесс запросов сервера в этом случае?Одновременно отправляет и принимает запросы на локальный сервер Rails

Например, когда я посылаю запрос в API под тот же сервер, я использую:

require 'rest-client' 

tasks = RestClient.get 'localhost:8000/tasks', 
{ 
    content_type: :json, 
    accept: :json, 
"X-User-Email" => "[email protected]", 
"X-User-Token" => "blahblah" 
} 

Однако, иногда это занимает до смешного много времени, чтобы получить результат. Или это приводит к ошибке «Ошибка чтения данных с сервера». Мне интересно, если это потому, что сервер отправляет запросы самому себе и одновременно получает запросы от себя. Я пробовал открыть другой сервер на порту 8000, отправить запрос на сервер port 3000, и это намного быстрее. Является ли рельсы плохими при многопоточности?

$ rails s -p 8000 -P 42323 

Кроме того, если я обновилась страница порт сервера 8000 первый и отправить запрос, а затем обновить страницу порт сервера 3000 также будет намного быстрее. Это потому, что ответ был кэширован Rack?

P.S Извиняюсь, если неправильно использовал разные условия.

EDIT:

Я попытался отладки с API и контроллером приложения. Похоже, что большинство задержек происходит прямо перед тем, как на самом деле нажать на контроллер API. Выход сервера при отправке запроса из порта 8000 в порт 8000 API:

Started GET "/" for 127.0.0.1 at 2016-11-11 17:37:14 +0800 
    User Load (0.7ms) SELECT "users".* FROM "users" WHERE "users"."id" = $1 ORDER BY "users"."id" ASC LIMIT 1 [["id", 1234567]] 
Processing by TasksApplicationController#index as HTML 


Started GET "/tasks" for 127.0.0.1 at 2016-11-11 17:38:14 +0800 
Processing by APIController#index as JSON 

Итак, прежде чем начать загрузку маршрут для API, одна минута прошла!

Так что, если я попытался с двумя локальных серверов работает и отправить запрос из порта 3000 на порт 8000 сервера, это выход гораздо быстрее версии:

Started GET "/tasks" for 127.0.0.1 at 2016-11-11 17:42:25 +0800 
Processing by APIController#index as JSON 

Разница в том, что эта часть продукции ушел, и, таким образом, 1-минутная задержка исчезла.

Started GET "/" for 127.0.0.1 at 2016-11-11 17:37:14 +0800 
    User Load (0.7ms) SELECT "users".* FROM "users" WHERE "users"."id" = $1 ORDER BY "users"."id" ASC LIMIT 1 [["id", 1234567]] 
Processing by TasksApplicationController#index as HTML 

Почему, если я отправить запрос на порт 8000 сервера С 8000 сервера, у меня есть эта дополнительная часть, которая вызывает столько времени задержки?

ответ

0

Проблема, скорее всего, связана с тем, что вы используете Webrick в режиме разработки. Хотя Webrick является многопоточным сервером, а Rails многопоточен, в режиме разработки Rails использует промежуточное ПО Rake :: Lock, которое предотвращает одновременные запросы.

Чтобы включить WEBrick быть полностью многопоточными в режиме разработки, вы должны обезьяне-патч Middleware и удалить Rake :: Замок создание следующего Инициализатора:

конфигурации/Инициализатор/multithreaded_webrick.гь:

# Remove Rack::Lock so WEBrick can be fully multi-threaded. 
require 'rails/commands/server' 

class Rails::Server 
    def middleware 
    middlewares = [] 
    middlewares << [Rails::Rack::Debugger] if options[:debugger] 
    middlewares << [::Rack::ContentLength] 

    Hash.new middlewares 
    end 
end 

Edit я нашел оригинальный источник этой информации:

How rails resolve multi-requests at the same time?

В дополнение к Инициализатором вы можете также необходимо установить:

config.cache_classes = true 
config.eager_load = true 
+0

Я но пума как сервер для рельсов. Я думал, что пума построена для параллелизма? – whales

+0

Хмм да, пума должна быть параллельной для развития. У меня нет времени, чтобы на самом деле проверить это - нужно спешить на работу xD. Но что касается вашего вопроса - рельсы параллельны и да, он может запускать многопоточную разработку без каких-либо проблем - скорее всего, это проблема конфигурации. – David

+0

может стоить выводить отладочную информацию со стороны API, чтобы попытаться изолировать, если проблема связана с тем, что она попала в API в первую очередь или что-то внутри вызова API вызывает блокировку. – David

Смежные вопросы