Нет, можно по подробнее?

Нет, можно по подробнее?

это кому вопрос?

Мне просто кажется если вы пишите классы и у вас много повторяющегося кода, то вы не так классы описываете

Вопросы был к Кириллу

Вопросы был к Кириллу

Просто берешь php файл и вставляешь в него клиентскую и серверную логику

И в чем отличие будет?

объявляешь <script> var peremennaya = <?php echo $peremennaya ?> <s/cript>

Так делают лучшие в нашем мире

Я понял, вы стебетесь над о мной

Нет, что вы

Это есть на сайте битрикса

Сам лично видел

Тимур, если ты из Москвы, то почему ты в этом чате?

Ну живу между двух городов. Так получилось, но так как большинство знакомых и коллег из Мск, указал в профиле этот город. Сам из уфы.

Кто- нибудь в реальных проектах асинхронный php использовал? Есть опыт?

Кто- нибудь в реальных проектах асинхронный php использовал? Есть опыт?

Нет, а смысл?

Ну, например, чтоб сокеты слушать

Я просто не пойму от куда тяга все усложнить

Я просто не пойму от куда тяга все усложнить

Чтоб продать себя за большие деньги)

Кто- нибудь в реальных проектах асинхронный php использовал? Есть опыт?

Мы применяем технологию асинхронного джаваскрипт и иксмл. Используем библиотеку jQuery

Мы применяем технологию асинхронного джаваскрипт и иксмл. Используем библиотеку jQuery

Я кстати так и не разобрался в асинхроном жс

Я кстати так и не разобрался в асинхроном жс

Вы говорили что используете ajax

Говорю же что не разобрался, может я термины не правильно могу использовать

Кто- нибудь в реальных проектах асинхронный php использовал? Есть опыт?

Загуглил, сначала подумал что ты говоришь о буфферизации, но нет оказывается есть библиотеки имитирующие промисы. Надо изучить

Мы применяем технологию асинхронного джаваскрипт и иксмл. Используем библиотеку jQuery

Ну это клиент-сайд, а на серверной части?

А зачем он на серверной части?

А зачем он на серверной части?

Например сокеты слушать

Загуглил, сначала подумал что ты говоришь о буфферизации, но нет оказывается есть библиотеки имитирующие промисы. Надо изучить

Да, eventloop полноценный

Интересно, надо будет почитать. Завтра с мнением вернусь на этот счёт

Например сокеты слушать

а чем elephant.io не устроил?

@nikolay_rovneyko а вы в своих проектах вебсокеты используете?

а если нужно развернуть самим вебсокет

то используем nodejs

Потому что считаем, что нет смысла городить огород

то используем nodejs

А чем вам jQuery не подошёл? Или там этого нет

А чем вам jQuery не подошёл? Или там этого нет

Нет, жаль, что jquery решает не все проблемы

Большинство клиентов не хотят переплачивать за VPS/VDS чтоб работать с сокетами на php. И по-моему сокеты и эмитация асинхронности php не связанные вещи друг с другом...

У нас клиенты только на своих серверах

то используем nodejs

Как ни странно аналог на NodeJS получился менее производительным в те моменты когда из эвента было необходимо обеспечить запрос к БД

сомневаюсь, что клиентам на хостингах нужен веб сокет

Как ни странно аналог на NodeJS получился менее производительным в те моменты когда из эвента было необходимо обеспечить запрос к БД

🙈

Большинство клиентов не хотят переплачивать за VPS/VDS чтоб работать с сокетами на php. И по-моему сокеты и эмитация асинхронности php не связанные вещи друг с другом...

Почему? (Это я к последнему предложению)

Как ни странно аналог на NodeJS получился менее производительным в те моменты когда из эвента было необходимо обеспечить запрос к БД

Костыльный ассинхронный PHP оказался стабильнее?

Пардон, производительнее?

Костыльный ассинхронный PHP оказался стабильнее?

Да, почти в 2.5 раза.

Да, почти в 2.5 раза.

В каких попугаях измерения происходили?

Может быть дело было в оптимизации или неумении развернуть?)

Почему? (Это я к последнему предложению)

Потому что асинхронность это деление выполнения скрипта на паралельно исполняемые ветки. А вебсокет это канал работы сервера и браузера для беспрерывного обмена информацией в реалтаим

