Обзор

Мое веб-приложение позволяет пользователям загружать файлы, которые хранятся на s3, через мои серверы. Когда пользователь запрашивает файл, мой веб-сервер извлекает его из s3, а затем отправляет его клиенту.

Недавно я развернул балансировщик нагрузки, сделав мои текущие настройки следующим образом:

Обратите внимание, что в настоящее время у меня есть только один веб-сервер для упрощения отладки.

Первоначальная проблема

После того, как я развернул балансировщик нагрузки, я заметил, что загрузка больших файлов (размером более 4 МБ) завершалась ошибкой с таймаутом шлюза 504 через 60 секунд.

Я просмотрел журнал ошибок балансировщика нагрузки nginx для сайта и увидел несколько таких записей:

[error] 11770#11770: *40 upstream timed out (110: Connection timed out) while reading response header from upstream, client: XXXX, ...

Когда я посмотрел журнал ошибок nginx веб-сервера для сайта, я увидел похожие записи:

[error] 6632#6632: *41 upstream timed out (110: Connection timed out) while reading response header from upstream, client: ...
[error] 6632#6632: *85 upstream timed out (110: Connection timed out) while reading response header from upstream, client: ...
[error] 7163#7163: *41 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: ...
[error] 7505#7505: *41 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: ...
[error] 7505#7505: *91 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: ....

И глядя на журналы ошибок php-fpm на моем веб-сервере:

WARNING: [pool www] child 3011, script '/home/forge/XXX.com/public/index.php' (request: "GET /index.php") execution timed out (64.950545 sec), terminating
WARNING: [pool www] child 3011 exited on signal 15 (SIGTERM) after 1140.059968 seconds from start
WARNING: [pool www] server reached pm.max_children setting (5), consider raising it
WARNING: [pool www] child 4260, script '/home/forge/XXX.com/public/index.php' (request: "GET /index.php") execution timed out (68.171099 sec), terminating
WARNING: [pool www] child 4260 exited on signal 15 (SIGTERM) after 160.005837 seconds from start
NOTICE: [pool www] child 4271 started

Я объяснил это тем, что у моих тайм-аутов выполнения php и тайм-аутов соединения nginx слишком мало, поэтому я увеличил их, выполнив следующие действия:

• На балансировщике нагрузки:
  • Добавить proxy_read_timeout 600s; в /etc/nginx/nginx.conf
• На веб-сервере:
  • В конфигурации сайта nginx я добавил fastcgi_read_timeout 600; в блок местоположения .php.
  • Добавлено max_execution_time = 600 и default_socket_timeout = 600 в конфигурацию php-fpm.
  • Добавлено request_terminate_timeout = 300 в /etc/php/7.0/fpm/pool.d/www.conf

Это в некоторой степени устранило мою первоначальную проблему, так как теперь я могу загружать файлы большего размера (проверено до 25 МБ).

Следующая проблема - медленные загрузки

После указанных выше изменений конфигурации я могу загружать файлы без тайм-аута, однако для начала загрузки требуется слишком много времени (~ 300 секунд), а сама загрузка идет медленно (небольшая проблема).

Процесс загрузки файла следующий:

• Клиент нажимает ссылку URI, которая попадает на мой сервер
• Мой веб-сервер обращается к базе данных и получает такую ​​информацию, как имя хешированного файла и путь к серверу БД.
• Затем веб-сервер извлекает файл из S3.
• Веб-сервер отвечает файлом как загрузкой на начальный запрос:

Для справки, на веб-сервере выполняется следующая функция:

public function show($projectID, $documentID, $revisionID, $fileID)
{
    $fileEntry = File::find($fileID);

    $path = $fileEntry->path();
    $file = Storage::get($path);
    $size = Storage::size($path);

    return Response::make($file, 200)
            ->header('Content-Type', $fileEntry->mime)
            ->header('Content-Disposition', 'attachment; filename="' . $fileEntry->original_filename . '"')
            ->header('Content-Length:', $size);
}

Я понимаю, что я дважды обрабатываю файлы и в будущем переключусь на подписанные перенаправления URL-адресов s3, но есть другие части приложения, где это не будет практично (захват коллекции файлов, архивирование и отправка клиенту) и, следовательно, будет хотел бы получить некоторое понимание.

Что могло быть причиной этой проблемы? Я не думаю, что когда-либо сталкивался с этой проблемой до развертывания балансировщика нагрузки.

Если я загружаю файл непосредственно из s3, время загрузки составляет лишь часть от общего времени при передаче через мой сервер, поэтому я не верю, что проблема заключается в двойной обработке. Это может быть связано с размером буфера или памяти?

Дополнительная информация:

• Кузница Laravel использовалась для обеспечения и серверов.
• Завершение SSL на балансировщике нагрузки
• Веб-приложение Laravel
• Все Linode размещены в сингапурском дата-центре
• S3 регион Сидней
• Проблемы наблюдались при крайне низкой посещаемости (до 1 клиента)