Можно сделать автоматом - примерно так: ставим gitolite например, делаем 2 ветки - master и release. Права на master даем программистам. При пуше в мастер автоматом разворачиваем репозиторий на тот же сервер, который является develop/deploy сервером. Там происходит тестирование, отладка, вот это все.
В свою очередь, доступ к ветке release даем только себе/своему ПМ. Когда код приходит к стабильному состоянию, мерджим его в release и делаем пуш - по пушу в ветку release настраиваем деплой на боевой сервер, например при помощи rsync (он хорош тем, что заменяет файлы атомарно), ну или есть масса специализированных инстументов типа capistrano/jenkins.
@Marques Насчет "нельзя установку хидеров в http секцию вынести" - не вижу препятствий. Что с того, что gitlab работает без апача? Он что, от хидеров умрет что ли?
А, туплю же. Откуда там возмутся файлы, если до CMS запрос даже не долетает? Вам надо в локейшене со статикой сделать try_files - если нужный файл есть - отдаем, если нет - проксируем запрос на CMS. Справитесь?
Надо посмотреть в логе ошибок энджи, если он не находит файлов, будет писать ошибку. Скорей всего проблема именно в том, что у вас не сохраняются (не туда сохраняются) файлы после обработки. Энджи тут точно ни при чем.
Можно я, можно я? Мне видится отсев именно по ip верным потому, что за одним ip обычно находится некая общность людей, и скачанный ими всеми файл вполне может быть скачан только раз. И да, если брать вариант с защитой по куке, то все совсем плохо будет с накрутками. Есть прям специализированные боты для накруток скачиваний файлов.
Ниже предложено парсить логи на предмет размера скачанного файла - это дополнительно даст некоторую защиту от накрутки ботами, которые, как я подозреваю, не скачивают файл до конца.
Можно, лично я не против. Это очистит переменную $dead до пустого массива. Это видимо не совсем то, что вам надо. Вот если б вы поточнее написали, что вам надо - может помощь была бы более полезной.
Если проект высоконагружен, это еще не значит, что там не надо использовать слой абстракции БД, который будет заниматься экранированием. Если сделать это правильно, не будет никакого оверхеда. А если действительно хайлоад - то без key-value БД не обойтись - они реально круты в вопросах кеширования информации.
Ну, как я понял задачу топикстартера, ему нужна трансляция видео широкому кругу пользователей, а не видеонаблюдение. Это две разных, в общем случае не пересекающихся задачи. На данном сайте совершенно не тарифицируется исходящий трафик, между тем, он и составит в таком проекте наибольшую статью расхода.