Как правильно создать объект класса Request в Workerman?

azuf,

Это уже пошли выкрутасы.

Это да, например:

Вот только он против современного так называемого ООП. Его слова: "Я придумал термин ООП, но не имел ввиду C++". Есть еще его высказывания подобной направленности.

Дейкстра в прошлом веке точно не имел ввиду современную реализацию ООП, но вас же это не остановило.

И чем же ФП сложное? С любой стороны ФП проще. Потому что Лямбда-исчисление само по себе простая модель. Может ли быть полноценный удобный язык проще чем Лисп? Идея о том, что приложение это просто функция - простая. Даже такие сложные приложения как компиляторы/интерпретаторы прекрасно реализуются в таком стиле. Можно легко разложить такое приложение на функции и держать все это в голове. Подобное приложение в стиле современного ООП будет монструозным и запутанным, его невозможно будет держать в голове.

Я и не говорю, что сложное. Но и ООП не сложнее, объект сам по себе простая модель. Хотя причем здесь Лямбда-исчисление, когда мы рассматриваем подходы с точки зрения программиста, я так и не понял.
Какой вы "случайно" выбрали пример. Компилятор это та задача, где у ФП нет особых проблем, побочных эффектов практически нет, самих эффектов мало, просто сказка. А вот с ООП, ах да, там тоже никаких проблем, т.к. побочек нет, то и в ООП будут преобладать чистые функции. В принципе это будет почти тот же код, что и при функциональном подходе.

Человек - не машина. Инструкции не любят читать и плохо понимают. Потому что императивность. Декларативный язык математики понимают намного большее количество людей.

Предвосхищение основания. Опять ни на чем не основанные, безаппеляционные утверждения.
Эмпирически доказано, что инструкция это пока единственный способ выполнить задачу так как нужно. И это касается не только людей, но и машин. В том же декларативном sql периодически надо переходить на императивные прямые указания.

Это не означает, что идея не дурацкая. Повсеместно - значит используется большинством. Большинство - всегда ошибочно, потому что нет своего мнения, потому что толпа, у толпы нет интеллекта. Все побежали и я побежал. Самые лучшие идеи всегда не находятся на поверхности.

Это также не означает, что идея дурацкая.
Остальное уже полный бред.
Выключите компьютер, им ведь пользуется большинство, а значит ошибочно им пользоваться. Да и вообще все электричество. Можно и не есть, и не пить, ведь так вообще все делают!

Можно ли настроить запросы к php через вебсокет и http одновременно?

rPman,

websocket это расширение http запроса, т.е. там добавляются специфические заголовки и можно отправлять туда-сюда пакеты в одном соединении.

Websocket это отдельный независимый от http протокол. Это не расширение http запроса.

Как правильно создать объект класса Request в Workerman?

azuf, про workerman и fpm уже расписал. Но толку, вы все проигнорировали.

Не только я плохо отзываюсь о так называемом ООП, но и многие всемирно известные деятели в IT. Не только Дейкстра. Нужно привести их имена?

Вы так ничтоже сумняшеся поставили себя в один ряд с Дейкстрой, ну-ну...

По вашему современная индустрия лучше во всем разбирается чем лауреаты премии Тьюринга?

По вашему вы лучше во всем разбираетесь, чем современная индустрия и лауреаты премии Тьюринга. Алан Кэй кстати именно за внедрение ООП получил ее, забавно, да?

Есть универсальные критерии для оценки. Простое лучше сложного. ФП - простое, ООП - сложное. Чем меньше кода - тем меньше проблем. ФП - мало кода, ООП - много кода.

Эта логическая ошибка называется предвосхищение основания, она у вас любимая. ФП не такое уж и простое, а ООП не такое и сложное.
По вашему идеальный программист тот, который не написал ни строчки кода.

Человек не приучен мыслить в моделях вычислений с состояниями. Зато с детства приучается мыслить в аппликативных моделях вычислений. Потому ФП - естественная модель программирования, а ООП - нет.

Вам когда в детстве давали инструкцию "купи хлеба и вынеси мусор", вы покупали хлеб и сразу его выбрасывли в виде мусора? Или все же знали, чтото о состояниях и обрабатывали их независимо?

