Перенос бота и впечатления от Amazon Web Services

Вера всё же решился и взял для SiteKnockerBot облачный сервер в Amazon Web Services. Причём сервер взял на ARM-архитектуре. Долго колебался, но в итоге сказалось то, что для ARM-серверов предлагается сетевое подключение до 5 Гбит/с, для x64 с free tier — нет, а хороший канал для этого бота очень даже важен. В качестве дистрибутива хотел было взять уже привычную Ubuntu. Но потом вычитал, что у Amazon Linux, предлагаемого по умолчанию, используется rolling model для обновлений, и это определило мой выбор в пользу него.
Первые впечатления были не очень: чуть не сломал себе мозг, пытаясь выяснить, как подключиться к серверу. Если с тем, что нужно подключаться, указывая public DNS, разобрался быстро. Но вот что вводить в качестве имени пользователя, было непонятно. Перепробовал кучу всего: идентификатор машины, идентификатор группы безопасности и т.п. Ничего не помогало, пришлось читать документацию. Оказалось, что имя пользователя фиксировано и зависит только от дистрибутива, и в моём случае нужно писать ec2-user.
Решил вернуться к истокам и снова в качестве «простукивающей» части бота использовать ту, которую писал в самом начале на PHP, а не более новую на Go. Версия для Go в последнее время стала очень сильно глючить, в последние дни даже несколько раз падала. Да и ложных срабатываний давала существенно больше. А кроме того, из-за другой архитектуры пришлось бы компилировать её непосредственно на сервере, а не просто закидывать бинарник, как раньше.
Попытался было поставить PHP и с удивлением обнаружил, что установилась версия 5.4. Пришлось снова лезть в документацию. Выяснилось, что ставить более новые версии можно с помощью специального скрипта amazon-linux-extras. Причём оказалось, что выбор версий там весьма велик: есть даже PHP 8.0. Я даже хотел был его и поставить, но потом всё же не решился и ограничился PHP 7.4.
Затем какое-то время колебался, что поставить: настоящий MySQL от Oracle или MariaDB. Пытался даже найти сравнения, но из-за недосыпа плохо вникал. В итоге поставил MariaDB просто из соображения, что это ближе к духу open source.
И вот наконец-то всё установлено, база перенесена со старого сервера и наступил момент запуска. Для начала запустил бота с отключенной отсылкой уведомлений в Telegram. После нескольких ошибок последнего момента вроде всё заработало. Но увы, существенного скачка в производительности не наблюдалось. Когда я повысил количество параллельных проверок до 500, стали проскакивать ложные срабатывания.
Остаток вечера и ночь я провёл в попытках найти оптимальное соотношение между максимально возможным числом проверок и этими ложными срабатываниями, а также подобрать настройки системные настройки через sysctl. В какой-то момент даже показалось, что нашёл. Но когда переключил бота в рабочий режим, увидел, что даже для моих сайтов то и дело приходят уведомления о слишком большом времени ответа —2-3 секунды.
В итоге где-то около пяти часов утра пришло в голову неожиданное решение: вытащить из базы общее количество URL для проверки, разделить весь пятиминутный интервал на это число, умноженное на три, и после каждой проверки делать sleep на нужное время. Решение, конечно, очень костыльное, но тем не менее, оно помогло! Ложные срабатывания исчезли, а время отклика моих сайтов стало показываться на уровне 150—240 мс — почти как в те времена, когда я только запустил бота, и проверялись только мои сайты. (На самом деле тогда было 110—180, лишние 40 мс добавились из-за того, что бот теперь находится в ДЦ во Франкфурте, а не в Москве.)
На этом решил успокоиться и пойти спать. Пока число URL на проверке не дорастёт до 25—30 тысяч, этого должно хватить, если не считать того, что PHPшная версия менее устойчива к медленным сайтам из-за особенностей работы curl_multi_exec. А к этому времени я либо всё же доведу до ума бота на Go (сейчас возникла мысль, что там можно переделать), либо вообще напишу сканирующую часть на C в многопоточном режиме, в которой, если и попадётся медленный сайт, он будет тормозить только один из сканирующих потоков.