Доброго времени суток!

Предо мной стоит задача, отдавать файлы через PHP (защищая их от прямого скачивания). Нашел множество решений, большинство из которых, по мнению "специалистов" (о уровне их квалификации я судить не могу) - потребляет очень много оперативной памяти. То есть, файл перед "отдачей" загружается в память целиком. Соответственно, если у нас лежит 10 файлов по 1Гб и их необходимо будет отдать все одновременно... Память на сервере, как я понял, может внезапно кончиться.

Нашел вот такой способ, который, по идее вроде бы как кушает памяти поменьше:


Подскажите пожалуйста, насколько затратный по объёму ОЗУ такой способ, хотя бы примерно?

Возможно есть какие-то более оптимальные варианты, для экономии оперативной памяти? 

сделайте тестовый замер с помощью memory_get_usage и посмотрите сколько есть

отдача скриптом файла потребляет столько же оперативы сколько занесется в буфур при чтении +- еще на работу скрипта.





 

Sanchezzz, шикарно, спасибо! Сегодня протестирую!

Поправил код:


Результаты:
1. Запуск скрипта ~300Кб
2. Внутри while ~2Кб
3. После while ~2Кб

Что-то мне подсказывает, что я что-то не так делаю... или буфер ("буфер" = объём "отъеденой" памяти) на самом деле может быть размером 1.5-2Кб для файла в ~700Мб?

WolfAlone, Смешнее всего не то, что копирование файла функцией stream_copy_to_stream не занимает дополнительный объем. Смешно то, что после этой функции куда-то деваются лишние 2k памяти. Либо это баг в php, либо погрешностьизмерения   

Впрочем, кто-то, судя по комментариям уже натыкался на такое поведение этой функции.

И да! При копировании файлов реально используется только небольшой буфер в памяти, через который собственно копирование и происходит. Как правило, при обычной реализации, обычным в меру адекватным программистом.

ksnk, правильно ли я понял, что при таком методе отдачи файлов ("через скрипт", например для подсчёта кол-ва скачиваний файла), обём "отъедаемой" памяти для одного файла, для грубого расчёта нагрузки, можно брать величину 512Кб (вообще, в результате работы того скрипта, если сильно округилть, получиться ~350Кб ОЗУ, но для "надежности", будем считать, что условно, такой скрипт кушает 0.5Мб оперативки в течение всего времени затраченного на отдачу файла)?

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

Это сообщение отредактировал(а) WolfAlone - 28.8.2012, 23:43

Посмотрите на функцию readfile. Это, случайно, не то, что нужно? 

Для чего ведутся такие расчеты? Для определения нужных параметров в php.ini или для определения нужных объемов памяти в виртуальной машине?

ksnk, подобные расчёты ведутся для вычисления объёма оперативной памяти, необходимой на серверной (физической) машине. Хочу поставить отдельный сервер, в качестве централизованного файло-хранилища. Файлы размером от нескольких Кб до не более ~1Гб. Номинальная нагрузка на сервер (для расчёта) 1000 одновременно скачиваемых файлов 24х7.

Расчитать нужно, именно объём оперативной памяти, необходимый для этой задачи.

Интересен именно объём потребляемой оперативной памяти по двум причинам:
Основная причина: я думаю, что "раздача файлов" не потребляет большое кол-во процессорных ресурсов
Косвеная причина: если придётся делать уменьшенную копию аналогичного сервера (сервиса), например на VPS (для экономии денег), все провайдеры из тех, что мне встречались (XEN, VmWare), предоставляют в пользование 1-2 ядра от Xeon ~2.4ГГц. Основное отличие тарифов друг от друга заключается только в объёме оперативной памяти.



Внимательно изучил Вашу ссылку, посмотрел пример: Example #1 Forcing a download using readfile(). В принципе, это как раз то, что мне нужно. Вопрос сключительно в том, какой из методов отдачи файла будет кушать наименьшее кол-во ОЗУ, растёт ли потребление ОЗУ пропорционально размеру файла (в каждом конкретном случае) и какой примерно объём ОЗУ выделяется (затрачивается) на скрипт отдающий файл.

Это сообщение отредактировал(а) WolfAlone - 29.8.2012, 11:40

WolfAlone, а погуглите.
И даже по этому форуму.

Где-то были упоминания о том, как создавать временные ссылки через скрипт и отдавать скачивание на откуп тому же nginx
то ли Feldmarshal, то ли Ипатьев про это писали.

Безусловно есть альтернативные решения! Можно, например, написать на С/С++ маленькую программку, контроллируя выделяемую ей (ею) память буквально до килобайта, и с помощью программы отдавать файлы, но прежде всего, я хотел бы рассмотреть самое стандартное (простое) решение.

Это сообщение отредактировал(а) WolfAlone - 29.8.2012, 14:27

Самое стандартное(с точки зрения php) решение - readfile. но для таких условий 

оно не подойдет

