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

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

Оно конечно в целях самообучения конечно классно, но для продакшена уверен — положет сервер. Насколько я знаю — тоже самое можно реализовать через проксирующий фронт-энд, например nginx
Безусловно. Однако эта статья написана на случай, в котром нет возможности приобрести сервер, а необходимость в искусственных ограничениях есть.
Это 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)

Собственно да, свой контент (пару файлов там) отдавать то никто не запретит, но в остальном за сервисы файлораздачи хостеры по головке не гладят.
Да, конечно-же. Речь идет именно о «пару файлов там». (:
Сервис файлораздачи, на обычном хостинге, и не организуешь в следствии сильно ограниченного дискового пространства.
Да конечно, вон какой-нить валуехост легко даст гига 3, агава вон 25 вообще, этого вполне достаточно чтобы положить свежий дистрибутив квипа, несколько образов убунты и еще с десяток очень нужных всем файлов :)
С какой-то стороны это верно. (-:
НЛО прилетело и опубликовало эту надпись здесь
Не внушает что-то он доверия.
НЛО прилетело и опубликовало эту надпись здесь
Имхо логику надо немного подправить:
Если у пользователя есть активные подключения — не надо «спать», надо закрывать новое подключение, а не «подвешивать» его, долбясь в БД каждую секунду.
Поддерживаю и предлагаю, по возможности, развить эту ветку.
«Сон» был организован для того, чтобы даунлоад-менеджеры определяли поддержку докачки. Считаю организацию оптимальной для решения задачи. Я ошибаюсь?
представь — я качаю файл регетом, он открывает 20 соединений.
что получается — первое соединение качает файл, остальные 19 висят и создают нагрузку 19 запросов к БД в секунду. И это только от одного пользователя!
Имхо состояние надо хранить не в БД, а в сессии и лишние коннекты рубить, а не висеть.
А если даунлоад-менеджер не поддерживает куки? Тогда такой вариант провалится.
Возможно сохранять файл с именем — IP-адреса. В последсвии проверять: если файл существует, значит соединение уже естановлено, если отсутствует, то создавать и приступать к отдаче.
ну здесь надо понять, что важнее, если ограничение, то тогда огнраничение по ip (оптимальнее всего тогда пихать в memcache)
Memcache — PECL-овское расширение PHP, которое не поставляется вместе с PHP, вследствии отсутствует на виртуальном хостинге.
Повторюсь, что данный пример расчитан на случай, в котором возможность приобрести сервер — отсутствует.
Как учебный пример и описание реализации идеи — очень хорошо.
Как практическая вещь — никуда не годно (по производительности)
В целом плюс :)
Не надо перекладывать на приложение то, чем должен заниматься вебсервер. Если проект не перерос шаред хостинг, то и ограничение там не нужны :) Даже 10 пользователей качающих одновременно фаил в несколько потоков положат все процессы апача.
Вынужден несогласиться. Тестировал на виртуальном хостинге мастерхоста. Качал в 20 пользователей, использовал Download Master (он пытался создать по 8 потоков на каждое скачивание), размер скачиваемого файла 100 Мб. Никаких проблем не возникло.
использование в коде переменной с именем $speed некорректно и вводит в заблуждение новичков. не лукавьте и назовите её $bytes_per_2seconds
хотя поторопился — не 2seconds…
но не $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 это не скорость отдачи, а некий коэффициент, который нелинейно на неё влияет.
То есть вы утверждаете что php будет ждать пока пользователь скачает блок данных, а лишь потом уйдёт в sleep и продолжит цикл?
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории