Виталий Артемьев

Недостатки исходных вариантов проверки:

$str = "0";  // непустая строка, содержащая цифру ноль
if (!$str) echo "bool false\n"; // сработает
if (empty($str)) echo "is empty\n"; // сработает

$str = null; // не строка
if ($str == "") echo "equals empty str\n"; // сработает
if (strlen($str) === 0) echo "zero length str\n"; // сработает

Поэтому лучший вариант, как и предложил Rsa97, проверять строгое равенство === с пустой строкой.

как импортируешь то? ты в свой скрипт не можешь вставить sleep между запросами?

львиную долю нагрузки базе данных на запись создают:
1. поддержка транзакций
2. перестройка индексов
3. средства защиты данных от сбоев
каждая запись на диск, которая по мнению базы данных должна быть произведена с гарантией, т.е. снабжается вызовом flush, но база данных не всегда знает когда это стоит делать а когда нет, частично это разруливается длинными транзакциями, вставляя между коммитами 100500 запросов на вставку

Так вот по каждому пункту можно временно изменить логику и настройки работы базы данных.
1. отключить транзакционные механизмы, перейдя от innodb к myisam, это может дать чуть ли не двухкратный прирост, но потребует в приложении как то игнорировать отсутствие поддержки транзакций, что не всегда просто сделать
2. отключить индексы, буквально, оставить только PK и то только там где это имеет необходимость только для импорта, после окончании импорта данных, индексы нужно будет вернуть. Однократное создание индексов на порядок если не два быстрее чем обновление индексов по каждой записи в базу.
3. отключить поддержку flush в операционной системе, буквально например опция монтирования ext4 data=writeback, база данных не будет ждать когда данные реально будут записаны на диск (есть еще опция O_DSYNC у mysql innodb, совет вообще полистать как тюнить дисковый io) но осторожно, если в это время произойдет краш сервера, данные будут испорчены, причем скорее всего безнадежно. В догонку, можно перенести журнал ext4 на другое более быстрое устройство или лучше совсем его отключить, так как при записи данные пишутся сначала в него потом на диск, на время импорта это лишние операции
И в догонку, если размер базы данных к примеру считанные сотня гигабайт, то можно временно арендовать в облаке машину с большим объемом RAM, залить базу в tmpfs и на максимально быстрой скорости импортировать данные, потом готовую базу залить обратно.

т.е. данные действия позволят, остановив работу (без этого никак) провести импорт максимально быстро и восстановить работу, пол миллиона записей это мизерный объем и если что то тормозит то исключительно из-за плохой архитектуры или реализации

Если используется mpm_worker то в конфиге найти и изменить следующие директивы:

<IfModule mpm_worker_module>
        StartServers             2
        MinSpareThreads          25
        MaxSpareThreads          75
        ThreadLimit              64
        ThreadsPerChild          25
        MaxRequestWorkers        150
        MaxConnectionsPerChild   0
</IfModule>

Если используется mpm_prefork то в конфиге найти и изменить следующие директивы:

<IfModule mpm_prefork_module>
        StartServers             5
        MinSpareServers          5
        MaxSpareServers          10
        MaxRequestWorkers        150
        MaxConnectionsPerChild   1024
</IfModule>

Насколько я вижу, mail1 не проходит авторизацию, скорее всего надо либо в настройках включить портальный пароль (это они так обычный назвали) либо использовать пароли приложений


Но вообще очень плохой вариант. С одной стороны яндекс может блочить отправку через свой SMTP, подробнее писал в этой статейке
https://7fk.ru/nastroyka-smtp/
С другой стороны отправка через mail1 с полем from mail2 будет всеми почтовиками восприниматься как спуффинг и письма далеко не везде попадут даже в папку спам

Вам нужно медиана?

Ну я даже не знаю. Там же, где и все остальное, в базе данных? Ну или где ты там хранишь всю остальную инфу.

HEAD

Зачем в цикле на каждую кнопку отправлять отдельное сообщение? Надо сначала в цикле сформировать клавиатуру, а потом отправить одно сообщение.