Тут почему-то серч съел кусок урла при редактировании поста, как я сейчас заметил.
Должно быть:
$promises = [ $function($client->getAsync('https://searchengines.guru/ru/forum/1074587')), $function($client->getAsync('https://searchengines.guru/ru/forum/1074587')),];
Вот это подождать на бекенде теоретически может быть заменено другими подходами. Гипотетический пример: нам нужно в кабинете мелкооптового продавца получить данные о товарах доступных на складе у оптового продавца, при заходе на страницу мы отправляем куда-то запрос, заносим запрос в очередь, загружаем страницу с неким js-виджетом, на котором написано "Получается информация" и уже он делает запросы к серверу, получая информацию исполнен ли запрос. Или же даже сам виджет может общаться с сайтом оптовика по ajax, web-socket'ам или, наверное, выше рекомендованным server-sent events. В этом случае переносим переносим на сторону клиента.
Бекенд обычного веба больше синхронный по логике, чем асинхронный. Грубо говоря, сначала получаем информацию о пользователе, а потом смотрим, что ему можно показать. Чем сложнее проект и чем ближе к веб-приложениям, а не вебсайтам, тем больше там места асинхронности. Имхо, естественно. :)
<?php require_once('../protected/vendor/autoload.php');use GuzzleHttp\Client;use GuzzleHttp\Promise\PromiseInterface;$client = new Client();$timing = [];$function = function (PromiseInterface $promise) use (&$timing) { $startTime = microtime(true); return $promise->then(function ($response) use ($startTime, &$timing) { $dom = new DOMDocument(); libxml_use_internal_errors(true); $dom->loadHTML((string) $response->getBody() , LIBXML_HTML_NOIMPLIED | LIBXML_HTML_NODEFDTD); libxml_clear_errors(); $title = $dom->getElementsByTagName('title')->item(0)->nodeValue; $endTime = microtime(true); $timing[] = $endTime - $startTime; echo "Request time: " . ($endTime - $startTime) . PHP_EOL, $title . PHP_EOL; });};$startTime = microtime(true);$promises = [ $function($client->getAsync('1074587')), $function($client->getAsync('1074587')),];GuzzleHttp\Promise\all($promises)->wait();echo "Вместе: " . (microtime(true) - $startTime) . PHP_EOL;echo "сумма раздельно: " . array_sum($timing) . PHP_EOL;
Request time: 0.25532793998718PHP асинхронность, многопоточность, параллельность - Веб-строительство - Сайтостроение - Форум об интернет-маркетингеRequest time: 0.26136803627014PHP асинхронность, многопоточность, параллельность - Веб-строительство - Сайтостроение - Форум об интернет-маркетингеВместе: 0.26281094551086Total time: 0.51669597625732
Это если через Guzzle - там под капотом, если я не ошибаюсь древний как мамонт multi_curl, который я ещё лет 10, как минимум, назад использовал. Для чего-то более современного нужно немного глубже копнуться в reactPHP или что-то подобное, но это могло занять больше времени.
Ну, и чтобы красивее, по-хорошему, нужно было бы парсить дом через какую-то более красивую по синтаксису библиотеку (если не ошибаюсь Crawler от Symfony подошёл бы, но у меня в докере какой-то вообще минимальный набор экстеншенов для php, нужно было добавлять, а мне лень было, ну а composer ругнулся).
Для вебсокетов я использую центрифугу не используя какие то велосипеды =))
Ну, мне тогда нужно было бы, чтобы программеру было меньше разбираться. То есть, PHP был первым вариантом выбора + нужно было с реактом (который JS, а не reactPHP) разобраться, потому что сторонняя библиотека, которую я решил использовать в проекте, был на нём написана. И чтобы я мог подключаться время от времени не тратя время на изучения нового. :)
Подскажите, что какую мысль вы хотите донести, суммируя время доставки двух страниц?
Таких инструментов же уже вагон и маленькая тележка:
- swoole- reactphp- workerman- amphp- roadrunner (app server)Это то что я знаю, тестил и живее всех живых. Но писать асинхронный код в php идея не очень благодарная, большинство драйверов блокирующие, надо писать а потом поддерживать обертки неблокирующие, большая часть библиотек написана в той парадигме что после запроса все чистится и в 98% случаев сторонних либ потечет память..... в целом это узкий инструмент достаточно, например чтоб реализовать свой сокет сервер и то если прям очень нужно, а то лучше на голанг все таки глянуть или на крайний случай на ноду
Для вебсокет-сервера использовали в своё время (лет 5 назад) https://github.com/ratchetphp/Ratchet , кажется, поверх reactPHP написан. Пришлось, правда, копнуться поглубже, так как в лоб текла память, но когда понял логику, то исправил ошибку у нас в коде (деталей уже не помню, кажется, реальность и документация отличались) и проект заработал. Через некоторое время проект задвинулся на задний план и я о нём призабыл. Через какое-то длительное время (может через несколько месяцев, если не через полгода) решил зайти глянуть, что там - все ок, утечек не было, сам вебсокет-сервер работал. Из одного источника, если мне память не изменяет данные получались. С другого - нет, но там чисто программно нужно было что-то типа сессии перезапускать раз в несколько дней, то есть, это не проблема ни php, ни его ассинхронности, а чисто организационный вопрос. То есть, асинхронность в пхп уже давно есть, но да, согласен, нужно писать с оглядкой на окружение на сервере.
Cмотря, что вы имеете в виду под одинаковым видом файлов и какая задача. Если одинаково выглядящие, то замените "o" латиницей на "о" кириллицей и получите одинаково выглядящие имена файлов. По идее такое же даже в винде должно прокатить.
А вот именно, чтобы точно одинаковое, то система не даёт сделать.
Не работал. Можно было только подключить карту и оплачивать что-то. Теперь можно и получать.
Но из минусов - это временная поблажка, если верить пресс-релизу, кажется, до 30 июня. Но надеемся, всё же лед сдвинулся.
Интересно, как это стыкуется с введенными за последние годы стопиццот условиями по финмониторингу и прочему контролю.
Может теперь и Вебмани включат?
Там суммы до определенных величин не подпадают под финконтроль. Ну, и требования от банка к банку отличаются.