Деградация передачи данных через php stream_socket_server и неблокируемый режим?

batyrmastyr,

вы сперва скажите, чего же вы хотите от пыхи, чтобы она перестала быть идиотской:
1) пыха вместо уже оптимизированного решения дала лишь несколько базовых кирпичиков. За это назвать тупым почти любой язык, ведь мало в каком языке есть готовые средства, например, для работы с .ods или .csv, а не базовые «прочитать из файла N байт / строку».
2) встроенные функции языка обязаны быть оптимальными. Сколько там для Го более оптимальных библиотек для работы с JSON? Считать ли Го идиотским языком, за то, что встроенные средства неидеальны?
3) У вас есть адекватные претензии, но я вас, гения, не понял.

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

Цитату пожалуйста, где я писал, что виноваты все, кроме пыхи. Я писал, что если писать код без оптимизации, то и работать он будет медленнее оптимизированного кода. Да, такое вот капитанство.

Файлы на каждое соединение создаёт не php, а система, сюрприз, а задачи обкладываться костылями из-за корявостей операционки ради «задачи 10 тысяч соединений» у него пока не было.

Сокеты работают так же, как у всех, я вам уже раз пять писал. Задействуешь опцию reuse_port - можешь тратить на порядок-другой меньше ресурсов, как Workerman, nginx и многие другие, а не задействуешь - получишь непонятки как автор вопроса. В любом языке.

Ну так докажите, что они не страдают от проблем автора вопроса, но при этом не используют reuse_port. Исходники самого Го в студию.
То, что с reuse_port пыха работает не хуже прочих я уже показал. Да, теми самыми тестами.

Расскажите подробнее, что вы "уже показали" в приведенных тестах, я не понимаю, причем здесь: получение данных из базы, подготовка html и производительность в кол-ве ответов в секунду, когда мы говорим совсем о другом, о кол-ве подключений?
Каким образом so_reuseport решит вопрос с ограничением кол-ва файловых дескрипторов на процесс? Ну сможете вы расшарить этот файл на несколько процессов, но лимит ведь никуда не денется, разве нет? Разумеется workerman это использует, т.к. подразумевает запуск нескольких воркеров, но причем здесь обсуждаемый вопрос?
Если вы знаете решение, то напишите ваш правильный вариант и проверьте как он работает. И если там все ок, то разместите здесь в ответах. Но вместо того, чтобы написать 2 строчки и проверить, вы зачем-то теоретезируете об исходниках Go.

Деградация передачи данных через php stream_socket_server и неблокируемый режим?

batyrmastyr,

я уже написал в чём: вы хотите фигачить код в лоб и верите, что кто-то за вас обязан его оптимизировать.

Даже если так, то где здесь вранье?
Оптимизировать код это прекрасно, только вот речь про встроенные функции языка, а не код, неужели вы этого не заметили?

Макось оптимизировала, фряха оптимизировала, Go оптимизировал (при этом дал своё API), линукс не стал, пыха не стала, но виновата у вас только пыха. Вы либо тогда уж и ядро линукса говном назовите, либо с пыхи глупые обвинения снимите

Круто, у всех все нормально, но у вас виноваты они все, а не пыха.
Можно и ядро линукс говном назвать, но речь ведь не об этом. Пыха и линукс мягко говоря разные вещи, и ваша попытка их связать вместе смахивает на демагогию. Еще раз, Go, python, нода тоже ведь на линуксах работают.

И да, она без проблем всё вытащит, если правильно ей об этом сказать (думаю найти отличия действий автора вопроса от авторов сервера вы сами сможете).
Выступит не хуже Go если без тяжёлых вычислений.

Куда и что она вытащит? Сокеты в php при workerman как-то иначе начинают работать и не нуждаются в файловых дескрипторах? К чему эти тесты, когда мы совсем о других вещах говорим?

Это забавно, как вы пытаетесь меня убедить, что нерабочее решение лучше, чем рабочее. Так что там с nginx? Судя по вашим заявлениям, вы наверное используете только Apache prefork и "правильно" его настраиваете? Потому как Apache не виноват, что есть лучшее решение, и нужно мучаться с ним, так?

Деградация передачи данных через php stream_socket_server и неблокируемый режим?

batyrmastyr,

Ещё раз, вы либо искренне заблуждаетесь, либо нагло врёте. Функции использованные автором, как и множество других, являются простейшими прослойками над вызовом системных функций и в других языках будет ровно то же самое, если открыть несколько тысяч сокетов и удерживать их. Это механика юниксов в целом.
Отсутствие «таких» проблем в «других языках», а точнее в одном лишь Go, означает лишь то, что он втихую использует один системный сокет для получения данных от нескольких клиентов. Точно так же, как это делает nginx.

Вру в чем? Ну возьмите не Go, а python, и будет тоже самое (но не тоже самое что в php). tcp-сокеты и unix-сокеты вещи разные, если вы привяжете один к другому, это, конечно, весело, но на фиг не нужно для конкретной задачи. И еще раз, можно сколь угодно говорить, что все дураки, а php истинно верный, и развлекаться с проблемами, либо принять, что правильное решение то, которое работает, а не наоборот.
И пример с nginx в этом плане очень хорош - хочется обрабатывать 10 запросов, а не 10 000 - берем Апач с кошерным разделением. Либо берем nginx и работаем с хорошей производительностью. И вот же незадача, Апач принял, что это верное решение и тоже стал так делать.

Увеличить лимит соединений tcp для websocket?

OneTwoThreeFourFive,

