fenrir

Вы смотрите на совершенно бесполезный график. Смотрите на полезные.

Если у вас табличка с 10 индексами и к ней select * from foo where id = ? - то это минимум 11 AccessShareLock. Совершенно логично, что чем больше параллельно нагрузки - тем больше вы увидите AccessShareLock. И дальше куда с этим? Вот и получается совершенно бесполезный график. А задирание max_connections сделает только хуже.

Посмотрите график CPU, есть ли в принципе CPU свободный (помним что у вас наверняка есть HT, значит 100% утилизации недостижимы, реальный потолок окажется где-то в районе 70-90%)
Посмотрите графики латентности IO. Если проседает латентность чтения или записи под нагрузкой - то это будет причина замедления. СУБД очень чувствительны к латентности.
Дальше графики pg_stat_activity с разбивкой по state. Если растут idle in transaction - проверять как дела на приложении, а так же сеть.
Конечно, графики по pg_stat_statements. top5 запросов по времени выполнения, для начала.
И проверить наличие корреляции с графиком длительности самой старой транзакции.

для неспособных гуглить
https://core.telegram.org/bots/api#sending-files лимиты
https://core.telegram.org/bots/api#using-a-local-b... как повысить лимиты

Во-первых, оформи код, нечитаемо. Кнопка </> в помощь.
Во-вторых, matchTemplate(), насколько я знаю, не-инвариантна к поворотам и масштабу. Иными словами, поворот или изменение размера целевого объекта сломают сопоставление.
В-третьих, на показанном кадре более одного экземпляра целевого объекта. Так предполагается или нет? Если предполагается, сколько экземпляров ожидается? Потому что разница очень большая с точки зрения методики.

Варианта тут три.
1. пытаться обучать под задачу нейронку. А лучше дообучить существующую, скажем, YOLOv5. Но тебе потребуется минимум несколько сотен размеченных изображений объекта в разных комбинациях, плюс в 2-3 раза больше похожих изображений без целевого объекта. Готовить такую базу будет утомительно, да и само обучение требует понимания что ты делаешь.
2. попробовать зафиксировать угол поворота или масштаб (т.е. допустить, что он всегда одинаков). Тогда другой параметр можно будет подбирать. Например, мы фиксируем масштаб и делаем 16 изображений объекта в разных поворотах, а потом поочерёдно ищем каждый вариант на кадре. Потом анализируем силу откликов - сколько их, насколько они сильные и т.д. Скорее всего, будет медленно
3. взять за основу поиск по локальным особенностям. Он справляется с масштабом и поворотом, но не справляется с несколькими экземплярами объекта. Это можно забороть, если использовать скользящее окно. Иными словами, находим на кадре узнаваемые точки - локальные особенности (желательно достаточно много и достаточно плотно), используя алгоритмы вроде ORB или SIFT. Затем выбираем те из них, которые попадают в прямоугольную рамку-окно. Затем сверяем эти особенности с особенностями объекта, используя RANSAC или подобный метод. Если получилось хороше совпадение - значит, в этой рамке есть объект или значительная его часть, и мы можем оценить его позицию в кадре в целом. Повторяем процесс, сдвигая рамку, пока оно не "обойдёт" всё изображение. Тоже может быть небыстро, так как нам требуется неоднократный поиск по картинке.

В хроме запрещен JavaScript или какое-то расширение его режет. Проверка на двусторонний пинг осуществляется примерно так: вы заходите на 2ip с адреса vps, 1) 2ip пингует адрес vps и засекает время ответа. 2) код страницы 2ip в вашем браузере на домашнем компе дергает пустую страницу с сайта 2ip. Пишут, что с помощью XMLHttpRequest, но я бы на это не полагался. Время ответа опять засекается. Так как ваш домашний комп объективно дальше от сервера 2ip, чем vps из-за туннеля ( t(browser -> vps -> 2ip) больше, чем t(vps -> 2ip)), вы палитесь на этом тесте. Глобально можно просто дропать ICMP Echo Request на vps, чтобы 2ip не мог выполнить п. 1)

Не скажу ничего про алгоритм и корректность замеров, но время t01 и t02 ты точно измеряешь неправильно

subsec_nanos
Returns the fractional part of this Duration, in nanoseconds.

This method does not return the length of the duration when represented by nanoseconds. The returned number always represents a fractional portion of a second (i.e., it is less than one billion).
https://doc.rust-lang.org/std/time/struct.Duration...

У структуры Duration есть операторы для сравнения, так что тебе не обязательно знать конкретное число, пока ты не выводишь его в консоль

let mut t01 = Duration::MIN;
let mut t02 = Duration::MAX;
if duration> t01 {
      t01 = duration; // здесь
   }
   if duration< t02 {
      t02 = duration; // и здесь
   }

UPD:

Комп 6 ядер 12 потоков ничем не нагружен. Если не накосячил с кодом, а так
захватывается периодически ресурс потоков компа, то как такое решить
и получать расхождение в пределах 20%?

1. Такой разброс, как у тебя показан - это норма. Нужно смотреть не на минимум/максимум, а на распределение (в комментах скинул график - там тоже минимум и максимум сильно различаются, но прогонов с таким временем мало)
2. Я не увидел в вопросе описания того, как происходит запуск. Хотябы в --release компилировал?
3. У тебя данные вполне статичные, так что компилятор при желании мог очень много наоптимизировать, что даст тебе некорректные результаты, но на распределение это влиять не должно.

http и https можно поднимать на любом порту, просто его придется явно указывать в отличие от дефолтных. Самое просто это делать через проксирование в нормальные веб-серверы, nginx и подобные.

Я бы вообще изобрёл велосипед, если честно.
У тебя есть список или база активных (неслучившихся) событий. Пусть это будет пара ID-метка времени, остальная инфа нам без надобности.
При запуске бота выбираем из списка ближайшее событие, и вычисляем время ожидания (с небольшим запасом) и спим в корутине. В случае, если ожидание прервано раньше - повторяем то же самое, чтобы либо "доспать", либо переключиться на ожидание более близкого события.
Если же ожидание закончилось успешно, обрабатываем событие и снова повторяем поиск ближайшего события.
Если список событий изменился, прерываем текущее ожидание, чтобы корутина ожидания могла адаптироваться к изменениям.

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