Дмитрий

есть стандартная системная служба cron

в менеджере systemd есть более современный метод создать my_name.service и к нему запускалку по времени my_name.timer
статей мильен и для того и для того
пишем задание для cron
пишем свой timer для systemd

Вот почему: PHPunit замокать класс внутри тестируемого класса?
Бонус-раунд: DI упрощает работу с зависимостями зависимостей. Если ваш MyService принимает какой-нибудь логер в зависимостях, который в свою очередь ожидает какой-нибудь драйвер файловой системы, вы задолбаетесь собирать их через new.

$data[$ip]

у Вас JSON невалидный. Если предположить, что правильный JSON такой:

{
  "128.3.3.1:1231":
    {"name":"NAME SERVER 1","gamemode":"mods","url":"https://url.ru","lang":"ru","players":412,"peak":521,"maxplayers":3333},
  "127.0.0.1:1234":
    {"name":"NAME SERVER","gamemode":"mods","url":"https://url.ru","lang":"ru","players":598,"peak":609,"maxplayers":3000}
}

то нужная часть извлекается элементарно:

$json= "https://jsonurl";
$data = json_decode(file_get_contents($json),true);

$ip = "127.0.0.1:1234";
$item = $data[$ip];

Самое простое:

function user_pow(int $number, int $degree) {
  if ($number <= 0 || $degree < 0) throw new \InvalidArgumentException('Invalid arguments');
  if ($degree === 0) return 1;
  $result = $number;
  for($i = 1; $i < $degree; $i++) {
    $result *= $number;
  }
  return $result;
}

echo user_pow(2, 2); // 4

Вопросы такие: какие есть способы ускорить загрузку страницы?

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

Можно ли её рендерить на клиенте при помощи js?

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

И почему на смартфоне в мобильном safari та же самая страница грузится за пару секунд?

Опять же, вопрос скорее к вам чем к кому-либо еще. Возможно кеширование, которое на мобильных браузерах практически всегда более агрессивное. Возможно вы просто не видите как тормозит загрузка, например в силу другого метода рендеринга, который сразу при получении данных выводит все что возможно, в то время как на стационаре рендеринг идет только после загрузки тега целиком. Достаточно например быстро промотать на сафари вниз при загрузке, чтобы увидеть что загрузилось далеко не все... А возможно в мобильной версии отображается сильно меньше элементов...

Можно ли этот эффект повторить на десктопе?

Если есть что повторять... Можно попробовать сделать таблицу не цельной, а разбить на несколько таблиц, по 100-300 строк. Или еще адкеватнее - сверстать дивами.

Как вариант - лэзилоад, по мере прокруки страницы подгружать новые данные по мере необходимости, что сильно снизит как трафик в целом, так и тормоза рендера.

PS:

я тоже склоняюсь к неэффективной вёрстке. Если я эту вёрстку буду генерировать js’ом, процесс ускорится?

Скорее всего, как я уже написал, скорости не прибавится. Вообще что мешает проверить эффективность верстки? Тупо выведите все строки дивами, без всяких разделителей, одна строка - один див с данными, разделенными "|" например, и посмотрите на разницу.

Для параметра -u в PHP нужно передать CURLOPT_USERPWD
https://www.php.net/manual/ru/function.curl-setopt.php

UPD.
curl_setopt($ch, CURLOPT_USERPWD, '12345:');

& на мысли не наталкивает ? Что такое html entity знаете ?
В общем или в базу муссора насовали или позже обработали строку.
Есть два подхода (крайности), к тому как заносить данные в базу данных.
1) Все проверяем по куче условий, при любой ошибке отказываемся.
2) Пофиг - записываем все как есть, потом будем опасное экранировать.

Всё есть в документации.
$array = json_decode($json, true)
На выходе получаете массив. Страны будут лежать тут, выводите как нужно:
$array['promocodeInfo']['countryDetails']

Вам не надо тестировать приватные методы.
Но как же тогда быть, вы скажете?
Публичные методы используют эти приватные методы, так и проходит тестирование.
Из этого вытекает, что класс должен быть небольшим и выполнять только одну задачу. Поэтому его приватные методы будут всегда задействованы при тестировании публичных.
Но вы скажете, что у вас там в публичных методах обращения к базе данных и внешним API, как же тут быть?
А быть тут просто: все зависимости вашего класса должны включаться в качестве аргументов конструктора, и через использование интерфейсов в аргументах. (Dependency Injection)
Таким образом в тесте все зависимости класса заменяются теми же моками, и вы легко тестируете не просто сферического корня в вакууме (приватный метод), а именно то, что и нужно тестировать: функциональность самого класса, а не его частей, потому что в OOP именно класс является как бы атомом функционала.
Но... если вам всё же таки очень надо, то можно это сделать при помощи рефлексии:
Хорошей практикой является использовать всегда protected вместо private.
Пишете себе такую вот утилиту:

class PHPUnitUtil
{
  public static function callMethod($obj, $name, array $args) {
        $class = new \ReflectionClass($obj);
        $method = $class->getMethod($name);
        // $method->setAccessible(true); // если PHP старше 8.1.0
        return $method->invokeArgs($obj, $args);
    }
}

И используете ее в тестах

$returnVal = PHPUnitUtil::callMethod(
                $this->object,
                '_nameOfProtectedMethod', 
                array($arg1, $arg2)
             );

Есть ещё вариант.

// Оригинальный класс
class Foo {
  protected function stuff() {
    // secret stuff, you want to test
  }
}

// Класс для тестов
class SubFoo extends Foo {
  public function exposedStuff() {
    return $this->stuff();
  }
}