N

не знаю о чем вы, но вот собирать логи веб-сервера задача элементарнейшая.
например разворачивам ELK (elastic + logstash + kibana) на хост с веб-сервером ставим filebeat , в кибане имеем все логи вебсервера как угодно, любые фильтры и обработки
или есть еще graylog , он тоже использует эластик, тоже интересное решение.

любое программирование относится к прикладному.
а дальше уже ведется дележка: системное/сетевое/доступное юзеру (в просторечии – прикладное)/и все такое.

Вам же, наверное, диапазон определенный нужен?
$ratingrandomvalue = rand(480, 500)/100;

//4,80 - 5,00

Правильно построить выборку из нужных таблиц.

INSERT into archive (title_product, title_category, price_product) 
SELECT p.title, c.title, p.price
  from product p
   join category c on p.category_id = c.id

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

Для любой Сложной Многофункциональной Системы веб сайт это только один из возможных каналов взаимодействия с системой. Само ядро системы может быть написано вообще на каком-нибудь Си и иметь помимо сайта выход на моб. приложение (Java), десктоп приложение (Си), какую-нибудь ERP-систему, веб-портал (PHP, Net), то есть Ядро единое, а каналов взаимодействия (которые написаны на разных языках) с ним много. Так что все ответы про Питон или боже упаси Яваскрипт это конечно же чушь собачья.
Просто почитай про бэкэнд таких проектов как Авито, ВК, фейсбук.

Вы тестируете не производительность кода, а производительность сети от вашего компа до сервера в Германии. Если хотите реальные тесты производительности, то нужно убирать сеть. Описаный вами стек, без учёта сети, должен быть чуть хуже, чем производительность Nginx, и скорее всего это будут десятки, а то и сотни тысяч запросов в секунду

Увеличивай количество потоков тестирования, очевидно же что основные тормоза у тебя из-за сетевой латенси
Локальный nginx на совсем убитой машине дает гигабайты на hello world статике и тысячи запросов в секунду.

В доказательство, попробуй запустить тесты локально на сервере.

1. отправлять форму через XHR / fetch (ajax post).
2. редирект после отправки формы - типовое и надёжное решение
3. можно сохранять в сессию последнюю отправленную форму. и если видим дубликат данных то игнорировать этот post-запрос.

Если редирект "не помогает" то прошу в студию минимальный пример кода где у вас форма + страница которая после получения формы делает редирект, а мы проверим правда ли "не помогает".

https://www.php.net/split

Warning
This function was DEPRECATED in PHP 5.3.0, and REMOVED in PHP 7.0.0.
Alternatives to this function include:
preg_split()
explode()
str_split()

оставляете точно такой же код, но вместо split() используйте explode()

У вас просто опечатка в .cachce. Если мы говорим об английском, то должно быть .cache.

1) update сам вызывает save (save надо убрать)
2) Можно использовать магию и итоговый вариант будет таким

public function update(Request $request, Crud $crud){
        $crud->update([
            'name' => $request->get('name'),
            'email' => $request->get('email')
        ]);
        return redirect('/')->with('update', 'Вы успешно Изменили Данные');
    }

Важный момент:
- переменная $crud должна быть названа как в роуте
- использовать валидацию

Нет.
Ради странных фантазий о том что код, написанный Симфони тем же самым программистом будет работать в 10 раз быстрее чем код под Ларавель, менять точно не стоит.

Ради будущего расширения проекта, если писать с соблюдением рекомендованных практик - вполне стоит, средний проект на Симфони обычно более расширяемый и поддерживаемый, чем типичное фигак-фигак и в продакшен на Ларе

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

У Laravel огромнейшее сообщество и опытные лидеры. Шанс того что ты напишешь лучше весьма низок. Если тебе что-то не понравится можно отключить и сделать лучше. Но имхо кроме лишних часов разработки ничего из этого не выйдет.

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

Нет. Фреймворк тут играет последнюю роль. 10000 человек в день это немного, меньше одного запроса в секунду в среднем, надо смотреть на нагрузку в пике. В любом случае надо анализировать слабые места - запросы к базе, количество веб серверов для обработки запросов, возможность кеширования и асинхронной обработки...
UPD. У Вас в вопросе написано и пиковая нагрузка 10000, и 10000 за день, что в итоге?))
Все равно результат нужно сводить к предварительному профилированию и только потом к тюнингу серверов или рефакторингу