У большинства нет своего мнения. Они просто следуют за кем то. Так было и будет всегда. Поэтому аргумент большинством - не аргумент.

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

Как правильно создать объект класса Request в Workerman?

azuf, вы реально хотите вести техническое обсуждение с помощью казуистики и демагогии?.. Надергать фраз и агитировать не нужно, просто запустите ваше идеальное решение в работу и зарабатывайте миллионы, раз "мнение большинства - всегда ошибочно, ибо большинство людей..."

Большинство не могут ошибаться?

Могут. И глаза могут ошибаться, и мозг. Вопрос вероятности, кто с большей долей вероятности ошибается: те, кто ежедневно используют в промышленных масштабах решение, или некий azuf с форума с аргументацией "большинство могут ошибаться, значит я прав, т.к. не смог изучить ООП". Даже и не знаю...

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

Насчет "выглядит понятным" вы уже лукавите, сами же говорили, что не осилили, значит не можете это оценить.
Что "зло"? Изменяемые состояния? Ну как бы без них никак не получится. "Запутанные" - зло? Так вы не запутывайте. Вообще запутать можно при любом подходе, а ООП предлагает очень годные инструменты, чтобы не запутывать. Почему вы решили, что выигрыша нет? Просто так захотелось? А "лишний код" вообще не аргумент.

Известная мантра. Любой реальный пример ее опровергает.

Ага, реальный пример: php7 быстрее php5 в 2-3 раза по синтетическим тестам, что на практике все знают. Вам бы и к своему синтетическому тесту следовало бы добавить реальный пример, глядишь и все бы стало понятно. А то получается: на статику забьем, https тоже выкиним, nginx здесь будем использовать, чтобы помедленнее, а там не будем, чтобы побыстрее, при этом выполнять код мы вообще не будем (оно ж логично, проверять выполнение кода, без выполнение кода).

Не имеет значения. Никогда FPM даже не приблизится к производительности workerman или подобных апликейш серверов.

Звучный лозунг. Прям красиво! Сразу видно техническое обсуждение вопроса.

Не знаю, не тестил, но вообще, сервера на C++ могут быть медленнее серверов на Go. И даже медленнее серверов на Node.js (uWebsockets.js). Просто потому, что хуже написаны. Вы ведь не заботитесь о производительности, правильно понимаю? И другие не заботятся. Просто пишут код и всё. Опытных системных программистов мало. Поэтому в 2025 году большинством используется устаревший во всех смыслах FPM. Заметьте, большинством. Так как большинство всегда ошибочно

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

Смотря что понимать под сайтом. И смотря как будет устроен этот сайт. Блог это сайт? Блоги на Next.js даже без оптимизаций значительно производительней чем такие же, использующие php-fpm.

Вы прям на лозунги горазды сегодня. А куда делся workerman, откуда ни с того, ни с сего Next.js? Вы так забавно пытаетесь увести в сторону...

Так это на 1 ядре! На 8 ядрах ~300-400к rps. То есть во много раз превосходит fpm + nginx. И это всего лишь hello world. Будь что сложнее, fpm и 1000 rps не покажет. Это вообще смешно.

Вам эти цифры прям покоя не дают, что вы даже не читаете что я пишу.

За столько Next.js полноценную страницу отрисовывает.

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

FPM в реальных приложениях показывает <1000 rps и все другие показатели соответствуют. Это как сравнивать скорость велосипеда и автомобиля.

Ага, это как сравнивать скорость велосипеда и бетмобиля.

Как отключить возможность запуска командной строки на экране блокировки windows 11?

Ziptar,

Это невозможно сделать, обладая лишь ограниченными привилегиями в рабочей системе (другие уязвимости в расчет не берем).

Т.е. описана все таки ошибка. Но автор нас дезинформирует и на самом деле подобный сценарий не возможен.

Как отключить возможность запуска командной строки на экране блокировки windows 11?

Ziptar,

ошибка в ПО - это когда ПО работает не так, как ожидается. Здесь нет такой ситуации. Никакой существенной уязвимости здесь также нет, поскольку для возможности получить полные привилегии в системе - ими уже надо обладать на подготовительном этапе.
От борьбы же с ветряными мельницами в лучшем случае не бывает пользы. Обычно же бывает лишь вред.

