Comments 30
Оно конечно в целях самообучения конечно классно, но для продакшена уверен — положет сервер. Насколько я знаю — тоже самое можно реализовать через проксирующий фронт-энд, например nginx
Безусловно. Однако эта статья написана на случай, в котром нет возможности приобрести сервер, а необходимость в искусственных ограничениях есть.
Тогда лучше брать 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 для этих целей лучше, иначе очень быстро убьете апач.
Это nginx. На тривиальном хостинге, к сожалению, его нет.
Дык на шареде еще быстрее трахнут за сервис файлораздачи :) разве не так?
Если правильно понял, то «шареде» — имеется ввиду бесплатный, так? На бесплатном, считаю, необходимость в раздаче вряд-ли появится, а вот используя платный хостинг можно, например, раздавать какой-либо авторский контент, при этом отдавать его очень быстро — за деньги, а бесплатно — медленно. При этом не имея финансовой возможности купить/арендовать полноценный сервер.
нет, не бесплатный, а 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)
Собственно да, свой контент (пару файлов там) отдавать то никто не запретит, но в остальном за сервисы файлораздачи хостеры по головке не гладят.
Собственно да, свой контент (пару файлов там) отдавать то никто не запретит, но в остальном за сервисы файлораздачи хостеры по головке не гладят.
UFO just landed and posted this here
Имхо логику надо немного подправить:
Если у пользователя есть активные подключения — не надо «спать», надо закрывать новое подключение, а не «подвешивать» его, долбясь в БД каждую секунду.
Если у пользователя есть активные подключения — не надо «спать», надо закрывать новое подключение, а не «подвешивать» его, долбясь в БД каждую секунду.
Поддерживаю и предлагаю, по возможности, развить эту ветку.
«Сон» был организован для того, чтобы даунлоад-менеджеры определяли поддержку докачки. Считаю организацию оптимальной для решения задачи. Я ошибаюсь?
«Сон» был организован для того, чтобы даунлоад-менеджеры определяли поддержку докачки. Считаю организацию оптимальной для решения задачи. Я ошибаюсь?
представь — я качаю файл регетом, он открывает 20 соединений.
что получается — первое соединение качает файл, остальные 19 висят и создают нагрузку 19 запросов к БД в секунду. И это только от одного пользователя!
Имхо состояние надо хранить не в БД, а в сессии и лишние коннекты рубить, а не висеть.
что получается — первое соединение качает файл, остальные 19 висят и создают нагрузку 19 запросов к БД в секунду. И это только от одного пользователя!
Имхо состояние надо хранить не в БД, а в сессии и лишние коннекты рубить, а не висеть.
А если даунлоад-менеджер не поддерживает куки? Тогда такой вариант провалится.
Возможно сохранять файл с именем — IP-адреса. В последсвии проверять: если файл существует, значит соединение уже естановлено, если отсутствует, то создавать и приступать к отдаче.
Возможно сохранять файл с именем — IP-адреса. В последсвии проверять: если файл существует, значит соединение уже естановлено, если отсутствует, то создавать и приступать к отдаче.
Как учебный пример и описание реализации идеи — очень хорошо.
Как практическая вещь — никуда не годно (по производительности)
В целом плюс :)
Как практическая вещь — никуда не годно (по производительности)
В целом плюс :)
Не надо перекладывать на приложение то, чем должен заниматься вебсервер. Если проект не перерос шаред хостинг, то и ограничение там не нужны :) Даже 10 пользователей качающих одновременно фаил в несколько потоков положат все процессы апача.
использование в коде переменной с именем $speed некорректно и вводит в заблуждение новичков. не лукавьте и назовите её $bytes_per_2seconds
хотя поторопился — не 2seconds…
но не $speed явно.
но не $speed явно.
Почему-же не $speed? Эта переменная отражает именно скорость (байты в секунду).
попробуйте посчитать с 128, 512, 5мбит итоговую скорость, которую будет получать клиент.
Сколько байт в $speed укажите, столько и будет получать в секунду если, разумеется, канал позволяет.
ну ладно, раз уж вам лень, посчитаем вместе :-)
если у пользователя канал 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 это не скорость отдачи, а некий коэффициент, который нелинейно на неё влияет.
если у пользователя канал 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 это не скорость отдачи, а некий коэффициент, который нелинейно на неё влияет.
Sign up to leave a comment.
Ограничение скорости скачивания файлов средствами PHP