VoidVolker

Это называется метрики приложения.
Реализовать можно несколькими способами, в зависимости от требования:
- Для онлайн показателей (количество ошибок приложения, кол-во активных пользователей) можно реализовать через счетчики - грубо говоря, приходит пользователь -> увечиличиваем счетчик
- Для статичтических данных - нужно делать запросы в БД, т.к. онлайн такое вряд-ли реализуется (приложение может рестартануть и метрики потеряются) - это SQL (если данные в реялционке) или язык для своего хранилища

Чаще всего вижу такое решение:
- Приложение отслеживает внутрениие метрики и отдает их в Prometheus формате
- Prometheus приложение собирает эти метрики
- Grafana получает метрики из Prometheus и строит по ним дашборды
- Grafana делает запрос в БД для получения статистики и строит по ним дашборды

В общем, смотри пару Prometheus/Grafana

P.S. анализ логов для получения метрик - плохая затея, не надо так
P.P.S. метрики, логирование, действия пользователя и т.д. - в общем случае называется observability - возможность понимать что происходит в приложении/системе и т.д.

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

Вариант решения тут один - смена провайдера.

Конечно это всё при условии что витая пара к Вам нормальная и Ваше оборудование тоже. И проверяется это всё надеюсь по кабелю, а не по вифи. В целом это проверить достаточно просто - подключив ПК напрямую в прова, минуя роутеры. Если косяк сохраняется - то 100% вина провайдера. тем более раз это не постоянно, а только в часы пик

Если вы имеет в виду, что к вашему кабелю приделана скрутка (ответвление) другим кабелем - скорее всего, монтажники подключили две квартиры на один кабель, каждую по двум парам. Работать будет, но максимальная скорость ограничена 100 Мбит/с.

Lua или Perl. Но я бы запускал с помощью fcgiwrap.

Как сказал ky0 :

Зачем хранить образы после сдачи проекта? У вас есть Dockerfile, в случае чего ничего не стоит развернуть всё заново.

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

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

Никогда не используй свои ресурсы для удовлетворения потребностей заказчика.

Зачем хранить образы после сдачи проекта? У вас есть Dockerfile, в случае чего ничего не стоит развернуть всё заново.

Если же вы про какие-то сакральные данные - как их хранить, после сдачи проекта решает клиент. Тратить на это свои деньги, конечно же, не стоит.

От 16гб оперативки минимум

У меня Macbook Pro M1 Pro 16/512.
Когда запускаешь какую-то IDE от Jetbrains типа Goland, то батарея тает на глазах, да и памяти она кушает хорошо.

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

Но... Как только вам понадобится Docker, могут начаться проблемы. На Маке он не нативный, и может сжирать много памяти. У меня много чего в Докере запускается, и вкладок в браузере всегда несколько требуется, поэтому мне 16 прям впритык.

Мой совет - брать машину с 16гб минимум, но тогда уже нет смысла брать Air...

P. S. Мак в разы лучше работает с памятью, чем винда, поэтому сравнивать не всегда корректно.

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