Чуть развернутей, пожалуйста. Почему здесь нет такой ситуации? Почему "права себе повысить до админских" используя горячие клавиши спецвозможностей это ожидаемое поведение? И зачем вообще в ОС система прав, если это ожидаемое поведение?
Существенная уязвимость или нет, это уже другой вопрос. Эффективность борьбы с ними, тоже другой вопрос.

Как отключить возможность запуска командной строки на экране блокировки windows 11?

Ziptar,

наши вам соболезнования.

Ты о себе во множественном числе?! Ну, ладно...
А чего "соболезнования"? У меня абсолютно та же аргументация как у тебя, и даже более лаконично написано.

Как отключить возможность запуска командной строки на экране блокировки windows 11?

Ziptar,

нет, это не ошибка в ПО.

нет, это ошибка в ПО.

Как отключить возможность запуска командной строки на экране блокировки windows 11?

Ziptar,

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

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

Он оттуда может права себе повысить до админских и запустить любой экзешник

И это ошибка в ПО!
Ошибка вызванная багом или нет, ошибка с типом уязвимость, ошибка о критичности которой можно спорить, и т.д. Но это попрежнему ошибка, и она не перестанет ею быть, какиебы альтернативные способы взлома здесь не предложили и какое бы аналогичное ПО не вспомнили.

Как отключить возможность запуска командной строки на экране блокировки windows 11?

Ziptar,

чушь. Здесь нет никаких "ошибок", про права вообще какие-то ахинея.

Ну если не ошибку в ПО, то возможность "латать" что вы обсуждали выше? Крышу?
Ага, повышение своих прав до админских никак не связано с правами. Права, это не про права, это ахиней.

Как отключить возможность запуска командной строки на экране блокировки windows 11?

Ziptar,

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

Как уже писал, в другой ветке, вне зависимости от "физического доступа" ошибка в ПО остается ошибкой. А если "латать этот эксплойт просто нет смысла", то надо просто убрать всякие запросы пароля администратора локально, убрать всякие другие учетки и не вводить пользователей в заблуждение, что существуют какието права доступа.
И да, если данные зашифрованы?..

Как отключить возможность запуска командной строки на экране блокировки windows 11?

Zerg89,

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

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

Как отключить возможность запуска командной строки на экране блокировки windows 11?

Drno, то, что при физическом доступе больше возможностей для взлома, не отменяет того, что ПО должно работать корректно.

Как правильно создать объект класса Request в Workerman?

azuf,

Видимо Дейкстра был прав, сказав, что ООП плохая идея, которую могли придумать только в Калифорнии.

А "высокомерие измеряется в нано-Дейкстрах"©. Если серьезно, то неважно что он и о чем говорил в прошлом веке, ООП сейчас основная производственная парадигма.

Код в ООП стиле сложно понять. По крайней мере мне

Это всем так с непривычки. Потому что привыкли в программе мыслить другими критериями. Нужно просто писать код, и понимание придет само, по мере преодоления ошибок. Вообще ООП-шный код даже на незнакомом языке зачастую выглядит вполне понятным.

Откройте Techempower benchmark. Вчера тестировал workerman с помощью wrk, на одном ядре 50 000 запросов в секунду, на нескольких ядрах сотни тысяч. FPM с Nginx и стандартными настройками показывает 4 500 запросов в секунду.

Если бы все было так просто, но синтетические тесты мало информативны на практике. Что такое "запросы"? Это запросы к php или статика тоже? Не поверю, что веб-сервер на php отдает статику быстрее nginx. А если у нас сайт, то там большая часть это статика. Ок, допустим это api, и все запросы к php, "50 000 запросов в секунду" - это 20мкс на запрос, "4 500 запросов в секунду" - это 222мкс на запрос. За сколько у нас отрабатывает api-запрос, не беря тяжелое и совсем легкое, в среднем 50-100мс. Т.е.10-20 запросов в секунду, причем особо нет разницы для какого варианта, потому что php-код отрабатывает гораздо дольше расходов на веб-сервер. И это мы еще не тестировали как себя поведет php-шный вебсервер при реальных запросах, где работа с базой, ошибки, а иногда и фатальные и т.д. К примеру, fpm очень хорошо шарит память между своими процессами, а на сколько хорошо workerman это делает? Разумеется есть shared memory, но все же. Кажется, что цепочка nginx > php-fpm > php слишком длинная, и просто демон на php лучше, но в реальных условиях nginx может быть вообще не один, и шифровать надо, что проще всего опять в nginx сделать.

