Алексей Сундуков

Для общего понимания происходящего: Сколько выдержит мой сервер?

Может ли? Бесспорно да! На вскидку по приведенным симптомам я бы сказал, что там на входе стоит nginx с включенным limit_req. Выход прост - не превышать rate.

А что дает непосредственный запуск этой команды в консоле? Т.е. берем, тест команды выносим в переменную и логируем. Упавшие варианты запускаем руками.

$cmd = "ffmpeg -y -i $filepath -vf scale={$scale},setsar=1:1 -vcodec libx264 -b:v {$px['b']}k -acodec copy -threads ".(exec('nproc') - 1)." -bufsize 2000k -minrate 0k -maxrate 1450k " . $new_filepath;
echo $cmd;
exec($cmd, $output, $result_int);

Попробуйте через XPath.
Материал по теме: https://youtu.be/id_MNxmdRvk

Как правильно решать такие ошибки и вообще, как раз и навсегда решить эту проблему чтобы больше не сталкиваться с ней?

Подлючить хороший репозиторий:

sudo apt-get install software-properties-common
sudo add-apt-repository ppa:ondrej/php
sudo add-apt-repository ppa:ondrej/nginx-mainline
sudo apt update

Имея бинарный модуль, динамический so уже не нужен. Но как тогда отключать их автоматически чтобы каждый раз не править mods-available

Ни как если модуль скомпилирован статически. Поэтому важно использовать и правильно юзать готовый репозиторий.

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

Смотреть в сторону headless браузеров. Например, PhantomJS. Проще всего с ним работать через webdriver.

В документации же написано: php.net/manual/ru/function.move-uploaded-file.php

Опыт использования данной библиотеке говорит о медленной работе. Попробуйте использовать gs скрипт напрямую вот так: https://github.com/alekciy/pdf2image/blob/7f8856dc...

Вообще могу предложить готовый сервис конвертации. Базируется на Yii2, описание развертывание см. README.md. Если нужен не код, а быстро сконвертить пдфку, то у меня есть развернутый проект в виде готового сервиса. Если нужно, пишите в личку.

Из PHP можно через https://github.com/facebook/php-webdriver по WebDrive слать запросы в PhantomJS который все и сделает. Все что нужно, это написать правильные команды.

Нужно смотреть не вывод команды ps, а free -mh
Я думаю она покажет, что вся RAM заполнена и система свопит.

Поскольку как я понимаю такой вызов планируется делать через CLI, то возможно будет если запущенный скрип попадет на другое ядро.

Задать в формат лог файла переменную $upstream_response_time. У меня так в /etc/nginx/nginx.conf:

http {

    ##
    # Basic Settings
    ##
    log_format main     '$remote_addr:$remote_port - $remote_user [$time_local] $host "$request" '
                        '$status $body_bytes_sent "$http_referer" '
                        '"$http_user_agent" "$http_x_forwarded_for" $request_time-$upstream_response_time';
....
}

Тогда в логах есть в конце строки есть две цифры:

1. время отдачи данных клиенту
   
2. время генерации ответа PHP
   

Первая цифра позволяет выявлять "медленных" клиентов (когда первая цифра большая, а втора маленька). Вторая показывает как долго движок генерит страницы. Позволяет выявлять проблемы на бэкэнде. А вот такая команда позволяет посчитать медиану времени генерации страницы:

cat nginx_access.log | awk -F\" '{print $9}' | grep -v ".--$" | awk -F\- '{print $2}' | sort -n | awk '{all[NR]=$1;} END {print all[int(NR*0.5)]}'
1.391

Общее количество запросов на бэкэнд у меня сегодня:

cat nginx_access.log | awk -F\" '{print $9}' | grep -v ".--$" | wc -l
74557

Что в сумме мне говорит, что сегодня 50% (медиана) запросов на бэкэнд, т.е. 37288 штук, отработало менее чем за 1.391 секунд. Хотя лично я предпочитаю мониторить 85%-ый перцентиль:

cat nginx_access.log | awk -F\" '{print $9}' | grep -v ".--$" | awk -F\- '{print $2}' | sort -n | awk '{all[NR]=$1;} END {print all[int(NR*0.85)]}'
1.869