После перезагрузки настройки файловых дескрипторов сбрасывались до стандартных 1024

Нужно указывать в настройках, а не один раз сменить.

каким-то образом подключается 1050 и немного больше

все зависит от кол-ва разрешенных файловых дескрипторов на процесс и кол-ва файлов уже используемых вашим скриптом.

Я могу лишь подсказать, что есть такая проблема, сам с ней сталкивался, хотя и давно. Но когда ограничение чуть больше 1000, то это скорее всего оно и есть. Здесь уже 2 человека покапав в этом направлении смогли решить. Когда я с этим сталкивался, вроде бы php писал конкретную ошибку, что не хватает файловых дескрипторов. Нужно смотреть, где конкретно спотыкается, смотрите логи.

Деградация передачи данных через php stream_socket_server и неблокируемый режим?

batyrmastyr, в 3ий раз, проблема только в php, в других языках ее нет. Если подразумеваете, что остальные языки обложились костылями, то нет - создавать файл на каждый коннект, это, конечно, очень похоже на unix way, но всегда нужно исходить из целесообразности. Если вам кажется что вы идете unix путем и при этом отстрелили себе ноги - вероятно вы делаете чтото не так, и не надо пинять на операционку.

Увеличить лимит соединений tcp для websocket?

OneTwoThreeFourFive, там antobra писал, что нужно еще перенастроить sysctl для highload, только увеличения лимита на файловые дескрипторы недостаточно. Это делали?

Увеличить лимит соединений tcp для websocket?

Как раз решали подобную проблему здесь https://qna.habr.com/q/1092856?e=12152650, связанную с "особенностями" php.

Деградация передачи данных через php stream_socket_server и неблокируемый режим?

antobra, отлично, спасибо что отписались о решении.
Надо будет посмотреть, как в этом плане работает MacOS.

Деградация передачи данных через php stream_socket_server и неблокируемый режим?

batyrmastyr, а зачем мне документация nginx? Когда как я уже писал, проблема только в php, и поэтому это идиотское решение. Отправьте читать документацию разработчиков других языков, в которых нет подобных проблем. Второе, nginx реализуя http работает мягко говоря совсем иначе, чем постоянные коннекты в сокетах. И если там, каждое соединение - это работа здесь и сейчас, то из 2000 сокетов большинство скорее всего будут простаивать в произвольный момент времени.

Деградация передачи данных через php stream_socket_server и неблокируемый режим?

batyrmastyr, то что в Unix все - это файл, это да. Но совсем не обязательно каждый отдельный коннект прогонять в отдельном файле. Тем более, очевидно, что для сокетов может потребоваться не 100 соединений, а гораздо больше. И в каком-нибудь python или go, это учли и сделали нормальное решение, а в php приходится манипулировать с лимитами файловых дескрипторов. Поэтому я бы не назвал это удачным решением, раз есть решения лучше.
У автора macos, а не Ubuntu.

Может ли само ядро Linux автоматически будить примонтированные диски в простое? Как определить, какой процесс обращался к диску?

Ну и софта всякого хватает отслеживающего общение с дисками, iotop и тому подобное

Взаимосвязанные сайты?

Не так трудно, как кажется на первый взгляд.
MySQL - это старая СУБД? Или MySQL 5.7 старая? В любом случае делать подобное через СУБД очень плохой вариант, не то, чтобы невозможно, но очень близко к этому из-за проблем, которые получим. А если делать, не через СУБД, то абсолютно без разницы какая она.

Почему функция get_defined_vars выводит в массиве два раза [_SERVER] => Array?

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

Запустится ли скрипт по cron, если предыдущий скрипт все еще выполняется?

Вот почему было бы не потратить 10 минут и попробовать?

Почему функция get_defined_vars выводит в массиве два раза [_SERVER] => Array?

Имя, то был намёк, прочитать в Google, что GLOBALS это

Ассоциативный массив (array), содержащий ссылки на все переменные, определённые в данный момент в глобальной области видимости скрипта. Имена переменных являются ключами массива.

И ваш массив с ключем _SERVER в GLOBALS это ссылка на _SERVER.

Почему функция get_defined_vars выводит в массиве два раза [_SERVER] => Array?

А что google говорит про GLOBALS?

Безопасно/правильно ли передавать логин и пароль в заголовке по HTTPS протоколу?

https для того и сделан, чтобы шифровать передаваемые данные. Опасность - подделка сертификата.
Но в вашем варианте, я бы больше опасался того, что вы пароль прописали прямо в строку, которая сохранится, например в истории bash и будет фигурировать в списке выполняемых команд.

Как решить проблему запуска ОС загрузчика GRUB?

в котором ничего невозможно сделать, так как отсутствуют элементарный sudo

А sudo при установке выбиралось? Т.е. вопрос в том, вы загрузились в текстовом режиме или в режиме восстановления?
В любом случае - смотреть логи. И разбираться с драйвером для видюхи.

Какой будет ответ var_dump(0 == "wow"); ??

asdasdqwe, именно так.
При сложении оба операнда должны быть числами, поэтому нечисловые операнды преборазуются в числа. По правилам приведения типов в php "10 Small Pigs" -> 10. И то, даже 7.4 уже выдает предупреждение.
Тоже самое касается и сравнения для php7. Но в 8 версии сравнение изменили, и теперь в строке должно быть число, и только оно, без всякого постороннего мусора.

Еще раз, есть простое приведение типов, а есть дополнительная проверка на число в 8 версии.

Какой будет ответ var_dump(0 == "wow"); ??

То есть идет сравнение "0" == "wow" //false

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