try {
$result = parent::query($query);
} catch (\Exception $e) {
$error_message = $e->getMessage();
if (str_contains($error_message, 'gone away')) {
parent::__construct($host, $user, $pass, $base, $port);
$result = @parent::query($query);
} else
die('Error: ' . $error_message);
}max_execution_time = 1000
memory_limit = 512M[Unit]
Description=Get content from email
After=network.target
After=mysql.service
Requires=mysql.service
[Service]
Type=simple
User=site
Group=site
WorkingDirectory=/home/site/htdocs/worker
ExecStart=/usr/bin/timeout --signal=SIGINT --kill-after=350 300 /usr/bin/php get_from_mail.php
MemoryLimit=512M
Restart=always
RestartSec=60
[Install]
WantedBy=multi-user.target$shallStopWorking = false;
pcntl_signal(SIGTERM, function () use (&$shallStopWorking) { $shallStopWorking = true; });
pcntl_signal(SIGINT, function () use (&$shallStopWorking) { $shallStopWorking = true; });
while (!$shallStopWorking) {
$mailbox = new PhpImap\Mailbox( '{imap.yandex.ru:993/imap/ssl}INBOX', ... );
$check = $mailbox->checkMailbox();
if ($check !== FALSE && $check->Nmsgs > 0) {
$mailsIds = $mailbox->searchMailBox('ALL');
if (!empty($mailsIds)) {
... работа с письмами ...
}
}
$mailbox->disconnect();
sleep(60);
pcntl_signal_dispatch();
}
Относительно подготовленных запросов:
1. можно код писать используя лишь query, используя следующие запросы:
PREPARE stmt FROM 'SELECT ....
SET @a = ...
SET @b = ...
EXECUTE stmt.....
2. Соглашусь, что в рамках демона, подготовленные запросы имеют смысл, так как одни и те же запросы исполняются многократно, бывают еще различные обработчики, парсеры, которые в циклах что либо выполняют при этом можно получить оптимизацию нагрузки на сервер. И да, при переподключении если пакет собран без флага MYSQLI_NO_CHANGE_USER_ON_PCONNECT то PREPARE нужно выполнять повторно, об этом функционале я сейчас и думаю. Но это исключительно частные случаи.
Стандартный сайт, да и большая часть любого правильно написанного кода одни и те же запросы исполняет 1-2 раза. Если сравнить стоимость одного query и стоимость prepare, set и execute то второй подход будет дороже. Если же вы относительно защиты от sql-инъекций - то она реализована на другом уровне.