Поэтому я экспериментирую с ситуацией, когда я хочу передавать огромные файлы со стороннего URL-адреса через мой сервер запрашивающему клиенту.
До сих пор я пытался реализовать это с помощью Curb или Net::HTTP, придерживаясь стандартной практики Rack для "каждого" тела ответа, например:
class StreamBody
...
def each
some_http_library.on_body do | body_chunk |
yield(body_chunk)
end
end
end
Однако я не могу заставить эту систему использовать меньше, чем, скажем, 40% ЦП (на моем MacBook Air). Если я попытаюсь сделать то же самое с Goliath, используя em-synchrony (как рекомендуется на странице Goliath), я смогу снизить использование ЦП примерно до 25% ЦП, однако мне не удастся сбросить заголовки. Моя потоковая загрузка «зависает» в запрашивающем клиенте, и заголовки появляются после того, как весь ответ был отправлен клиенту, независимо от того, какие заголовки я предоставляю.
Прав ли я, думая, что это один из тех случаев, когда Ruby просто изумительно отстой, и вместо этого мне приходится обращаться к go и nodejs мира?
Для сравнения, в настоящее время мы используем потоковую передачу PHP из CURL в выходной поток PHP, и это работает с очень небольшой нагрузкой на ЦП.
Или есть решение для проксирования вверх по течению, которое я мог бы попросить обработать мои вещи? Проблема в том, что я хочу надежно вызвать функцию Ruby после того, как все тело будет отправлено в сокет, и такие вещи, как прокси-серверы nginx, не сделают этого за меня.
ОБНОВЛЕНИЕ: я попытался провести простой тест для HTTP-клиентов, и похоже, что большая часть ЦП используется библиотеками HTTP-клиентов. Существуют тесты для HTTP-клиентов Ruby, но они основаны на времени получения ответа, тогда как использование ЦП никогда не упоминается. В моем тесте я выполнил потоковую загрузку HTTP, записав результат в /dev/null, и получил стабильную загрузку ЦП на 30-40%, что примерно соответствует загрузке ЦП, которую я имею при потоковой передаче через любой обработчик Rack.
ОБНОВЛЕНИЕ: оказалось, что большинство обработчиков Rack (Unicorn и т. д.) используют цикл записи() в теле ответа, что может привести к ожиданию занятости (с высокой загрузкой ЦП), когда ответ не может быть записан быстро. довольно. Это можно до некоторой степени смягчить, используя rack.hijack и записывая в выходной сокет, используя write_nonblock и IO.select (удивлен, что серверы не делают этого сами по себе).
lambda do |socket|
begin
rack_response_body.each do | chunk |
begin
bytes_written = socket.write_nonblock(chunk)
# If we could write only partially, make sure we do a retry on the next
# iteration with the remaining part
if bytes_written < chunk.bytesize
chunk = chunk[bytes_written..-1]
raise Errno::EINTR
end
rescue IO::WaitWritable, Errno::EINTR # The output socket is saturated.
IO.select(nil, [socket]) # Then let's wait on the socket to be writable again
retry # and off we go...
rescue Errno::EPIPE # Happens when the client aborts the connection
return
end
end
ensure
socket.close rescue IOError
rack_response_body.close if rack_response_body.respond_to?(:close)
end
end