Нормально по производительности такие задачи решаются только созданием временных "жестких" ссылок на скачивание файла. Сама скачка файла передоверяется в дальнейшем какому-нибудь nginx'у. 

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

Какая примерно нагрузка (потребление ресурсов машины) будет при одновременном скачивании 10-и, 100-а файлов, размером допустим 10Мб? Где примерно пролегает граница, между тем когда "разумно" отдавать файлы скриптом и когда такой подход уже не оптимален, в виду каких-то причин? Как определить эту "границу"?

1000 одновременно отдаваемых скриптом файлов - это 1000 одновременно запущенных версий PHP и 1000 соответствующих им веток апача, обслуживающих связь с клиентской машиной. Насколько бы оптимально не были выставлены запросы на память и ресурсы - никакой одинокий сервер с такой нагрузкой не справится. И апач и php довольно тяжелые продукты и запускать их в массовом порядке не рекомендуется.


Зачем определять такую границу? Ну вообразите, что при 12 одновременных загрузках сервер еще шевелится, а 13 его роняет. Какой выход? Блокировать юзеров свыше 12-ти? Или пусть лучше файлы отдает сапожник nginx, который для этого ( эффективной работы со статическим контентом) специально и создавался? 

Такую границу, нужно определить для того, что бы знать, в каких случаях нужен nginx, а в каких нет. Например, в первой "версии" (основной) предполагается пиковая нагрузка в 1000 скачиваний - 24x7 - файл(ы, ов) по 100Мб каждый (это для расчёта). А если такой сервис уменьшить в масштабе, допустим в N раз? И у нас получиться пиковая нагрузка: 10 файлов, по 10Мб, 1000 скачиваний в сутки (в общей сложности). И, при таком раскладе ставить Nginx не имеет особого смысла (этого я не утверждаю, я лишь привожу пример/предположение). Вот, для этого я и хочу определить подобные границы.

X-Accel-Redirect
Далее пишем конфиг для никса где храним файлы и как будем обрабатывать все это


далее создаем скрипт логики который будет это дело обслуживать и перенаправлять куда надо на файл


/download/ключ/имя_файла


Полноценная отдача файлов для не разумных пределов через чистый PHP долго не живет



Это сообщение отредактировал(а) Sanchezzz - 29.8.2012, 17:15

наконец-то!
я уже расстроился и собирался напоминать про X-SendFile   

Всем большое спасибо! Пытаюсь детально разобраться в вопросе. Позже отпишу о результатах.

WolfAlone,  добрый день!

В надежде на то, что Вы "детально разобрались в вопросе", и, поскольку, это единственно более-менее "свежий" топик близкий к той проблеме, что меня занимает, решился здесь задать вопрос (хаоса в Вашу тему не внесу, т.к. вопрос очень близкий, и заводить новую тему показалось неправильным  ).

Хостинг, услугами которого я сейчас пользуюсь, отдает видео с "Content-Type: application/octet-stream". Для большинства браузеров, это не представляет проблемы, но не для IE. Пользовательские MIME-types запрещены, нет .htaccess (сервер Apache/1.3.37 (Unix)) и, соответственно, всего, что с ним могло бы быть связано. PHP 5.3.6 установлен не модулем Apache, а FastCGI. Техподдержка MIME-types менять не будет, т.е. вообще ничего не будет делать - славный такой саппорт.

Пытался заменить заголовки для клиента пользователя таким образом:

На локальном сервере работает, но не на хосте. ETag, в принципе, лишний, но оставил, чтобы показать, что пробовал даже самые бредовые варианты. Более того, при попытке раздачи файла через этот скрипт, даже те браузеры, что раньше легко воспроизводили контент, стали выдавать "no video with supported format and MIME type found". Причем, Content-Type: video/mp4 правильный, и размер файла Farebug  показывает, т.е. браузер его загрузил, но воспроизводить не пытается.
Вопрос первый: как раздать видео клиенту, указав правильный mime-type?
Вопрос второй: как заставить скрипт выдавать клиенту код 304? (гонять файлы большого размера, если они есть в кеше, не гуд  )
apache_request_headers для чтения заголовков клиента использовать не могу, т.к. FastCGI и PHP 5.3.6 (не 5.4). В Глобальных переменных нужные данные не присутствуют ($_SERVER). Хостер разрешает Perl, CGI-BIN, но дела с ними не имел и возможностей не знаю.

Буду рад любым идеям.

Вопрос, для меня, давно перестал быть актуальным, но допускаю, что может кому-нибудь и пригодится его решение.
Проблема, как часто это бывает, состояла в недостаточной внимательности и пренебрежении системным подходом. phpinfo() показала, что хостером запрещена директива allow_url_fopen, поэтому скрипт просто не мог открыть файл для чтения. Но библиотека CURL, к счастью, оказалась включена. Пока администрации хостинга не придет в голову новая фантазия, скрипт, подающий IE заголовки благополучно работает.