Vitsliputsli

Вы выводите поле is_poisk, он это и показывает, хотите считать кол-во строк - используйте функцию для подсчета строк.

Если весь массив умещается в память это уже хорошо. Как оптимизировать:
1) Создайте массивы не ассоциативные, а с обычными числовыми ключами. Лучше так и хранить, будет отдельно массив url и массив cnt, связь по числовому ключу.
2) Храните отсортированный массив, и используйте по нему, например, бинарный поиск.
3) Дополнительно можно использовать массив фиксированной длины из SPL, а не стандартный на хеш-таблицах, на таких объемах от него будет толк.

Подскажите на каком языке лучше всего Websocket? чтобы он был менее затратны в производительности и более всего понятен для изучения? :)

Go.

прочитал, что могут быть разные утечки памяти, если на php делать

Не будет, если сами их не создадите.

У вас включен файловый кеш (в том числе для cli), но отключена проверка валидности кеша (validate_timestamps). Поэтому пока вы вручную не сбросите кеш, он будет продолжать работать.
Что касается sudo, при первом запуске скрипта, вы сделали это через sudo, был создан файл кеша от root, с правами запрещающими чтение другими пользователями. При запуске без sudo php не может его прочитать и записать (хрен его знает, почему он не кидает ошибку), в итоге sudo php работает с файловым кешем, а php от пользователя нет.

Не нужно ничего сокращать. Код вполне краток и понятен. Дальнейшие сокращения лишь ухудшат читаемость.
Но если хочется поговнокодить можно взять empty.

Они не будут сортироваться, т.е. будут взяты, как прочитаны. Порядок при чтении зависит от движка, если говорить про InnoDB, то в нем данные сортированы по первичному ключу. Этот порядок зависит лишь от внутренних механизмов движка и не гарантируется, расчитывать на него и использовать в ПО нельзя.

Время выполнения - 10-12 сек в первый раз и 3-4 сек при повторных запросах

В первй раз идет "прогрев" кеша диска, поэтому долго. Повторный запрос в 3-4 секунды наверное вполне нормальный, т.к. скорее всего необходимо обработать большое кол-во данных (но, конечно, нужно смотреть план, чтобы понимать сколько он обработал).
Решение стандартное - стройте проекции. Агрегирующие с группировкой по дням, для группировок по дням, неделям, месяцам. И top-проекции для "получить 100 элементов, у которых самая большая сумма". Но нужно посмотреть как это делать, так как я больше работал с другой колоночной СУБД.

1) Внешний адрес у всех устройств подключенных к одному роутеру одинаковый или разный?

Скорее всего одинаковый. Т.к. под роутером обычно понимают домашние маршрутизаторы, выполняющие роль NAT, как раз чтобы экономить ip-адреса в первую очередь.

2)Как узнать внешний адрес статический или динамический?

Если меняется при новом подключении значит динамический. Если не меняется, то всяко может быть.
Очевидно, он статический, если прописан вручную в роутере, но скорее всего его получают динамически, и ответить точно, может только администратор сети, к которой роутер подключен.

Стандартно, gitflow. К примеру так: разработка ведется в отдельных ветках feature, для интеграции сливаются в dev, на основе dev создается release и после тестирования заливается в master, который и выкладвается в прод.
Разные токены это относится к окружению, в коде этого быть не должно. Окружение собирается сборщиком деплоя, например в Jenkins.

Дождаться окончания распродаж, когда они окончательно закроют свой сайт, ну или вдруг снимут ограничения на посещение.
Что вы хотите? Они живых пользователей не пускают, а вы хотите ботом пробиться.

Как удобно, так и храните. Брокер сообщений предлагают, потому что, это универсальный вариант, гарантирующий доставку (если, конечно, не в памяти он будет хранить).
Если данные уже лежат в классический СУБД, то есть резон там же организовать очередь и забирать из нее, не вводя дополнительный инструмент.
Т.к. инсертим батчами, то разумеется нужно делать инсерт из файла, это будет эффективнее. Т.е. готовите файл, и через какой-либо промежуток времени заливаете его. И, разумеется, только после заливки помечаете записи как обработанные.
Наверное, можно писать даже прямо в файл для заливки, если архитектура позволяет, главное проработать момент, когда начинаем писать в новый файл, чтобы записи не попали в старый, когда началась процедура заливки в ClickHouse.
Но, при этом остается момент: ваш заливщик умер, когда уже получил подтверждение от Clickhouse, что все записалось, но не успел зафиксировать это в очереди. Соответственно это нужно проверять.
Если у вас не только insert, но и update, то нужно усложнять архитектуру (заодно и решится выше указанная проблема), нужно удалять предыдущие записи для обновляемых.

Нисколько не потребляет, когда не работает, а работает она только когда вы меняете через нее правила. Всегда потребляет ресурсы встроенный файервол netfilter, а сколько, зависит от кол-ва правил, их сложности и подключенных модулей.
Туннели могут какие угодно разные, что в софте реализуете, хоть http через icmp.

Все public, все доступно извне, нет сокрытия.
Прям сам объект куда-то лезет по api, забирает данные, которые сам и предоставляет, обрабатывает ответ, явное нарушение SRP.

Оптимизация это всегда жертва чем-то, ради чего-то. Нельзя просто оптимизировать, нужно выбрать, что улучшать, а затем выбираеть решения, понимая, чем можно пожертвовать. Поэтому начинать оптимизацию нужно тогда, когда знаешь какую проблему решаешь.
Нельзя просто поставить прослойку перед MySQL и все станет хорошо, MySQL итак, очень быстрая СУБД. Но можно поставить, например кеширующий Redis, при условии, что у вас очень много key-value значений и крайне важен быстрый доступ к ним. Это решение не только увеличит занимаемое место и усложнит архитектуру, нужно будет контролировать консистентность баз данных, которая может быть нарушена из-за проблемы инвалидации кеша.
Оптимизация классических СУБД всегда начинается с построения наиболее подходящих индексов. Если этого уже не хватает и скорость чтения недостаточна, то можно ввести репликацию slave и читать из нее. Здесь опять возникнет вопрос дополнительных затрат на место и консистентности, особенно неконсистентности данных из-за лага репликации. Плюс затраты на дополнительное подключение, что впрочем можно решить внедрением proxy.
Далее более сложные варианты, от отказа от foreign keys, до шардирования. Но все это при действительно высоких нагрузках, заниматься этим на данном этапе не стоит, разве что, если есть предпосылки, что к этому придете, то заранее выбрать параметр шардирования (иногда это просто, а бывает очень сложно).

Использовать разные базы данных внутри одного Редиса.
Если, конечно, настройки Редиса подходят для обоих проектов.

Вы можете воспользоваться контравариантностью (php>=7.4), т.е. указать в абстрактном классе родительский класс для User:

abstract protected function mapToArray(Model $object ): array;

...

class User extends Model

Либо ввести DTO, чтобы mapper брал данные из него и вообще никак не обращался к бизнесовым сущностям.