Ограничение скорости скачивания файлов средствами PHP

[Silverstorm]

Оно конечно в целях самообучения конечно классно, но для продакшена уверен — положет сервер. Насколько я знаю — тоже самое можно реализовать через проксирующий фронт-энд, например nginx

[iMaster]

Безусловно. Однако эта статья написана на случай, в котром нет возможности приобрести сервер, а необходимость в искусственных ограничениях есть.

[alfa]

Тогда лучше брать vds, nginx sysoev.ru/nginx/docs/http/ngx_http_core_module.html#limit_rate и sysoev.ru/nginx/docs/http/ngx_http_limit_zone_module.html для этих целей лучше, иначе очень быстро убьете апач.

[iMaster]

Это nginx. На тривиальном хостинге, к сожалению, его нет.

[alfa]

Дык на шареде еще быстрее трахнут за сервис файлораздачи :) разве не так?

[iMaster]

Если правильно понял, то «шареде» — имеется ввиду бесплатный, так? На бесплатном, считаю, необходимость в раздаче вряд-ли появится, а вот используя платный хостинг можно, например, раздавать какой-либо авторский контент, при этом отдавать его очень быстро — за деньги, а бесплатно — медленно. При этом не имея финансовой возможности купить/арендовать полноценный сервер.

[alfa]

нет, не бесплатный, а shared хостинг (http://ru.wikipedia.org/wiki/%D0%92%D0%B8%D1%80%D1%82%D1%83%D0%B0%D0%BB%D1%8C%D0%BD%D1%8B%D0%B9_%D1%85%D0%BE%D1%81%D1%82%D0%B8%D0%BD%D0%B3)

Собственно да, свой контент (пару файлов там) отдавать то никто не запретит, но в остальном за сервисы файлораздачи хостеры по головке не гладят.

[iMaster]

Да, конечно-же. Речь идет именно о «пару файлов там». (:

[iMaster]

Сервис файлораздачи, на обычном хостинге, и не организуешь в следствии сильно ограниченного дискового пространства.

[alfa]

Да конечно, вон какой-нить валуехост легко даст гига 3, агава вон 25 вообще, этого вполне достаточно чтобы положить свежий дистрибутив квипа, несколько образов убунты и еще с десяток очень нужных всем файлов :)

[iMaster]

С какой-то стороны это верно. (-:

[iMaster]

Не внушает что-то он доверия.

[romka777]

Имхо логику надо немного подправить:
Если у пользователя есть активные подключения — не надо «спать», надо закрывать новое подключение, а не «подвешивать» его, долбясь в БД каждую секунду.

[iMaster]

Поддерживаю и предлагаю, по возможности, развить эту ветку.
«Сон» был организован для того, чтобы даунлоад-менеджеры определяли поддержку докачки. Считаю организацию оптимальной для решения задачи. Я ошибаюсь?

[romka777]

представь — я качаю файл регетом, он открывает 20 соединений.
что получается — первое соединение качает файл, остальные 19 висят и создают нагрузку 19 запросов к БД в секунду. И это только от одного пользователя!
Имхо состояние надо хранить не в БД, а в сессии и лишние коннекты рубить, а не висеть.

[iMaster]

А если даунлоад-менеджер не поддерживает куки? Тогда такой вариант провалится.
Возможно сохранять файл с именем — IP-адреса. В последсвии проверять: если файл существует, значит соединение уже естановлено, если отсутствует, то создавать и приступать к отдаче.

[romka777]

ну здесь надо понять, что важнее, если ограничение, то тогда огнраничение по ip (оптимальнее всего тогда пихать в memcache)

[iMaster]

Memcache — PECL-овское расширение PHP, которое не поставляется вместе с PHP, вследствии отсутствует на виртуальном хостинге.
Повторюсь, что данный пример расчитан на случай, в котором возможность приобрести сервер — отсутствует.

[duncan]

Как учебный пример и описание реализации идеи — очень хорошо.
Как практическая вещь — никуда не годно (по производительности)
В целом плюс :)

[mgyk]

Не надо перекладывать на приложение то, чем должен заниматься вебсервер. Если проект не перерос шаред хостинг, то и ограничение там не нужны :) Даже 10 пользователей качающих одновременно фаил в несколько потоков положат все процессы апача.

[iMaster]

Вынужден несогласиться. Тестировал на виртуальном хостинге мастерхоста. Качал в 20 пользователей, использовал Download Master (он пытался создать по 8 потоков на каждое скачивание), размер скачиваемого файла 100 Мб. Никаких проблем не возникло.

[zerkms]

использование в коде переменной с именем $speed некорректно и вводит в заблуждение новичков. не лукавьте и назовите её $bytes_per_2seconds

[zerkms]

хотя поторопился — не 2seconds…
но не $speed явно.

[iMaster]

Почему-же не $speed? Эта переменная отражает именно скорость (байты в секунду).

[zerkms]

попробуйте посчитать с 128, 512, 5мбит итоговую скорость, которую будет получать клиент.

[iMaster]

Сколько байт в $speed укажите, столько и будет получать в секунду если, разумеется, канал позволяет.

[zerkms]

ну ладно, раз уж вам лень, посчитаем вместе :-)

если у пользователя канал 128кбит/с. то при указанном ограничении в 512кбит/с мы получим:

4 секунды скачивается заданные 512к, пауза 1 сек. получаем 5сек. итого 512кбайт качалось 5 секунд. скорость 512/5 = 102,4

256кбит/с: 512 / (2 + 1) = 170,(6)

512кбит/с: 512 / (1 + 1) = 256

1024кбит/с: 512 / (0.5 + 1) = 341.(3)

5120кбит/с: 512 / (0.1 + 1) = 465,45454545454545454545454545455

как можно заметить — на небольших скоростях получаем неплохие потери. такие же потери мы наблюдаем даже на 512 и мегабите… более того — даже на 5мбит'ах мы не получаем заявленных в скрипте 512кбит/с

вердикт: $speed это не скорость отдачи, а некий коэффициент, который нелинейно на неё влияет.

[mamontoff]

То есть вы утверждаете что php будет ждать пока пользователь скачает блок данных, а лишь потом уйдёт в sleep и продолжит цикл?