- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Как удалить плохие SEO-ссылки и очистить ссылочную массу сайта
Применяем отклонение ссылок
Сервис Rookee
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Подскажите, что какую мысль вы хотите донести, суммируя время доставки двух страниц?
Для расширения кругозора, хотел пример кода с использованием какой то асинхронной библиотеки на пхп, когда скрипт, выполняя 2 задачи, отрабатывает за x сек, тогда как время затраченное на 2 документов составило 2х.
Вероятно, на базе этого: https://www.php.net/manual/ru/intro.parallel.php , что то типа аиохттп у питона. Чтобы в несколько строк, реализовать какой то асинхронный парсер например.
Для расширения кругозора, хотел пример кода с использованием какой то асинхронной библиотеки на пхп, когда скрипт, выполняя 2 задачи, отрабатывает за x сек, тогда как время затраченное на 2 документов составило 2х.
Это если через Guzzle - там под капотом, если я не ошибаюсь древний как мамонт multi_curl, который я ещё лет 10, как минимум, назад использовал. Для чего-то более современного нужно немного глубже копнуться в reactPHP или что-то подобное, но это могло занять больше времени.
Ну, и чтобы красивее, по-хорошему, нужно было бы парсить дом через какую-то более красивую по синтаксису библиотеку (если не ошибаюсь Crawler от Symfony подошёл бы, но у меня в докере какой-то вообще минимальный набор экстеншенов для php, нужно было добавлять, а мне лень было, ну а composer ругнулся).
multi_curl у меня тоже замечально работал на 1-10 записей. Когда пошли сотни и тысячи начались проблемы, зависания, пропуски.... лень было разбираться в проблеме.
Ну, и чтобы красивее, по-хорошему,
Мой пост был местами провокационный. Просто, хотелось разбавить абстрактные рассуждения о каких то либах примерами для понимания сути. И, может быть, дойти до каких то практических вариантов применения.
В вебстроительстве главная польза от асинк/авайт, это операции ввода-вывода, когда надо подождать (то, что на скрине 0.455 сек). Это же справедливо для запросов к базе данных. Примеры, что на пхп, что на питоне показывают - да, существенная выгода есть. Но, зачастую, выгода нивелируется практическим применением.
$promises = [
$function($client->getAsync('1074587')),
$function($client->getAsync('1074587')),
];
Тут почему-то серч съел кусок урла при редактировании поста, как я сейчас заметил.
Должно быть:
В вебстроительстве главная польза от асинк/авайт, это операции ввода-вывода, когда надо подождать (то, что на скрине 0.455 сек).
Вот это подождать на бекенде теоретически может быть заменено другими подходами. Гипотетический пример: нам нужно в кабинете мелкооптового продавца получить данные о товарах доступных на складе у оптового продавца, при заходе на страницу мы отправляем куда-то запрос, заносим запрос в очередь, загружаем страницу с неким js-виджетом, на котором написано "Получается информация" и уже он делает запросы к серверу, получая информацию исполнен ли запрос. Или же даже сам виджет может общаться с сайтом оптовика по ajax, web-socket'ам или, наверное, выше рекомендованным server-sent events. В этом случае переносим переносим на сторону клиента.
Но, зачастую, выгода нивелируются практическим применением.
Бекенд обычного веба больше синхронный по логике, чем асинхронный. Грубо говоря, сначала получаем информацию о пользователе, а потом смотрим, что ему можно показать. Чем сложнее проект и чем ближе к веб-приложениям, а не вебсайтам, тем больше там места асинхронности. Имхо, естественно. :)
Грубо говоря, сначала получаем информацию о пользователе, а потом смотрим, что ему можно показать.
Там по дороге, асинхронность можно использовать. Кстати, архитектура питоновских асинхронных фреймворков намекает.
Кусок миддлевари фастапи. (аиохттп похожий принцип: оперируем 3 объектами app, request, response)
В процессе обрастания данных для вывода пользователю, например, с запросами к бд, попытаться провернуть, похожее на то, что мы увидели в примерах с парсингом. Как только появляется новый (например, определен ИД документа, по которому можно достать его контент), его тут же в таски. Параллельно, обрабатывая данные в нужном нам виде. Короче, так, чтобы итоговое время работы было меньше суммы времени исполнения запросов, каждого по отдельности.
Совсем просто: (10 запросов по 2мс (20) выполнены за 10 мс) ? "асинк во всей красе" : "плохой асинк, хотя кругом авайты"
Или же даже сам виджет может общаться с сайтом оптовика по ajax, web-socket'ам или, наверное, выше рекомендованным server-sent events. В этом случае переносим переносим на сторону клиента.
Это вариант на самом деле так себе. Вообще есть такие штуки как api gateway, которые могут проксировать запросы, агрегировать их, выполнять синхронно и параллельно, подставлять результат из первого запроса во второй, например мы использует krakend что бы клиент не ходил на кучу микросервисов, а ходил на кракен а кракен уже собирал ответы по grpc от разных микросервисов
Бекенд обычного веба больше синхронный по логике, чем асинхронный. Грубо говоря, сначала получаем информацию о пользователе, а потом смотрим, что ему можно показать. Чем сложнее проект и чем ближе к веб-приложениям, а не вебсайтам, тем больше там места асинхронности. Имхо, естественно. :)
Асинхронность обычно используется для обработки запросов/написании серверов. В случае сайтов, такой сервер поднимается сразу с загруженными в память данными, например подключение к БД, кешеру общее на все запросы.