Буду разбираться. Посоветуйте что нибудь практичное для обучения. Чтобы по больше практики. От толстых книг клонит в сон.

Сложно чтото советовать, со временем забываешь, что помогало. Чисто субъективно

тут

Обобщенно, не зная уровня обучающегося - я бы начал с примитивных описаний ООП как оперирование с объектами реального мира, на самом деле это не так, но чтобы въехать помогает. Дальше писать код, читать код популярных решений, если не идет (а оно сразу не пойдет) - берешь более простые задачи или решения. Плохо если проект не живой, т.е. в него не прилетают постоянно правки по реальным требованиям, именно внесение изменений показывает, где ошибся.
Прочитать про распространенные ошибки, супер-классы и т.п. На первых порах лучше забыть, что статика вообще существует, а то есть риск свернуть не туда. Знал одного программиста из крутого банка, который писал статикой, по-сути он процедуры оформлял как методы, а классы были как namespace, и делал так много лет, но это было давно. Писать длинные методы по-привычке нормально, даже если их не разделить сразу, когда в будущем прилетят правки они покажут, что это надо было сделать, и где это надо было сделать. Использование примитивов не преступление, но только внутри объекта, если данные поплыли между объектами нужно быть очень осторожным. Иначе, когда с примитивом нужно будет передать еще данные, придется перепиливать весь путь, поэтому в таких случаях лучше сразу заложить объект, к нему прицепить дополнительные данные не проблема. Патерны не являются каким-то уникальным инструментом, но удобно в названии классов использовать название патерна, чтобы сразу было понятно для чего класс. Наследование это связь между родственными объектами, не стоит его использовать для других целей.
Прочитать про dependency injection, для начала понять, что зачастую удобнее объект передать из предыдущего обработчика, а не создать в текущем.
Прочитать про SOLID, и повторять их для себя время от времени. Дело в том, что в начале достаточно будет только буквы S, одно только соблюдение single responsibility убирает огромное кол-во проблем, остальное придет позже. А есть еще всякие GRASP и не только.
Что касается ООП в php. Private/protected/public обязательны всегда, и для методов, и для свойств. Static поначалу забыть, что он есть. Interface можно оставить на потом. Trait я бы не использовал вообще.
В общем, у меня получается, что нужно больше читать не как надо писать, а как не надо писать.
Я не знаю хороших книг по ООП, боюсь, в любом случае, только практика поможет. Из того, что вспомнилось. "Чистый код" - это что-то оторванное от жизни, вообще не стоит читать. "Совершенный код" - отличная книга, но вряд ли сильно поможет в начале изучения ООП. Патерны - это больше как принято называть устоявшиеся решения, лучше знакомиться после практики.

.

Помощь в решении задачи 96, Sql-ex?

Adamos,

учить вежливости незнакомых людей - это как раз неуважение. А учитывая, что они еще, скорее всего, старше и опытнее - просто глупость.

Да, ладно, если эти незнакомые люди не умеют себя вести можно и нужно учить. И тем более, если они старше и опытнее, это отягащающий фактор, т.к. у них было больше времени. Помоему само допущение, что старший может быть невежлив к младшему, только на основании, что он старший, мерзко. В плане вежливости, все в равных правах.
Другое дело, что никто и не был невежлив, да переписка неформальная, да не обвешана формальными вежливыми словами, но критиковали конкретную работу, и никто не переходил на личности. В принципе, как вы и написали, что как "в рабочей команде". Нет конструктивной критики кода, нет роста.

MySQL/MariaDB. 10 vs 11 version. Индексы. Странное поведение?

N,

Как дальше с этим жить и лопатить проекты с JOIN'ами(это грубо говоря) при переносе?

