у нас есть 60 000 клиентов, нам нужно продлить подписку, для этого мы используем сценарий обновления, который использует curl_multi_exe c, чтобы создать дочерних элементов для вызова другого сценария, который выполняет транзакции, и вставляет is_paid=1 в базу данных.
Сценарий выполняется с использованием задания cron на PHP 5.3 и Apache, сервер centos 6. Сценарий всегда занимает от 30 до 50 минут до окончания sh. Приведенный ниже сценарий создает дочерние элементы, которые запускают другой сценарий, который вызывает API с использованием curl, а API вызывает платежный шлюз с помощью curl и обновляет базу данных.
Если $number_of_items = 400; Что-то подобное, все запросы curl будут готово, но процессор будет настолько высок, что MySQL перестанет вставлять записи в базу данных. Таким образом, вы платите, но is_paid=0, MySQL не будут обновлять его, поэтому около 2% пользователей не будут иметь доступа к контенту, за который они заплатили
Если number_of_items=6000, это означает меньше скручивание потоков и большее количество элементов в потоке, процессор великолепен, никаких проблем, но не у всех людей возобновляется подписка. если у нас 60 тыс. клиентов, успешно создано 10 локонов, но, возможно, 1 конечная sh половина его работы, в итоге мы обновим 8 тыс. клиентов или что-то в этом роде, поэтому они даже не вызывают API оплаты
* 1012. *
Я хочу сохранить сравнительно большой пакет данных, чтобы процессор не был сумасшедшим, и хочу, чтобы у каждого ребенка не было тайм-аута.