Как стать автором
Обновить

Комментарии 13

Не уверен, что когда-нибудь придется загружать 14Гб файлы, но спасибо.
Я тоже изначально такого не предполагал, но тут потребовалось давать ссылки на скачивание файлов логов, и кое-где у нас ротируемые файлы логов имеют размеры по 12-14Gb.
Логи, тесты, — это от лукавого, только время зря терять :)
Кстати, проблемы со скачиванием файлов начинаются где-то от 512Mb. Да и CPU грузится лишний раз.
Неделя Ruby?) Ну пожалуйста пусть это будет так, пусть это будет так, пусть это будет так.
non-stop!
Всеми конечностями присоединяюсь!
Советую чуть-чуть дальше пойти и в production просто выдавать HTTP заголовок X-Sendfile ( Apache2 ) или
x-accel-redirect — для nginx. Прирост скорости ( и уменьние загрузки ), по моему опыту, просто сногсшибательные.
О подобном решении написано в постскриптуме. Для бэкэнд-решений часто не подходит.

Во-первых, некоторые сервисы не должны зависеть от внешних пакетов, включая nginx. Ибо ставятся на самые различные машины.

Во-вторых, если сервис использует sendfile, то уже не имеет значения, чью работу он делает, ибо работа перекладывается на операционную систему;

В-третьих, если надо отдавать файлы из различных локаций, то nginx тут уже не спасет, ибо для него пришлось бы динамически генерировать и перечитывать конфигурацию (читаем документацию по X-Accel-Redirect).
А зачем выдавать такие большие файлы через Ruby? Чем ngnix не нравится, он как раз для раздачи статики разрабатывался.
Ни чем не не не нравиться, просто всплыла вот такая лажа синатры в связке с webrick и отписали что-да как.
Неужели неинтересно? Не ngnix«ом же единым, какая бы няшка он не был.
Заметка интересная. Но я бы тоже не стал отдавать файл прямо из приложения. Лучше это поручить прокси-серверу. Не обязательно nginx. Но альтернатив я, честно говоря, не вижу.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Изменить настройки темы

Истории