Это тема для круглого стола я думаю как раз подойдёт

Потому что асинхронность это деление выполнения скрипта на паралельно исполняемые ветки. А вебсокет это канал работы сервера и браузера для беспрерывного обмена информацией в реалтаим

Один мой друг разработал бесконечный коннект с сервером через setTimeout(..., 100)

В каких попугаях измерения происходили?

В утилизации CPU

сокеты не нужны

пардон, setInterval

только он упадет

бесконечное количество запросов стремится к постоянному коннекту

Может быть дело было в оптимизации или неумении развернуть?)

Не думаю - есть как опыт и в разработке под обе технологии так и в администрировании linux

Потому что асинхронность это деление выполнения скрипта на паралельно исполняемые ветки. А вебсокет это канал работы сервера и браузера для беспрерывного обмена информацией в реалтаим

Это многопоточность. Асинхронность это про передачу ресурсов другому потоку исполнения до наступления определенного условия

А про канал -верно. но тут и проблема PHP, живущего только до исполнения запроса. А PHP-CLI отожрет слишком много ресурсов на поток

Была статья на Хабре как многие путают многопоточность с асинхронным исполнением программного кода. Но всеравно вещи не связанные с вебсокетом не думаете?

Была статья на Хабре как многие путают многопоточность с асинхронным исполнением программного кода. Но всеравно вещи не связанные с вебсокетом не думаете?

Почему нет? Есть процесс, который слушает сокет, и не потребляет ресурсов, пока не получит пакет с сокета.

А как это связано с php если слушатель сервера по сокет каналу отрабатывает на стороне браузера?

Кстати, я не имел в виду взаимодействие с браузером - я имел в виду tcp-сокеты. Например для работы с каким-то обородованием, например с КИП

Слушатель в данном случае находится на стороне сервера

Так бы сразу и сказали, а то мы сидим тут головы ломаем 😂

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

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

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

Делал эмитацию ассинхронности. Задача была по парсингу xml на >200000 строк. После структурирования данных распараллелил процесс на добавление/обновление записей в базе в разных таблицах. Т.е. одновременно запись шла в таблицу пользователей, товаров, новостей.

Свыше этой задачи потребности не возникало.

А как паралелили? Отдельные таски на чанки делали?

Какой стек для этого задействовали?

Не углублялся в такие дебри. Задача разовая. Половина работы решилась копипастом.

Жаль(

Думал использовать как тему на круглый стол, но никого не заинтересовал)

На практике потребность в таких возможностях крайне редко возникает на php. А если всё-таки часто то для такого проекта не нужен php. И для клиента был либо неправильно выбран язык, либо компания решила расширяться, но на технические расширение заложила заложила малые бюджеты. И вот приходится мучить php костылями и заплатками в виде модулей расширения. Я так считаю. Пусть потоками и распаралеливанием заниматься спецы на языке с более высоким порогом вхождения. Ну а мы в свою очередь просто будем получать/отправлять запросы и ответы по их апи. Человек аркестр это конечно хорошо, но не на высоконагруженных проектах которые действительно требуют многопоточности.

Ну PHP уже давно не язык для бека сайтиков, это вполне себе язык общего назначения. Порог качественного вхождения в PHP тоже вырос. Почему же не использовать имеющуюся инфраструктуру на PHP при необходимости реализации асинхронной работы? Это не костыли а вполне рабочая технология. Которая может сильно ускорить любой проект на PHP

И опять же: многопоточность != асинхронность

Северный язык. Врятли общего назначения. Я конечно понимаю что можно упаковать интерпретатор в приложение и сделать тот же эксешник на php. 😁 но...

Северный язык. Врятли общего назначения. Я конечно понимаю что можно упаковать интерпретатор в приложение и сделать тот же эксешник на php. 😁 но...

Для чего екзешник? Почему не запускать через интерпретатор? Экзешник это просто способ упаковки исполняемого кода. PHP это скриптовый язык общего назначения. Даже библиотека для гуя на него есть.

Ну вот можете понять тему за круглым столом. Интересно кто что думает. По этому поводу.

Меня заинтересовало

Это тема больше для холивара чем для обсуждения) Лучше что-то про более применимое на практике, чем захочется заняться после того, ка встанешь из-за стола))))