Комментарии 85
habrahabr.ru/post/79377/ — старичек phpDaemon
github.com/kakserpom/phpdaemon — просто как серпом по яи…
github.com/kakserpom/phpdaemon — просто как серпом по яи…
Complete requests: 5000
Failed requests: 4983
Мощь! Или тестировались настолько динамичные страницы, что возвращался каждый раз разный результат?
Complete requests: 5000
Failed requests: 4983
(Connect: 0, Receive: 0, Length: 4983, Exceptions: 0)
На странице, отображается количество запросов в БД и общее время выполнения скрипта, ясно что они будут меняться и вместе с ними размер документа.
Под нагрузкой мои сайты могут отдавать до пяти тысяч ошибок в секунду.
а можете погонять без базы, выводить например «hello world»? интересно насколько php быстр)
Тот же HHVM, пул из 16 процессов с Nginx
HHVM, один процесс без Nginx, то есть напрямую:
Скрытый текст
nazar-pc@nazar-pc ~> ab -n5000 -c256 cscms.org:9990/uk
This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, www.zeustech.net/
Licensed to The Apache Software Foundation, www.apache.org/
Benchmarking cscms.org (be patient)
Completed 500 requests
Completed 1000 requests
Completed 1500 requests
Completed 2000 requests
Completed 2500 requests
Completed 3000 requests
Completed 3500 requests
Completed 4000 requests
Completed 4500 requests
Completed 5000 requests
Finished 5000 requests
Server Software: nginx/1.6.2
Server Hostname: cscms.org
Server Port: 9990
Document Path: /uk
Document Length: 13 bytes
Concurrency Level: 256
Time taken for tests: 0.342 seconds
Complete requests: 5000
Failed requests: 0
Total transferred: 725000 bytes
HTML transferred: 65000 bytes
Requests per second: 14610.53 [#/sec] (mean)
Time per request: 17.522 [ms] (mean)
Time per request: 0.068 [ms] (mean, across all concurrent requests)
Transfer rate: 2068.87 [Kbytes/sec] received
Connection Times (ms)
min mean[±sd] median max
Connect: 0 2 1.4 2 6
Processing: 1 8 5.8 6 210
Waiting: 1 7 5.8 6 209
Total: 1 10 5.8 9 210
Percentage of the requests served within a certain time (ms)
50% 9
66% 11
75% 12
80% 13
90% 15
95% 19
98% 23
99% 24
100% 210 (longest request)
This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, www.zeustech.net/
Licensed to The Apache Software Foundation, www.apache.org/
Benchmarking cscms.org (be patient)
Completed 500 requests
Completed 1000 requests
Completed 1500 requests
Completed 2000 requests
Completed 2500 requests
Completed 3000 requests
Completed 3500 requests
Completed 4000 requests
Completed 4500 requests
Completed 5000 requests
Finished 5000 requests
Server Software: nginx/1.6.2
Server Hostname: cscms.org
Server Port: 9990
Document Path: /uk
Document Length: 13 bytes
Concurrency Level: 256
Time taken for tests: 0.342 seconds
Complete requests: 5000
Failed requests: 0
Total transferred: 725000 bytes
HTML transferred: 65000 bytes
Requests per second: 14610.53 [#/sec] (mean)
Time per request: 17.522 [ms] (mean)
Time per request: 0.068 [ms] (mean, across all concurrent requests)
Transfer rate: 2068.87 [Kbytes/sec] received
Connection Times (ms)
min mean[±sd] median max
Connect: 0 2 1.4 2 6
Processing: 1 8 5.8 6 210
Waiting: 1 7 5.8 6 209
Total: 1 10 5.8 9 210
Percentage of the requests served within a certain time (ms)
50% 9
66% 11
75% 12
80% 13
90% 15
95% 19
98% 23
99% 24
100% 210 (longest request)
HHVM, один процесс без Nginx, то есть напрямую:
Скрытый текст
nazar-pc@nazar-pc ~> ab -n5000 -c256 cscms.org:9998/uk
This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, www.zeustech.net/
Licensed to The Apache Software Foundation, www.apache.org/
Benchmarking cscms.org (be patient)
Completed 500 requests
Completed 1000 requests
Completed 1500 requests
Completed 2000 requests
Completed 2500 requests
Completed 3000 requests
Completed 3500 requests
Completed 4000 requests
Completed 4500 requests
Completed 5000 requests
Finished 5000 requests
Server Software:
Server Hostname: cscms.org
Server Port: 9998
Document Path: /uk
Document Length: 23 bytes
Concurrency Level: 256
Time taken for tests: 0.522 seconds
Complete requests: 5000
Failed requests: 0
Total transferred: 485000 bytes
HTML transferred: 115000 bytes
Requests per second: 9569.76 [#/sec] (mean)
Time per request: 26.751 [ms] (mean)
Time per request: 0.104 [ms] (mean, across all concurrent requests)
Transfer rate: 906.51 [Kbytes/sec] received
Connection Times (ms)
min mean[±sd] median max
Connect: 0 0 0.7 0 5
Processing: 8 11 6.9 11 404
Waiting: 8 11 6.9 11 404
Total: 10 11 7.0 11 404
Percentage of the requests served within a certain time (ms)
50% 11
66% 11
75% 12
80% 12
90% 13
95% 15
98% 18
99% 18
100% 404 (longest request)
This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, www.zeustech.net/
Licensed to The Apache Software Foundation, www.apache.org/
Benchmarking cscms.org (be patient)
Completed 500 requests
Completed 1000 requests
Completed 1500 requests
Completed 2000 requests
Completed 2500 requests
Completed 3000 requests
Completed 3500 requests
Completed 4000 requests
Completed 4500 requests
Completed 5000 requests
Finished 5000 requests
Server Software:
Server Hostname: cscms.org
Server Port: 9998
Document Path: /uk
Document Length: 23 bytes
Concurrency Level: 256
Time taken for tests: 0.522 seconds
Complete requests: 5000
Failed requests: 0
Total transferred: 485000 bytes
HTML transferred: 115000 bytes
Requests per second: 9569.76 [#/sec] (mean)
Time per request: 26.751 [ms] (mean)
Time per request: 0.104 [ms] (mean, across all concurrent requests)
Transfer rate: 906.51 [Kbytes/sec] received
Connection Times (ms)
min mean[±sd] median max
Connect: 0 0 0.7 0 5
Processing: 8 11 6.9 11 404
Waiting: 8 11 6.9 11 404
Total: 10 11 7.0 11 404
Percentage of the requests served within a certain time (ms)
50% 11
66% 11
75% 12
80% 12
90% 13
95% 15
98% 18
99% 18
100% 404 (longest request)
С завидной периодичностью появляются статьи про, что «ПХП не так уж плох» и «ПХП можно ускорить». Если бы все было так хорошо как пишут — такие статьи бы не появлялись. Короче: «Не верю!».
Есть фундаментальные органичения ПХП, которые обусловлены его устройством. Чудес не бывает. Его можно ускорить в 4 и даже в 10 раз, но относительно его «производительности», этого будет недостаточно — нужны порядки.
Есть фундаментальные органичения ПХП, которые обусловлены его устройством. Чудес не бывает. Его можно ускорить в 4 и даже в 10 раз, но относительно его «производительности», этого будет недостаточно — нужны порядки.
Статьи появляются чтобы развеять стереотипы, зря вы не верите.
Устройство PHP в случае HHVM достаточно хорошее, компилируя тяжелые участки кода в машинный код вы не сильно уж сможете ускорить по сравнению с тем же Python, Ruby или NodeJS, просто некуда быстрее, у меня даже есть подозрение, что PHP окажется быстрее всех упомянутых. Конечно, можно написать на С, но это уже совсем другая история с другой областью применения.
Фундаментально PHP может работать с сокетами, другое дело что только небольшой процент использует это подобным образом. Не привыкли потому что. На Тостере всё ещё советуют ставить Apache2 и Nginx перед ним, просто потому что привыкли, хотя практического смысла в этом нет.
В статье описывается ситуация, когда фактически ничего не изменилось — мы просто перестали поднимать интерпретатор каждый раз и создавать системные часто используемые объекты (HHVM в FastCGI тоже оптимизирует кое-что, но не так существенно), а если начать использовать асинхронную работу с БД, файловой системой и различным внешними сервисами — поднять на порядки реально, зависит от контекста.
Устройство PHP в случае HHVM достаточно хорошее, компилируя тяжелые участки кода в машинный код вы не сильно уж сможете ускорить по сравнению с тем же Python, Ruby или NodeJS, просто некуда быстрее, у меня даже есть подозрение, что PHP окажется быстрее всех упомянутых. Конечно, можно написать на С, но это уже совсем другая история с другой областью применения.
Фундаментально PHP может работать с сокетами, другое дело что только небольшой процент использует это подобным образом. Не привыкли потому что. На Тостере всё ещё советуют ставить Apache2 и Nginx перед ним, просто потому что привыкли, хотя практического смысла в этом нет.
В статье описывается ситуация, когда фактически ничего не изменилось — мы просто перестали поднимать интерпретатор каждый раз и создавать системные часто используемые объекты (HHVM в FastCGI тоже оптимизирует кое-что, но не так существенно), а если начать использовать асинхронную работу с БД, файловой системой и различным внешними сервисами — поднять на порядки реально, зависит от контекста.
Статьи появляются чтобы развеять стереотипы, зря вы не верите.
Ожидаю еще ряд минусов, но справедливость требует написать еще один ответ.
Я отдал этому монстру несколько лет своей жизни. Я очень верил в этот язык, но чем больше я про него узнавал, тем меньше он мне нравился. В итоге это выродилось в лютую ненавист к этому языку (да — я признаю, что я эмоционален, когда речь идет о PHP).
Я прошел путь через разные оптимизаторы (которые ингода кстати глючат), узнал что перед ПХП нужно ставить реверс прокси, чтобы выхлоп не блокировал работу скрипта, ставил мемкешд, чтобы ликвидировать «узкое место при обращении к БД». Узнал что ПХП не умеет работать с FCGI так как это задумано. То есть там нельзя было создать цикл обработки (возможно сейчас это уже не так). Мы пробывали клеить автоматом файлы в один, чтобы получить прирость производительности. И еще кучу-кучу всяких мелочей, которые давали надежду получить еще немного прироста. В итоге мы получили сотни процентов прироста. А каков итог? Этого мало.
К сравнению выснилось, что сервер на С++, способен обработать запрос, сделать полезные вычисления и отправить ответ пользователю за то время, пока! пустой! скрипт на ПХП даже не успеет загрузиться.
Стереотипы? Да — я работал с ПХП давно, но у меня есть сильные опасения, что принципиально с того момента мало что изменилось. Многие разработчики прокляли тот момент, когда решили писать на ПХП, потому что менкеджер всех убедил, что «ну фейсбук и вк же написаны на ПХП», даже не подозревая как сильно тот ПХП, который они использовали отличался от того ПХП на которм они собирались писать и не понимая через какое количество «боли и унижения» пришлось пройти этим людям.
Скажу честно — для меня пост о том, что «ПХП не такой уж медленный» — это пост про то, что «БигМак не такой уже и вредный».
Я очень верил в этот язык
Никогда этого не понимал. Понимаю привычку, но слепую веру — это глупо. Язык лишь инструмент, и для каждой задачи он свой.
которые ингода кстати глючат
видать вы давно трогали PHP. Вообще можете уточнить когда и с чем вы работали? У меня создается впечатление что это было лет так 5-6 назад и работали в с битрикс или cake/codeigniter.
перед ПХП нужно ставить реверс прокси
Я бы и перед реализацией на Rust/Go/C++ его ставил что бы не гонять постоянно CPU.
ставил мемкешд, чтобы ликвидировать «узкое место при обращении к БД»
Аналогично, тут проблема не в медлительности PHP а в I/O. То есть не важно что вы будете делать, обращение к кэшу в памяти на порядки быстрее запросов в память. То есть это проблема архитектуры приложения а не языка.
Узнал что ПХП не умеет работать с FCGI так как это задумано.
Статья как раз об этом, если что. Уже были попытки сделать из PHP тру fcgi но как-то это не популярная парадигма. В том виде в котором большинство используют PHP — меньше проблем и дешевле. А все то что приводится в статье необходимо только при больших нагрузках и опять же проблем с этим нет. Единственное что это на порядок усложняет архитекруру приложения, нужно организовывать пул подключений к базе, выносить этот пул в отдельные процессы/потоки и т.д. Можно конечно воспользоваться возможностями mysqli (там есть API для асинхронной работы с базой) но опять же есть свои оговорки.
Мы пробывали клеить автоматом файлы в один, чтобы получить прирость производительности.
Походу это было еще до APC/OpCache…
Сейчас все на самом деле изменилось. У вас есть возможность поднять на ReactPHP очень быстрый API с прединициализацией. Есть opcache который можно настроить на прогрев при деплое, и тогда при выполнении скриптов вообще не будет происходить обращения к файловой системе, парсинга и компиляции в опкоды. А это дает просто колосальный прирост. В PHP7 полностью (со времен 5.4) переписали ядро и основные структуры, снизив потребление памяти и подняв производительность еще больше. Есть эксперементы с JIT. Есть HHVM на котором крутится фэйсбук (опять же, там не PHP, там Hack, у которого есть статический тайп хинтинг и много чего еще).
Словом… лучше уж пусть школьники пишут на PHP который будет умирать. Индустрии нужны люди которые пилят бложики. Но говорить о том что на PHP ничего серьезного не сделать тоже глупо. Просто придется расширить стэк технологий в последствии. Реализовать узкие места на go к примеру, распределить приложение по разным серверам… зато бюджет проекта от этого не будет раздуваться на порядки.
Никогда этого не понимал. Понимаю привычку, но слепую веру — это глупо.
Для того, чтобы узнать язык, на нем нужно какое-то время писать. Судя по всему у вас переход из состяния «не знаю/знаю» произошел дискретно в момент, когда вы впервые увидели ПХП. Снимаю перед вами шляпу — я таких людей в своей жизни встречаю впервые.
видать вы давно трогали PHP. Вообще можете уточнить когда и с чем вы работали? У меня создается впечатление что это было лет так 5-6 назад
Абсолютно верно — я об этом написал. Это было давно. Те тенденции, которые я видел тогда (а так же исходная точка), позволяли сделать вывод, что принципиально ничего не изменится. Судя по всему так и есть, т.к. разговор в конечно счете снова про «разы», а не про «порядки». Ну а далее «интерпритатор, типизация, чудес не бывает» и всякое бла-бла-бла в этом роде. Не буду повторятся.
Я бы и перед реализацией на Rust/Go/C++ его ставил что бы не гонять постоянно CPU.
А я бы не стал, т.к. в Go вообще все операции асинхронные, а в C++ «нормальные пацаны» пишут все асинхрон.
Уже были попытки сделать из PHP тру fcgi но как-то это не популярная парадигма
Вы понимаете, когда люди придумали FCGI — это был не «прикол так». В этом был глубинный смысл: переход от CGI к FCGI. И сделано это было еще до ПХП. Я очень рад, если в ПХП наконец сделали возможность настоящего FCGI, т.к. плюсы от прогретого окружения могут перекрыть все остальные попытки «ускорения».
Походу это было еще до APC/OpCache…
Это было очень-очень давно.
К слову, приход в Фейсбук Александреску ничего для «этих ваших ПХП» хорошего не сулит. С учетом того, что весомый вклад в ПХП сделал именно ФБ, стоило бы задуматься.
Судя по всему у вас переход из состяния «не знаю/знаю» произошел дискретно в момент, когда вы впервые увидели ПХП.
Немного не понял о чем вы… Я когда начал писать на PHP еще даже и не думал идти в WEB и в принципе в программирование. У меня тогда просто были какие-то задачи которые я хотел как-то автоматизировать. А там уж как-то так сложилось.
разговор в конечно счете снова про «разы», а не про «порядки»
Среднестатистический разработчик убьет любую программу кривым запросов в базу. И тут нет разницы отрабатыват логика за 1 милисекунду или за 100, если запрос отрабатывает секунду (кривые джойны, нет индексов и т.д.). Производительности PHP более чем хватает, и опять же все узкие места связанные с вычислениями и алгоритмами стоит писать на другом языке (на худой конец на том же Си, с возможностью использовать всю мощь SSE/AVX… а скоро и FPGA впилят если уже не впилили). Чего-то можно добиться на JIT, если будет доступна информация о типах. Один из кор контибьюторов даже предложил что если эта RFC пройдет то он реализует компилятор PHP в нативный код (по сути компиляция опкодов в нэйтив и кеширование этого).
К слову, приход в Фейсбук Александреску
Насколько я помню Александреску делает там только ресерчи и пилит тулзы для девелопмента. Из того что там есть на D в данный момент (насколько мне известно, моя информация могла устареть уже прилично) — средства для статического анализа и препроцессоры для C++. Мне D как язык очень нравится, но развивается он в сравнении с теми же Go или Rust значительно медленнее.
Говоря про «разы порядки» я имел ввиду, что ПХП очень медленный.
Если я на C++ ускорю обработку запросов на 20% — то это будет «Вау! Круто!». Потому, что речь может идти про тысячи запросов.
Если вы ускорите ПХП на 400%, то вам скажут «ммм… окей. А еще можно что-то ускорить? Было бы неплохо...». Но можно конечно и серверов навалить. Подход про «железо дешевле» я тоже слышал.
Или вы правда считаете, что магическим образом качественный переходу уже произошел? Давайте только говорить честно.
Плохой тормозной код можно написать на любом языке. Алгоритм O(n^2) отработает при больших n на C медленнее, чем O(n) для PHP — этого я оспраивать не будут. Но если мы возьмем код на С++, написанный алгоритмически вменяемым человеком, то даже если этот код не точили напильником, то он будет быстрее, чем заточенный до блеска код на PHP.
Поймите мою позицию правильно. Пусть PHP существует, но не стоит говорить о скорости, о том что все на самом деле быстро. Говорите про «низкий порог вхождения», «быстрый старт» и другие подобные плюсы. Если бы PHP был быстр, то нужны бы были статьи, которые «разрушают мифы»? Почему-то не видно статей, которые разрушают мифы о том, что C или C++ тормозной. Это повод задуматься.
Если я на C++ ускорю обработку запросов на 20% — то это будет «Вау! Круто!». Потому, что речь может идти про тысячи запросов.
Если вы ускорите ПХП на 400%, то вам скажут «ммм… окей. А еще можно что-то ускорить? Было бы неплохо...». Но можно конечно и серверов навалить. Подход про «железо дешевле» я тоже слышал.
Или вы правда считаете, что магическим образом качественный переходу уже произошел? Давайте только говорить честно.
Плохой тормозной код можно написать на любом языке. Алгоритм O(n^2) отработает при больших n на C медленнее, чем O(n) для PHP — этого я оспраивать не будут. Но если мы возьмем код на С++, написанный алгоритмически вменяемым человеком, то даже если этот код не точили напильником, то он будет быстрее, чем заточенный до блеска код на PHP.
Поймите мою позицию правильно. Пусть PHP существует, но не стоит говорить о скорости, о том что все на самом деле быстро. Говорите про «низкий порог вхождения», «быстрый старт» и другие подобные плюсы. Если бы PHP был быстр, то нужны бы были статьи, которые «разрушают мифы»? Почему-то не видно статей, которые разрушают мифы о том, что C или C++ тормозной. Это повод задуматься.
Разве хоть кто-то здесь пытался доказать что сам PHP соизмерим по скорости с C++? Все в курсе что он и много других языков медленнее на порядки, и угадайте что? Мизерное количество сайтов написано на С++, даже высоконагруженные далеко не всегда написаны на нем. А если страничка на PHP генерируется не 100мс, а 10мс, то по моему ничего плохого здесь нет, или что вместо 300rps мы получаем 1000rps, минимально изменяя код, это же здорово, разве нет?
Все в курсе что он и много других языков медленнее на порядки, и угадайте что? Мизерное количество сайтов написано на С++, даже высоконагруженные далеко не всегда написаны на нем.
Сомо собой разумеется. Я не спорю, что «порог входа» для С++ сильно выше, чем для PHP. Я так же не спорю с тем, что «стартануть» на PHP быстрее, причем намного. За все нужно платить. Вопрос лишь в осознании этой платы.
А если страничка на PHP генерируется не 100мс, а 10мс, то по моему ничего плохого здесь нет, или что вместо 300rps мы получаем 1000rps, минимально изменяя код, это же здорово, разве нет?
1000rps — это какая-то синтетика и вам это точно известно. Это изумительно, но это синтетика — это не рабочий проект. Я читал такие же статьи много лет назад. Совершенно фантастические приросты производительности. А толку? Для меня отправной точкой для того, чтобы закончить работу с ПХП, было понимание о наличие потолка производительности, который очень низок и который не пробить никакми оптимизаторами. Я говорю не про алгоритимческую сложность, а про сложность единицы. Для того, чтобы «внезапно» не получить даже 300rps вовсе не обязательно решать задачи на графы. Есть PHP, который медленнее C++ на порядки, а есть Go (компиляция+типизация), который медленнее только в разы. И вот учитывая скорость старта и порог вхождений, говорить про разы на мой взгляд разумно, а говорить про порядки — нет.
Если ваш проект эти проценты спасают, то это здорово. А вот некоторые люди могут стукнутся в непробиваемый потолок в тот самый момент, когда сил уже вложено необратимо много. То что вы в этот потолок еще не стукнулись — это либо ваше счастье, либо ваше горе. Смотря по сопутсвующим обстоятельствам. Однажды можно храбро бросится в новый переспективный проект и узнать про этот самый потолок много нового и интересного. Вот такой вот мой «очень дорогой» опыт. Незнаю много ли таких людей, но они есть. И для нас — это не «мифы» — это «факты».
Для кого вы писали статью? Для тех кто с радостью пишет на PHP? Судя по вступлению — нет. Вы хотели переубедить тех кто считает, что «PHP умирает». Вот он я — вот мои аргументы. Обвините меня в том, что я про ПХП ничего не знаю и что мои обвинения голословны. Вы можите? В ответ я получу еще несколько минусов, потому, что статья написана не для меня, а для тех кто «в клубе любителей». Тогда начните статью словами «Сегодня я расскажу вам пару трюков о том, как сделать PHP еще быстрее...».
Зря я сюда влез — вы уж простите. Но не могу я без боли смотреть на статьи про «производительность» PHP. Рука тянется к клавиатуре. Наверное единственный аспект, где я сдержаться не могу.
Если ваш проект эти проценты спасают, то это здорово. А вот некоторые люди могут стукнутся в непробиваемый потолок в тот самый момент, когда сил уже вложено необратимо много. То что вы в этот потолок еще не стукнулись — это либо ваше счастье, либо ваше горе. Смотря по сопутсвующим обстоятельствам. Однажды можно храбро бросится в новый переспективный проект и узнать про этот самый потолок много нового и интересного. Вот такой вот мой «очень дорогой» опыт. Незнаю много ли таких людей, но они есть. И для нас — это не «мифы» — это «факты».
Вы постоянно пишете, что кто-то стучится в какой-то потолок и плачет, но, как показывает история, к моменту стука об этот потолок (а это оооочень далекий путь на самом деле) уже не важно на чем вы там писали этот код. Или вам нужны примеры?
>Но не могу я без боли смотреть на статьи про «производительность» PHP
Конечно, вы правы, что C++ на порядок круче PHP в плане производительности. С этим вообще никто не спорит. Но реальность такова, что на свете есть много людей, которые по разным причинам используют PHP, и для них вопрос повышения производительности может быть актуален. Зря вы так критикуете статью, в ней нет ничего плохого.
Конечно, вы правы, что C++ на порядок круче PHP в плане производительности. С этим вообще никто не спорит. Но реальность такова, что на свете есть много людей, которые по разным причинам используют PHP, и для них вопрос повышения производительности может быть актуален. Зря вы так критикуете статью, в ней нет ничего плохого.
что ПХП очень медленный.
Да не очень то он и медленный. В 90% web приложений узким местом всегда будет база данных или работа с I/O. Более того, большая часть web разработчиков в принципе не в состоянии спроектировать архитектуру приложения таким образом что бы минимизировать простои и т.д. И хоть решения на C++ и будут давать вам выйгрыш в производительности в один порядок, но скорее всего и обойдется вам так же на порядок дороже. Этот спор (лучше то что быстрее) вообще пустой. Помимо этого есть еще скорость разработки, простота деплоймента и масштабирования… кучи параметров. И тут PHP пока выигрывает. Как минимум потому что можно нанять 2-3 разработчиков за $2К и они поднимут чуваку его стартапчик за N времени, и затем еще N времени будут его допиливать что бы нагрузки выдерживал. Можно конечно же сразу нанять 2-3-х разработчиков за $4К+ которые напишут все круто и на C++ и за 1.5N-2N, и после чего сервис сможет выдержать огромные нагрузки… нооо расходов будет больше в два раза, и отбиваться эти расходы так же будут позже…
Словом… давайте закроем спор. PHP медленнее C++, но вам никто не мешает писать на C++ узкие места (есть еще зефир, который является эдаким PHP со строгой типизацией и возможностью компилить это добро в экстешнеы для PHP) и радоваться жизни. Вопрос не в инструменте а в том как им пользуются люди.
что до fcgi — сейчас приняли внутри PHP комьюнити стандарт, регламентирующий интерфейсы для взаимодейтвия с HTTP — так что можно будет сделать основу для этого добра.
Да не очень то он и медленный.
По вашей ссылке от 3 до 131 раза медленнее.
А «очень» медленный это во сколько раз?
Как по мне «не очень» — это Go:
benchmarksgame.alioth.debian.org/u64/compare.php?lang=go&lang2=gpp
Или JavaScript:
benchmarksgame.alioth.debian.org/u64/compare.php?lang=v8&lang2=gpp
И часто вы на PHP пишете операции над последовательностью ДНК или множество мандельброта рисуете?
Кстати у Rust цифры ещё лучше, может быть всем пересесть на него?
Кстати у Rust цифры ещё лучше, может быть всем пересесть на него?
кстати, о том же множестве Мандельброта на php уже говорили сегодня в дайджесте PHP, процитирую:
Представлена экспериментальная реализация JIT для PHP от Zend — Один из главных авторов PHPNG, Дмитрий Стогов, анонсировал реализацию JIT. На некоторых синтетических тестах заметен значительный рост производительности, а для специфичных случаев, например, подсчет множества Мандельброта, показывает 30 кратный рост и опережает реализацию на C.
Представлена экспериментальная реализация JIT для PHP от Zend — Один из главных авторов PHPNG, Дмитрий Стогов, анонсировал реализацию JIT. На некоторых синтетических тестах заметен значительный рост производительности, а для специфичных случаев, например, подсчет множества Мандельброта, показывает 30 кратный рост и опережает реализацию на C.
А какова версия PHP была в описываемое время? Любопытно очень.
Я боюсь ошибиться, но судя по датам это была версия 5 или выше, т.к. там уже были области видимости внутри класса.
Кстати вот интересный вопрос: разработчики PHP все еще считают, что «закрытый член класса» — это такой член, «о котором снаружи никто не знает» или они уже пришли к заключению о том, что это член класса, «к которому нельзя снаружи обратиться»?
Кстати вот интересный вопрос: разработчики PHP все еще считают, что «закрытый член класса» — это такой член, «о котором снаружи никто не знает» или они уже пришли к заключению о том, что это член класса, «к которому нельзя снаружи обратиться»?
PHP Fatal error: Cannot access private property Foo::$bar in /home/zTq6k1/prog.php on line 8
ideone.com/lWkkGJ
если я правильно вас понял. С инкапсуляцией у PHP все ок. И судя по всему вы застали переход от PHP4 к PHP5 и все.
Судя по всему ничего не поменялось таки.
Модифицирую ваш пример.
Модифицирую ваш пример.
class Foo {
private $bar = 'bar';
public $foo = 'foo';
}
class Bar extends Foo {}
$f = new Bar();
echo("Bar: ");
var_dump($f->foo);
var_dump($f->bar);
$f = new Foo();
echo("Foo: ");
var_dump($f->foo);
var_dump($f->bar);
А как по вашему, как должно работать? Приватное свойство никак не влияет на цепочку наследников. Оно есть в классе Foo, в классе Bar его нет и интерпритатор воспринимает его как неявное публичное свойство. Все работает так же, как если бы вы в Bar объявили публичное свойство $bar. То есть поведение приведенное вами соответствует такому коду:
Инкапсуляции от этого хуже не делается, наоборот, никто ничего не знает о реализации базовых классов. Совсем ничего. PHP вам кинет нотис о том что вы обратились к несуществующему свойству и все.
class Foo {
private $bar = 'bar';
}
class Bar extends Foo {
public $bar;
}
Инкапсуляции от этого хуже не делается, наоборот, никто ничего не знает о реализации базовых классов. Совсем ничего. PHP вам кинет нотис о том что вы обратились к несуществующему свойству и все.
Фактически это означает, что изменение области видимости влияет на логику работы кода.
Попробуйте вопроизвести подобный пример в Java или C++.
Попробуйте вопроизвести подобный пример в Java или C++.
конечно, изменение области видимости должно влиять на логику кода. Иначе бы не было различных областей видимости.
С каких пор C++ эталонный пример реализации инкапсуляции?
Что до Java — там все так же: ideone.com/soDELi
Что до Java — там все так же: ideone.com/soDELi
Проверьте пример — кажется там не то.
ideone.com/D9V4Rx
ideone.com/D9V4Rx
Там именно то. Когда в PHP вы обращаетесь к объекту у которого нет такого свойства, выкидывается предупреждение и создается публичное свойство. Динамически, в рантайме. Это другое свойство, оно никакого отношения не имеет к свойствам родительского класса. Можно написать свой обработчик ошибок который на подобные действия будет кидать исключения, но… суть все та же. Разница в поведении только в этом. Так сложилось исторически и по причинам сохранения обратной совместимости (из-за всяких wordpress) решено видимо было оставить подобное поведение.
Я понимаю как оно написано. Я понимаю как оно работает. Тут для меня нет тайны.
Но мы пришли к тому с чего начали
и что в PHP
Мне кстати более таких языков не известно — наверное я их не очень много знаю.
Но мы пришли к тому с чего начали
разработчики PHP все еще считают, что «закрытый член класса» — это такой член, «о котором снаружи никто не знает»
и что в PHP
изменение области видимости влияет на логику работы кода.
Мне кстати более таких языков не известно — наверное я их не очень много знаю.
разработчики PHP все еще считают, что «закрытый член класса» — это такой член, «о котором снаружи никто не знает»
Закрытый член класса тот, к которому нельзя обратиться. Просто в PHP есть такая фишка как автосоздание проперти при обращении.
изменение области видимости влияет на логику работы кода.
Вы видимо не работали с Python хотя бы… А уж как у вас начнет бомбить когда вы хотя бы годик на JS плотно попишите…
Специально для вас:
Bar: string(3) «foo»
PHP Notice: Undefined property: Bar::$bar on line 11
Notice: Undefined property: Bar::$bar on line 11
NULL
Foo: string(3) «foo»
PHP Fatal error: Cannot access private property Foo::$bar on line 15
Fatal error: Cannot access private property Foo::$bar on line 15
Bar: string(3) «foo»
PHP Notice: Undefined property: Bar::$bar on line 11
Notice: Undefined property: Bar::$bar on line 11
NULL
Foo: string(3) «foo»
PHP Fatal error: Cannot access private property Foo::$bar on line 15
Fatal error: Cannot access private property Foo::$bar on line 15
Да, а должно быть оба раза Cannot access. По «хорошему».
С какой стати? Это же private, а не protected.
Потому, что область видимости означает, что «к члену класса нельзя обратиться», а не то, что «этого поля никто не должен видеть». Такая реализация приводит к изменения логики работы программы при изменениии области видимости. Это не в какой ООП простите не лезет.
Можете меня просветить, в таком случае, какие принципы ООП нарушает скрытие приватных свойств, а не запрет доступа к ним? Буду благодарен за ссылки на источники, которые позволят мне вырасти в этом понимании.
Вы не вполне понимаете. От того, что произошло наследование, поле «foo» не стало «более private». Оно было унаследованно и осталось private. Как и было. ничего не поменялось. Точнее «ничего не должно было поменяться». Однако поменялось. Мембер только что «был, но к нему нельзя было обратиться», а теперь «исчез».
Как вы думаете: «наступал» я на это ли нет, раз пишу об этом?
Как вы думаете: «наступал» я на это ли нет, раз пишу об этом?
Используйте protected и никуда он не исчезнет, либо я чего-то тоже не догоняю?
Если вы определили его как private он доступен только внутри класса, где определён.
Если объявить как protected — можно будет получить доступ и далее при наследовании.
Если вы определили его как private он доступен только внутри класса, где определён.
Если объявить как protected — можно будет получить доступ и далее при наследовании.
Речь про то что видно снаружи.
В пример в классе Foo его видно, но он не доступен.
А в классе Bar его уже не видно снаружи.
В частности это имеет значение при использование рефлексии. При изменении области видимости вы можите получить разные результаты (хотя это могло поменяться, но с учетом описанного выше, думаю что нет).
В пример в классе Foo его видно, но он не доступен.
А в классе Bar его уже не видно снаружи.
В частности это имеет значение при использование рефлексии. При изменении области видимости вы можите получить разные результаты (хотя это могло поменяться, но с учетом описанного выше, думаю что нет).
да нет, в наследуемом классе оно уже не private, иначе к нему он тоже мог бы обратиться.
Если вы про потенциальные ошибки (когда я забыл, что поле private и пытаюсь его использовать в наследнике, но программа не завершается принудительно при таком кощунстве) — может быть некоторый осадок.
Но если забыть об костылях, пытающихся защитить программиста, то принцип “черного ящика” говорит мне, что сокрытие данных должно их именно скрывать вообще, код “снаружи” области видимости не должен иметь никаких знаний о коде “внутри”.
Т.е., более логичным было бы как раз в обоих случаях говорить о «Undefined property”. Но это привело бы, к сожалению, к большему числу ошибок, т.к. программисты часто игнорируют предупреждения, а реагируют только на ошибки.
Если вы про потенциальные ошибки (когда я забыл, что поле private и пытаюсь его использовать в наследнике, но программа не завершается принудительно при таком кощунстве) — может быть некоторый осадок.
Но если забыть об костылях, пытающихся защитить программиста, то принцип “черного ящика” говорит мне, что сокрытие данных должно их именно скрывать вообще, код “снаружи” области видимости не должен иметь никаких знаний о коде “внутри”.
Т.е., более логичным было бы как раз в обоих случаях говорить о «Undefined property”. Но это привело бы, к сожалению, к большему числу ошибок, т.к. программисты часто игнорируют предупреждения, а реагируют только на ошибки.
да нет, в наследуемом классе оно уже не private, иначе к нему он тоже мог бы обратиться.
Хорошо — я выразился не вполне верно. С точки зрения пользователя (а пример рассматривается с точки зрения пользователя) ничего не поменялось. Он как не мог обратиться к этому полю — так и не может. Поле не исчезло. Проведите подобный эксперимент в других языках.
Как вы правильно заметили — правильно было бы иметь одинаковое поведение.
Не должно, потому что private property не наследуется. Так же и в c++.
В С++ нет «property» — там есть «member». Но сути это не меняет. Перепишите данный пример на С++.
По древу наследования спускаемся вниз, находим приватное свойство — фэйлимся. В случае с PHP мы вместо этого «додумываем» публичное свойство у наследника, выкидываем на всякий нотис и живем себе. Вот и все. Причем вам никто не запрещает конвертировать эти нотисы в исключения.
Мы с вами говорим об одном и том же, с той только разницей, что я ставлю знак "-", а вы — знак "+".
Я попробую показать еще один пример: если вы попробуете использовать рефлексии, то
даст вам разные результаты для private и protected, хотя и в том и в другом случае доступа к члену класса нет. Я имею ввиду пример с B extends A.
То есть вы порефакторили класс — только изменили область видимости и изменили логику работы программы. В C++ или Java я могу быть точно уверен, что логика работы от замены private на protected или наоборот не изменится. Мой код может не скомпилироваться — это верно, но работать он будет так же.
Я попробую показать еще один пример: если вы попробуете использовать рефлексии, то
$api = new ReflectionClass($f);
foreach($api->getProperties() as $p) {
print $p->getName() . "\n";
}
даст вам разные результаты для private и protected, хотя и в том и в другом случае доступа к члену класса нет. Я имею ввиду пример с B extends A.
То есть вы порефакторили класс — только изменили область видимости и изменили логику работы программы. В C++ или Java я могу быть точно уверен, что логика работы от замены private на protected или наоборот не изменится. Мой код может не скомпилироваться — это верно, но работать он будет так же.
Все правильно, такова особенность PHP — создание свойств на лету. Товарищ dnovikoff предъявляет претензию, что php неправильно интерпретирует модификатор private, но это не правда.
«Модификаторы доступа» — общепринятая концепция, которая ограницичает доступ, а не видимость. То что «создание свойств на лету» (частное свойство языка) является более приоритетным, чем общепринятая концепция — это большая беда и болезнь языка.
В PHP используется термин «Visibility», хотя в большинстве языков используется термин «Access Modifiers». Удивительно, но даже в документации PHP речь идет про «access», хотя в заголовке написано про «visibility». Удивительная подмена понятий: говорим про «видимость», а рассказываем про «доступ».
В документации на php я нашел ровно этот случай с пометкой значения значения как «Undefined». Так что правильно или нет — вопрос вкуса. С точки зрения документации — да. С точки зрения логики и общепринятой практики — это большой вопрос.
Если вы считаете, что раз оно в PHP так, то это правильно, я не имею возможности с вами спорить. Нет логической возможности для оспаривания аксиоматических утверждений. Есть «модификаторы доступа», которые появились задолго до PHP. Есть практика их использования, есть разговор про «доступ», а не про «видимость». Если создадут язык в котом слово «class» означает объявление строки, а слово «public» — выделение места на куче, то сложно будет поспорить с тем, что это особенность языка.
В PHP используется термин «Visibility», хотя в большинстве языков используется термин «Access Modifiers». Удивительно, но даже в документации PHP речь идет про «access», хотя в заголовке написано про «visibility». Удивительная подмена понятий: говорим про «видимость», а рассказываем про «доступ».
В документации на php я нашел ровно этот случай с пометкой значения значения как «Undefined». Так что правильно или нет — вопрос вкуса. С точки зрения документации — да. С точки зрения логики и общепринятой практики — это большой вопрос.
Если вы считаете, что раз оно в PHP так, то это правильно, я не имею возможности с вами спорить. Нет логической возможности для оспаривания аксиоматических утверждений. Есть «модификаторы доступа», которые появились задолго до PHP. Есть практика их использования, есть разговор про «доступ», а не про «видимость». Если создадут язык в котом слово «class» означает объявление строки, а слово «public» — выделение места на куче, то сложно будет поспорить с тем, что это особенность языка.
да, я действительно ошибался, но не так уж и сильно. Родительское private свойство можно переопределить в потомке как public. Иначе получается, такой код не может иметь право на существование (пример на шарпах, но в плюсах поведение такое же):
В php поведение точно такое же, public свойство создается в дочернем классе поверх private свойства в родительском, только в php это происходит на лету, во время исполнения, в то время, как в плюсах это нужно указывать явно.
Свойство класса, к которому нельзя обратиться даже внутри самого класса само по себе бессмысленно, поэтому его наследование так же имеет мало смысла. Но, кстати говоря, то, что в php дочерний класс не наследует private свойства родительского класса не совсем верно. Это можно показать на таком примере:
Результат аналогичного кода идентичен в C#. Родительское свойство есть в дочернем классе, но доступно оно только в методе, унаследованном от родительского класса (все верно, зачем нужно свойство, которое никак нельзя использовать).
Вот и получается, что поведение в php не отличается от поведения в c++. Отличие только в формулировке текста ошибки и в том, что переменные (и свойства класса) в php можно использовать без явного их объявления.
class Foo
{
private int one;
public int two;
public Foo(){}
};
class Bar : Foo
{
public int one;
public Bar(){}
};
В php поведение точно такое же, public свойство создается в дочернем классе поверх private свойства в родительском, только в php это происходит на лету, во время исполнения, в то время, как в плюсах это нужно указывать явно.
Свойство класса, к которому нельзя обратиться даже внутри самого класса само по себе бессмысленно, поэтому его наследование так же имеет мало смысла. Но, кстати говоря, то, что в php дочерний класс не наследует private свойства родительского класса не совсем верно. Это можно показать на таком примере:
<?php
class Foo
{
private $one = 1;
public function getOne()
{
return $this->one;
}
}
class Bar extends Foo
{
public $one = 2;
}
$bar = new Bar();
echo $bar->getOne(); // выведет 1
Результат аналогичного кода идентичен в C#. Родительское свойство есть в дочернем классе, но доступно оно только в методе, унаследованном от родительского класса (все верно, зачем нужно свойство, которое никак нельзя использовать).
Вот и получается, что поведение в php не отличается от поведения в c++. Отличие только в формулировке текста ошибки и в том, что переменные (и свойства класса) в php можно использовать без явного их объявления.
PHP все еще считают, что «закрытый член класса» — это такой член, «о котором снаружи никто не знает» или они уже пришли к заключению о том, что это член класса, «к которому нельзя снаружи обратиться»?Вы с Пайтоном перепутали сейчас.
Хмм…
Я знаю способ писать программы, которые могут работать еще быстрее аналогов, написанных на C++.
Это написание программ на ассемблере!
Но почему-то даже системные программисты не часто выбирают такой подход для написания своих приложений.
Так так ли важна скорость работы программы в контексте выбора ЯП для какой-либо задачи?
Я знаю способ писать программы, которые могут работать еще быстрее аналогов, написанных на C++.
Это написание программ на ассемблере!
Но почему-то даже системные программисты не часто выбирают такой подход для написания своих приложений.
Так так ли важна скорость работы программы в контексте выбора ЯП для какой-либо задачи?
Я знаю способ писать программы, которые могут работать еще быстрее аналогов, написанных на C++.
Оптимизации в современных компиляторах обычно справляются с этой задачей намного лучше большинства людей.
Безусловно, но если речь идет, например, об использовании инструкции процессора, о которой оптимизатор еще не знает.
Думаю, что можно изобрести еще примеры. Опять же ассемблерные вставки в C код не просто так там появляются.
Думаю, что можно изобрести еще примеры. Опять же ассемблерные вставки в C код не просто так там появляются.
Ну вы же понимаете что если брать по соотношению кода, то между PHP и C++ не такая уж сильно большая разница так что это не вполне корректное сравнение. Благо стандарты (x11, x14) последних лет реально упрощают жизнь. Скажем если писать на том же Go — там так же не намного сложнее чем на PHP в плане скорости разработки, просто добавляется оверхэд на компиляцию и откладку. А в целом — очень даже миленько все.
Хорошо, тогда, если мы пропустим диспуты по поводу наличия или отсутствия подходящих библиотек, то в сухом остатке придем к выводу, что выбор ЯП (и соответствующего стека технологий) должен быть обусловлен в большей степени характером решаемой задачи.
В данной статье обсуждается способ расширения возможностей стека PHP по решению специфических задач связанных с веб и длинные обсуждения того, хорош или плох ЯП в данном случае не являются конструктивными.
Своим замечанием я и хотел это продемонстрировать.
В данной статье обсуждается способ расширения возможностей стека PHP по решению специфических задач связанных с веб и длинные обсуждения того, хорош или плох ЯП в данном случае не являются конструктивными.
Своим замечанием я и хотел это продемонстрировать.
А в целом — очень даже миленько все.
Да, это возможно. На мой взгляд для широкого применения Go в массах в нем очень не хватает MVC фреймворка.
MVC фреймворка.
MVC — UI архитектура, для сервера нужны request/response фреймворки. Собственно в PHP мире тоже нет MVC фреймворков, просто почему-то народу очень нравится эта аббревиатура. Ну а шаблонизаторов и ORM для go уже нормально.
MVC — UI архитектура, для сервера нужны request/response фреймворки. Собственно в PHP мире тоже нет MVC фреймворков
То есть веб сайт — не имеет UI я так понимаю?
Имеет, почитайте вот это:
blog.ircmaxell.com/2014/11/a-beginners-guide-to-mvc-for-web.html
blog.ircmaxell.com/2014/11/a-beginners-guide-to-mvc-for-web.html
Тогда, скорее, более интересным является продолжение статьи: blog.ircmaxell.com/2014/11/alternatives-to-mvc.html
В общем, и автор этих статей говорит об этом, существует два понятия: MVC архитектура и MVC фреймворк (автор использует кавычки для MVC). Думаю, что из контекста должно быть понятно какое из понятий используется в конкретном моменте.
В общем, и автор этих статей говорит об этом, существует два понятия: MVC архитектура и MVC фреймворк (автор использует кавычки для MVC). Думаю, что из контекста должно быть понятно какое из понятий используется в конкретном моменте.
Я о том и говорю. «MVC» фреймворки потому и не нужны. А request/response фреймворков для go хватает. Так же как и средств для организации модели, сервисного слоя и слоя представления.
«MVC» фреймворки потому и не нужны
Я имею в виду, что Go не хватает чего-то подобного Rails или Django или Yii как это не назови. Своей популярностью Ruby или Python в среде веб-разработки обязаны по большей части этим фреймворкам.
Для веб-сокетов Go, по всей видимости, неплох. Но разрабатывать на нем какой-нибудь веб портал пока совсем не тянет.
Есть фундаментальные органичения ПХП, которые обусловлены его устройством.
Не посвятите?
PHP и так быстрее Ruby (если заставить его работать по той же модели). Чего вам еще нужно?
Не посвятите?
PHP — это интерпретируемый язык без строгой типизации. Вопросы?
Ясно понятно. И что? В PHP7 по всей видимости будет тайпхинтинг для скаляров, это конечно не то же самое, но на основе этого где-нибудь в 8ой версии или в виде экстеншена уже можно запилить вполне себе эффективный JIT/AOT. Более того, если у вас настолько специфичная задача что производительности PHP не хватает (это реально очень специфичные штуки типа обработка изображений и т.д.) — можно дописать эти узкие места, которые обычно составяют не более 5% функционала, на Си в виде экстеншена.
В целом ваша позиция мне ясна. Вы предлагаете выкинуть все эти детские игрушки типа Python/Ruby/PHP в угоду православных C++/Rust/Go/D/etc… просто так… потому что вам кажется что это не эффективно. И вырезать на корню вообще всю нишу rapid development и т.д.
В целом ваша позиция мне ясна. Вы предлагаете выкинуть все эти детские игрушки типа Python/Ruby/PHP в угоду православных C++/Rust/Go/D/etc… просто так… потому что вам кажется что это не эффективно. И вырезать на корню вообще всю нишу rapid development и т.д.
Расскажите мне про это еще раз, когда «по всей видимости будет» " где-нибудь" — тогда будет смысл говорить. Всегда есть куча крутых идей в проэкте, но:
1) Они не всегда реализуются
2) Не всегда реализуются в том виде
3) Не всегда дают ожидаемый эффект
И «специфичных» задач на ПХП у меня нет. У меня нет никаких задач на ПХП уже очень давно. Я этому несказанно рад.
1) Они не всегда реализуются
2) Не всегда реализуются в том виде
3) Не всегда дают ожидаемый эффект
И «специфичных» задач на ПХП у меня нет. У меня нет никаких задач на ПХП уже очень давно. Я этому несказанно рад.
Расскажите мне про это еще раз, когда «по всей видимости будет» «где-нибудь»в «Хаке» есть.
Скорости работы php уже давно хватает, как вы сами писали в данной ветке — подпирать приходилось сервер и хранилище, а фейсбуку мощностей хватало ещё до всяких придумывания всяких HHVM, хватало даже древнего php4, с тех пор производительность пилят, хотя она уже была ДОСТАТОЧНОЙ, в реальности ускорее получается небольшое, потому что упираемся во всякие сторадж, а не рассчитываем сложные алгоритмы для массивов данных для бигдаты.
Теперь о статье. В традиционном подходе у php не проблема со скоростью, а с тем, что на каждый запрос выделяется отдельный процесс. Соответственно, если ты держишь по вебсокетах 1000 конектов, то у тебя поднимается ОДНОВРЕМЕННО 1000 процессов со скриптом. По сравнению с этим конкурентность 128, после которой падало — это ничто. В такой момент приходят к единому демону, который принимает все запросы и хендлит их по мере надобности. Автор же запустил в таком режиме cms-ку, которая изначально не задумывался для работы в режиме демона, это круто, попутно объяснил как надо и не надо писать, чтобы не было проблем с демонизацией. Современные же php фреймворки с DI и middleware как правило не имеют проблем с демонизацией, пишите на здоровье.
Но все эти асинхронности и статическая типизация десятилетиями валяются на задворках pecl, так как процесс родился-отработал-умер практически идеален для бизнеса и для большинства задач. Потому php-шники В СРЕДНЕМ получают больше, чем сишники, для нашей страны это 2000 против 1700.
Теперь о статье. В традиционном подходе у php не проблема со скоростью, а с тем, что на каждый запрос выделяется отдельный процесс. Соответственно, если ты держишь по вебсокетах 1000 конектов, то у тебя поднимается ОДНОВРЕМЕННО 1000 процессов со скриптом. По сравнению с этим конкурентность 128, после которой падало — это ничто. В такой момент приходят к единому демону, который принимает все запросы и хендлит их по мере надобности. Автор же запустил в таком режиме cms-ку, которая изначально не задумывался для работы в режиме демона, это круто, попутно объяснил как надо и не надо писать, чтобы не было проблем с демонизацией. Современные же php фреймворки с DI и middleware как правило не имеют проблем с демонизацией, пишите на здоровье.
Но все эти асинхронности и статическая типизация десятилетиями валяются на задворках pecl, так как процесс родился-отработал-умер практически идеален для бизнеса и для большинства задач. Потому php-шники В СРЕДНЕМ получают больше, чем сишники, для нашей страны это 2000 против 1700.
Про DI: далеко не во всех реализациях под РНР есть понятие «scope», без которого в таком режиме оно просто не будет адекватно работать, например, абсолютно любой сервис зависящий от «request» должен пересоздаваться при новых запросах, но это поведение не реализовано практически ни в одном из популярных DI-framwork-ов.
Даже в тяжеловесном symfony di-container нет этого функционала из коробки, да там есть «scope», но совсем не для этого.
Тем не менее, прирост такого рода статей за последнее время не может не радовать.
Даже в тяжеловесном symfony di-container нет этого функционала из коробки, да там есть «scope», но совсем не для этого.
Тем не менее, прирост такого рода статей за последнее время не может не радовать.
«was able»
Какой-то негатив тут разгорелся на тему PHP, в отдельных местах. Коллеги, вы чего?
Напрашиваются две мысли, после прочтения комментов:
Также интересно, пришли ли отдельные C++ разработчики таки к заключению, что разные языки хороши для решения разных задач, а иногда разумно использовать стек из разных технологий, что бы построить то или иное решение? Или они все еще считают, что ты пишешь либо на PHP, либо на C++! Точка!
Действительно, ведь крутые C++ программисты напишут бложик на C++, или вообще никогда не столкнуться с такой низкоуровневой задачей/просьбой.
Напрашиваются две мысли, после прочтения комментов:
Кстати вот интересный вопрос: разработчики PHP все еще считают, что «закрытый член класса» — это такой член, «о котором снаружи никто не знает» или они уже пришли к заключению о том, что это член класса, «к которому нельзя снаружи обратиться»?
Также интересно, пришли ли отдельные C++ разработчики таки к заключению, что разные языки хороши для решения разных задач, а иногда разумно использовать стек из разных технологий, что бы построить то или иное решение? Или они все еще считают, что ты пишешь либо на PHP, либо на C++! Точка!
Словом… лучше уж пусть школьники пишут на PHP который будет умирать. Индустрии нужны люди которые пилят бложики.
Действительно, ведь крутые C++ программисты напишут бложик на C++, или вообще никогда не столкнуться с такой низкоуровневой задачей/просьбой.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Атомный реактор в каждый сайт