Сервер HTTP Apache - Как определить на сервере если законченная загрузка и который файл?

Ну, так как Вы спросили, когда я думаю 'память на ленте', я думаю 'pain-in-the-ass память только для записи'. Я полностью признаю, что это, вероятно, очень несправедливо из меня, но это - моя ассоциация, и у меня всегда были бы данные по диску, учитывая опцию.

3
задан 3 July 2009 в 19:45
7 ответов

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

10
ответ дан 3 December 2019 в 04:42

80-е TRS получили верную мысль, и я определенно рекомендую спуститься по тому маршруту. Если Вы - тупик при ожидании, пока передача не закончила, то рассматривает использование lsof определить, когда ни у кого нет открытого файла. Так, что-то как:

for file in /directory/full/of/zips/*.zip; do
  if [ -z "$(lsof $file)" ]; then
    # Nobody's reading it, delete
    rm $file
  fi
done
3
ответ дан 3 December 2019 в 04:42

Первым путем я вижу, должен проанализировать результат состояния сервера, чтобы знать, запустилась ли загрузка. Когда загрузка запустилась, можно удалить файл как сказанный TRS-80. Но я не рекомендовал бы что, потому что, если Вы клиент получили разъединение по какой-либо причине, он не будет возможен перезапустить загрузку. Таким образом, я проанализировал бы файл журналов для знания, когда файл был загружен. Запись в файле журнала не будет добавлена, непока связь с клиентом не закрывается. В файле журнала у Вас будет количество октета подаваемым клиенту так, чтобы можно было соответствовать размеру файла, чтобы быть уверенными, что он имеет, загружают целый файл.

1
ответ дан 3 December 2019 в 04:42

Это не категорический ответ, но как я сначала думал бы о занятии этим.

Я запускал скрипт каждый час. Этот сценарий перечислил бы все имена файлов в исходной папке Zip. Я затем заставил бы сценарий прочитывать журналы Apache для некоторой записи Завершения Передачи, соответствующей текущему имени файла. Если существует запись в журнале соответствия, удалите файл. В противном случае затем перейдите на следующее имя файла.

0
ответ дан 3 December 2019 в 04:42

Я предложил бы более изящное решение:

Apache способен к условному входу, и журнал может быть произведен к процессу. Таким образом, можно сделать что-то как:

SetEnvIf Request_URI "^/path/to/files/.*\.zip$" deletefile
CustomLog "|/path/to/program" "%r" env=deletefile

Программа получит имя файла после того, как каждый запрос будет закончен и сможет удалить его:

#!/usr/bin/perl
$| = 1;
while (<STDIN>) {
    unlink($_);
}

Вы могли даже использовать "%> s %r" как формат и удалять, только если состояние 200.

1
ответ дан 3 December 2019 в 04:42

Как другая опция - у меня есть подобный процесс, но я ничего не пишу в диск, поскольку я служу архивам мульти-ГБ.

Вместо этого я просто испускаю соответствующие HTTP-заголовки (включая Довольное Расположение, чтобы установить имя файла) и затем передать для архивирования (или tar) с соответствующими флагами для них для записи в stdout.

Что касается масштабирования - я имею большие файлы, но не отправляю их настолько часто. Я действительно прохожу 'хороший', таким образом, я могу отбросить приоритет процесса архивирования.

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

0
ответ дан 3 December 2019 в 04:42

На этой странице существует некоторая действительно большая информация. Я не чувствую себя стоящим, чтобы даже вносить из-за ума подхода 80-х TRS. Что касается меня, хотя то, что Вы служите огромным динамично сгенерированным файлам, но волнуетесь по поводу дискового пространства. Я хочу удостовериться, что Вы мудры со своим самым драгоценным ресурсом, RAM.

Во-первых, необходимо удостовериться, что Вы делаете вещи таким способом, которым Apache может использовать sendfile. Я был бы также обеспокоен генерацией файла с любым основанным на модуле прикладным уровнем, mod_php, mod_python, или обратный прокси Полукровке/Ruby on Rails. Вы действительно должны быть осторожными этого. Я не знаю много о Вашей установке, но инстинкт говорит мне, что Вы должны:

  1. Используйте рабочего MPM вместо Предварительного ветвления
  2. Если использование Python видит: WSGI При использовании PHP видят: FastCGI, Если направляющие видят: Пассажир
  3. Не позволяйте пользователям запросить, какие триггеры поколение файла - делает доставку. Используйте подобный AJAX шаблон для:
    1. Поколение очереди файла
    2. Проверяйте периодически на завершение
    3. Журнал, который начала загрузка (хорошо, это собирается),
    4. Начните загружать
  4. Однако не полагайтесь на клиент, чтобы указать Вам, что необходимо удалить файл. Я периодически использовал бы lsof на "начатый журнал" для удаления.

Конечно, в моей промышленности мы всегда должны волноваться о способности масштабироваться. Вы не можете заботиться.

0
ответ дан 3 December 2019 в 04:42

Теги

Похожие вопросы