idmrty

[Unit]
Description=Docker OOM Monitor Service

[Service]
Type=simple
ExecStart=/usr/bin/docker events --filter type=oom

[Install]
WantedBy=multi-user.target

1. ini_set('display_setup_errors', 1); надо убрать вообще, это бессмысленный карго-культ
   
2. ini_set('error_reporting', E_ALL); и ini_set('display_errors', 1); надо вынести в общий файл, который инклюдится во все остальные. Иначе на бою придется редактировать в каждом файле, чтобы заменить 1 на 0.
   
3. empty после trim надо убрать, проверять на существование заведомо существующее значение не имеет смысла. То есть, переписать так
   

   if(trim($_POST['user_name']) && trim($_POST['user_email']) && trim($_POST['user_password']))

   
   Но и это будет неправильно, поскольку trim не применяется к добавляемым в БД значениям
   То есть, потримать отдельно в переменные, а потом проверить просто
   if($user_name && $user_email && $user_password)
   
   
4. проверка if(isset($_SESSION['user_data'])) явно не на месте. А если форма запрошена не постом? Показывать её уже авторизованному пользователю? Зачем?
   
5. после header('Location: '); всегда должен идти exit. в данном случае не принципиально, но это должно делаться на автомате.
   
6. _once из require_once надо убрать вообще, это бессмысленный карго-культ
   
7. require('database/ChatUser.php'); - это стыдоба. Сделайте простенький автозагрузчик, это три строчки. Например
   

   spl_autoload_register(function ($className) {
       $ds = DIRECTORY_SEPARATOR;
       $className = str_replace('\\', $ds, $className);
       $filename = __DIR__ . "{$ds}..{$ds}database{$ds}$className.php";
       require($filename);
   });

   автозагрузчик тоже кладется в общий подключаемый файл.
   
   
8. проверку if($user->saveData()) надо убрать вообще, это бессмысленный карго-культ, и - вдобавок - ошибка. Если POST запрос был обработан без ошибок, то после него всегда должен быть редирект, без всяких success_message. А "Something went wrong" выводится совсем другим кодом. Я ещё посмотрю в database, но если что, то исправлять надо будет там
   
9. вывод сообщений об ошибках в хтмл части лучше сделать в едином стиле
   

   <? if($errors !== ''): ?>
       <?=htmlspecialchars($errors) ?><br><br>
   <? endif ?>

   
   
10. хорошим тоном считается при ошибке выводить пользователю уже введенные значения (кроме пароля, разумеется)
    

    <input type="text" name="user_name" value="<?= htmlspecialchars($user_name ?? '') ?>">

    
    

1. В обязательном порядке переделать
   • Во-первых, require в коде класса - это сразу профнепригодность. Всю необходимую информацию класс должен получать только через методы.
     
   • Во-вторых, new DatabaseConnection в каждом конструкторе - это совсем детская ошибка. Давно TOO MANY CONNECTIONS от mysql не получали?
     
   
   Этот класс должен принимать уже созданное соединение, через параметр конструктора.
   
   
2. createAvatar я бы вынес в отдельный класс
   
3. Непонятно, зачем вам вообще понадобился цикл foreach ($params as $key => $value), если проще и удобнее написать $statement->execute($params); Для кого специально этот функционал создатели PDO писали?
   
4. return $user_data; после условия - это логическая ошибка. Будет undefined variable $user_data если условие не выполнится. Но главное, что здесь все неправильно изначально. Никаких проверок быть в принципе быть не должно.
   

• Во-первых, данные для подключения к БД (как и другие, отличающиеся для разных окружений настройки) пишутся в отдельном файле, который не добавляется в систему контроля версий (пишется в .gitignore). И, соответственно, никаких констант, а обычные параметры конструктора. И в этом контексте становится непонятно, зачем вообще нужен класс DatabaseConnection, если все что он делает - это создает инстанс PDO? Правильно, он становится совершенно не нужен
  
• Во-вторых, и самое главное - в PDO не включен режим информирования программиста об ошибках. Я даже не представляю, у какого инфоцыгана вы брали этот код - уже, вроде бы, даже до самых тупых из них дошло, что оставлять программиста без сообщений об ошибках - это садизм. Поэтому при создании инстанса ПДО надо в обязательном порядке включать режим информирования об ошибках. Для этого добавить еще один параметр в виде массива, [PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION]; и пока оставить так. А потом, со временем, добавить к проекту централизованный вывод сообщения "что-то пошло не так"
  
  

Из 2 гигов оперативки занято 500 мб, причём раньше свободно было больше.

Из-за чего systemd-journald может есть 10% от оперативки? Куда смотреть?

которой бы не блокировался anti-DDOS

Так вот: я смотрю, что получил 1500 строк из базы за 0.0316 секунд. Это нормально?

База растёт и строк к выводу станет больше.

Маляр Шлёма подрядился красить пунктирные осевые линии на дорогах. В первый день он получил банку краски, поставил её на дорогу, и к концу дня покрасил 300 метров осевой линии. «Отлично! — сказал прораб. — Быстро работаешь!» и заплатил ему.
На следующий день Шлёма покрасил 150 метров. «Мда, это, конечно, не так здорово, как вчера, но приемлемо», — сказал прораб и снова заплатил ему.
Ещё через день Шлёма покрасил всего 30 метров. «Всего лишь 30! — заорал прораб. — Это никуда не годится! В первый день было в десять раз больше! В чём дело?»

«Ничего не могу поделать, — говорит Шлемиэль. — Каждый день я ухожу всё дальше и дальше от банки!»

На что ориентироваться? На показатели загрузки процессора или время выполнения запроса или расход памяти?

И вопрос в догонку: если одним запросом я получаю 1500 строк и если в запросе я установлю select нужных мне столбиков - это усложняет запрос или нет? Ведь в первом случае я получаю информацию как есть, а во втором случае процессору надо время чтобы перебрать нужные столбики?!

Сейчас я кеширую результаты php на 60 минут,

Как понять есть ли нагрузка на БД?/