rPman

Со своим сервисом - сделать batch запросы, позволяющие одним запросом выполнять несколько операций, например запрашивать/модифицировать информацию сразу по нескольким объектам. Но еще лучше, реализовать требуемую логику изменения объектов прямо на сервере, грубый пример - нужно сдвинуть координаты объектов на величину [dx,dy,dz], вместо того чтобы все с сервиса выгружать, менять координаты и загружать обратно, нужно сделать команду, которая на вход получит этот вектор и все сделает на сервере (это самый быстрый вариант)

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

Да конечно, preg_replace принимает как первым аргументом так и вторым - массив, если оба будут массивами, то метод будет использовать строчку замены соответствующую строке условию.

Еще есть preg_replace_callback и preg_replace_callback_array почитай документацию и примеры, еще более гибкие операции

p.s. осторожно, utf8 этими функциями работает с оговорками (модификатор /u), есть методы mb_ereg_... но array там уже не поддерживается

Есть ли в базе данные по условию?data = :data AND ref_id = 10215.
В data хранятся данные в формате?date("d-m-Y");.
По коду если запрос вернет пустой результат у тебя должна быть ошибка (варнинг в логах веб сервера или консоли где выполняется код), так как $depref1 не определен.
и т.п.

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

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

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

...

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

Все вышесказанное тебе может не понадобиться, так как в подавляющем большинстве случаев сервер сообщает о количестве доступных запросов и/или времени, через которое можно будет сделать следующий вопрос прямо в ответе на каждый запрос. Для этого заводится соответствующий заголовок и это указывают в документации. В этом случае тебе достаточно будет проверять этот заголовок и делать sleep (точнее usleep) ровно таким, как указано там (там бывает пишут сразу timestamp, когда можно делать следующий запрос).

p.s. посмотри внимательно, возможно долбить сервис http rest запросами не самый лучший способ получения оперативной информации, вдруг сервис предлагает более удобные инструменты, например websocket или даже старый long pooling

В чем совет то тебе дать?

Почему не работает код? так скажи что в нем не так.

Про получение данных, если тебе нужны ОПЕРАТИВНЫЕ данные, забудь про http rest, используй websocket, binance выдает в поток в 4 тысячи событий по всем парам, подписывайся на них и анализируй, это ты сможешь сделать в одном подключении. Если же все же http rest то внимательно прочитай про лимиты на запросы, они указываются в минуту и на практике еще меньше

IP Limits

Every request will contain X-MBX-USED-WEIGHT-(intervalNum)(intervalLetter) in the response headers which has the current used weight for the IP for all request rate limiters defined.
Each route has a weight which determines for the number of requests each endpoint counts for. Heavier endpoints and endpoints that do operations on multiple symbols will have a heavier weight.
When a 429 is received, it's your obligation as an API to back off and not spam the API.
Repeatedly violating rate limits and/or failing to back off after receiving 429s will result in an automated IP ban (HTTP status 418).
IP bans are tracked and scale in duration for repeat offenders, from 2 minutes to 3 days.
The limits on the API are based on the IPs, not the API keys.

p.s. Исторические данные по фьючерсам недоступны (только в пределах текущего квартала)
я пользовался, минуток тут более чем достаточно:

https://dapi.binance.com/dapi/v1/continuousKlines?pair={$pair}&contractType={$type}&limit=1500&interval=1m&startTime={$startTime}&endTime={$endTime}"

Где startTime и endTime нужно устанавливать на основе предыдущих полученных и сохраненных данных
https://dapi.binance.com/dapi/v1/exchangeInfo
Даст всю информацию о рынке (без стакана), там же видно где какой тип контракта PERPETUAL/CURRENT_QUARTER/NEXT_QUARTER какое наименование инструмента, типа LTCUSD_230630 или ETHUSD_230331 (там же есть все данные по времени начала и окончания периода), PERP фьючерсы повторяют spot рынок, поэтому для удобства можно эти данные брать

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

скорее всего php устанавливался вручную готовым пакетом, все .so идут в поставке по умолчанию
настраивается в php.ini

вот пример (пути могут другие быть)

если тебе не надо это контролировать, то игнорировать
@$data->{'id'}

p.s. вторым параметром json_decode пропиши true, тогда результатом будет не object а array в нужном тебе виде, да и работать можно будет с ним $data['id']