А зачем спешить переходить? Переходите тогда, когда результаты тестирования новой версии вас устроят. Сейчас похоже рано (хотя я не верю в оптимизатор, который никогда не ошибается).
Например, некоторые до сих пор используют mysql 5.7, и не только потому что все подводные камни известны, просто 8ка показывает себя хуже при тестировании. И несмотря на проблемы 5.7, стабильность важнее.

MySQL/MariaDB. 10 vs 11 version. Индексы. Странное поведение?

N,

я был уверен, что всё будет "чики-пуки"

Соберите статистику и посмотрите изменится ли план. Хотя за "несколько дней" она должна была ее сама собрать.
Я смотрю, 11 версии всего 2,5 года, и в ней сильно поменяли стоимостную модель. Подождем, может кто в теме и подскажет.

MySQL/MariaDB. 10 vs 11 version. Индексы. Странное поведение?

N, оптимизатору чтобы построить хороший план, нужно понимать какие данные и в какой пропорции лежат в таблицах. Тупой пример, вы залили в таблицу много данных, а оптимизатор думает что она маленькая и вместо использования индекса пойдет фул-сканом. Разумеется это не так глупо работает, но при больших и быстрых изменениях лучше все таки вручную попросить собрать статистику, на всякий случай.
Указать какой индекс использовать - нормально. Но, нужно быть очень аккуратным, если вы знаете что распределение данных не изменится, то хорошо. Чаще всего, в работающем проекте распределение данных более менее постоянно, и указание конкретных индексов надежнее. Даже если у вас давно работающий проект, оптимизатор может иногда удивить, выбрав очень странный план, особенно если сложные индексы с пересекающимися полями.
И еще, USE - это рекомендация, оптимизатор может на нее забить, прям чтоб гарантировано нужен FORCE.

MySQL/MariaDB. 10 vs 11 version. Индексы. Странное поведение?

Я так понимаю работали в 10ке, затем перенесли данные в 11 и сразу попробовали? А статистику собирали после переноса? Если нет, то ничего удивительного, что оптимизатор выбрал неверный план.

Как правильно создать объект класса Request в Workerman?

azuf,

Vitsliputsli, то есть нельзя создать экземпляр Request? Здесь Request используется вне onMessage, правда класс наследуется от исходного. Не знаю важно ли это, плохо разбираюсь в работе конструкций классов и объектов.

Можно, но объекты не в вакууме существуют, их чтото создает и передает необходимые данные. Какие данные вы будете передавать для создания объекта? А нужно передавать buffer, т.е. сырые данные запроса http.
Пример который вы здесь привели, это оперирование с объектами класса Request, пожалуйста, можете сделать также, но чтото предварительно должно создать объект класса Request.
В Workerman гдето есть код по созданию объекта класса Request, и есть вызов onMessage с передачей туда Request.

Потому что он позволяет использовать PHP как полноценный язык, способный держать постоянный процесс. Что дает много новых возможностей, в отличие от общепринятой CGI модели использования PHP, когда процесс запускается отдельным веб-сервером, а после процесс умирает. И дает еще и увеличение производительности. И потому что он проще чем Swoole.

Демоны на php это такая же общепринятая модель, как и cgi, уже давно. И с ними все тоже самое, кроме некоторых нюансов. Обработка http-запросов демоном на php скорее всего будет менее производительно чем через php-fpm, потому что fpm максимально оптимизирован для такой работы.

У меня нет цели изучать именно ООП. Моя цель разобраться с Workerman. Мне непонятно как изучать ООП. Я вижу класс Request, везде учат, что нужно создавать экземпляр объекта от класса, а тут выясняется, что просто так объект Request не создашь. То есть чтобы понять как работать конкретно с таким классом, нужно сразу углубляться в какие то тонкости, как это сделать непонятно, так как во всех книжках одна и та же общая информация.

Зря, не разберетесь с ООП, дальше не сможете продвигаться.
Так у вас уже создан экземпляр класса, Workerman его создал. Весь смысл ООП, что вам не нужно вникать, что и как там делал Workerman - вам не нужно самому парсить запрос http, у вас есть есть готовый объект Request, с набором функций-методов, для удобного получения различных параметров запроса.