Атомный реактор в каждый сайт

    Все слышали о том, что PHP создан, чтобы умирать. Так вот, это не совсем правда. Если захотеть — PHP может не умирать, работать асинхронно, и даже поддерживает честную многопоточность. Но не всё сразу, в этот раз поговорим о том, как сделать чтобы он жил долго, и поможет нам в этом атомный реактор!



    Атомный реактор — это проект ReactPHP, в описании указано «Nuclear Reactor written in PHP». На знакомство с ним меня подтолкнула вот эта статья (картинка выше оттуда). Я перечитывал её несколько раз на протяжении года, но никак не получалось добраться до имплементации на практике, хотя рост производительности более чем на порядок в перспективе очень радовал.

    Исходное состояние


    В качестве подопытной системы выступает CleverStyle CMS, движок кэшировния APCu, версия в разработке, то есть установлены все возможные компоненты, в тестах открывается страница модуля Static pages.
    В качестве тестовой железки выступает рабочий ноутбук с Core i7 4900MQ (4 ядра, 8 потоков), ОС Ubuntu 15.04 x64, дисковая подсистема состоит из двух SATA3 SSD в RAID0 (soft, btrfs, пока не лучший вариант для БД, оказалось достаточно узким местом в тестах, но есть что есть), перед каждым тестом запускается sudo sync, при каждом запросе производится 2-4 запроса в БД (создание сессии посетителя, не кэшируются на уровне БД), у Nginx 16 воркеров.
    Условия не лабораторные, но с чем-то нужно работать)
    Тестировать производительность будем простым Apache Benchmark.

    Сначала PHP-FPM (PHP 5.5, 16 воркеров, статически):
    Скрытый текст
    nazar-pc@nazar-pc ~> ab -n5000 -c128 cscms.org:8080/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: 8080

    Document Path: /uk
    Document Length: 99320 bytes

    Concurrency Level: 128
    Time taken for tests: 22.280 seconds
    Complete requests: 5000
    Failed requests: 4239
    (Connect: 0, Receive: 0, Length: 4239, Exceptions: 0)
    Total transferred: 498328949 bytes
    HTML transferred: 496603949 bytes
    Requests per second: 224.41 [#/sec] (mean)
    Time per request: 570.373 [ms] (mean)
    Time per request: 4.456 [ms] (mean, across all concurrent requests)
    Transfer rate: 21842.25 [Kbytes/sec] received

    Connection Times (ms)
    min mean[±sd] median max
    Connect: 0 0 0.5 0 3
    Processing: 26 563 101.6 541 880
    Waiting: 24 559 101.3 537 872
    Total: 30 564 101.4 541 881

    Percentage of the requests served within a certain time (ms)
    50% 541
    66% 559
    75% 572
    80% 584
    90% 759
    95% 795
    98% 817
    99% 829
    100% 881 (longest request)

    Конкурентность 128, поскольку при 256 PHP-FPM просто падает.

    Теперь HHVM, для начала прогреем HHVM с помощью 50 000 запросов (почему), потом выполним тест:
    Скрытый текст
    nazar-pc@nazar-pc ~> ab -n5000 -c256 cscms.org:8000/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: 8000

    Document Path: /uk
    Document Length: 99309 bytes

    Concurrency Level: 256
    Time taken for tests: 20.418 seconds
    Complete requests: 5000
    Failed requests: 962
    (Connect: 0, Receive: 0, Length: 962, Exceptions: 0)
    Total transferred: 498398875 bytes
    HTML transferred: 496543875 bytes
    Requests per second: 244.88 [#/sec] (mean)
    Time per request: 1045.408 [ms] (mean)
    Time per request: 4.084 [ms] (mean, across all concurrent requests)
    Transfer rate: 23837.54 [Kbytes/sec] received

    Connection Times (ms)
    min mean[±sd] median max
    Connect: 0 0 1.5 0 8
    Processing: 505 1019 102.6 1040 1582
    Waiting: 505 1017 102.9 1039 1579
    Total: 513 1019 102.5 1040 1586

    Percentage of the requests served within a certain time (ms)
    50% 1040
    66% 1068
    75% 1080
    80% 1087
    90% 1108
    95% 1126
    98% 1179
    99% 1397
    100% 1586 (longest request)

    Получили 245 запросов в секунду, с этим и будем работать.

    Первые шаги


    Хочется чтобы код не зависел от того, запускается ли он из-под HTTP сервера написанного на PHP, или в более привычном режиме.
    Для этого были утилизированы headers_list()/header_remove() и http_response_code(), суперглобальные $_GET, $_POST, $_REQUEST, $_COOKIE, $_SERVER наполнялись вручную.
    Системные классы разрушались после каждого запроса и создавались при новом.
    В целом работало, но были нюансы:
    • В случае использования асинхонных операций где больше одного запроса будут выполняться одновременно всё накроется медным тазом
    • Создание всех ситемных объектов всё ещё создавало существенные накладные расходы, хотя это и работало быстрее чем полный перезапуск скрипта
    • Не запускалось из-под PHP-CLI, для отправки заголовков нужен PHP-CGI, у которого течет память (по неведомой причине) при долгоиграющем процессе
    • Если кто-то решил вызвать exit()/die() — всё умирает

    Оптимизации, поддержка асинхронности


    Во-первых системные объекты были разделены на две группы — первая, запросы которые зависят от пользователя и конкретного запроса, вторая — полностью независимые.
    Независимые объекты перестали разрушаться после каждого запроса что дало существенный прирост скорости.
    Объект, который принимает запрос от ReactPHP и формирует ответ получил дополнительное поле __request_id. При получении системного объекта, который зависит от конкретного запроса с помощью debug_backtrace() достается этот __request_id, что позволяет разделить эти объекты для каждого отдельного запроса даже при асинхронности.
    Так же были выделены отдельно системные функции, которые работают с глобальным состоянием, для HTTP сервера подключались модифицированные их версии, которые учитывают __request_id. Были добавлены функции _header() вместо header() (для работы заголовков под PHP-CLI), _http_response_code() вместо http_response_code(), уже существующие _getcookie() и _setcookie() были модифицированы, последняя под капотом вручную формирует заголовки для изменения cookie и отправляет их в _header().
    Суперглобальные переменные заменяются массиво-подобными объектами, и при доступе к элементам такого странного массива мы получим данные, соответствующие конкретному запросу — тут совместимость с обычным кодом высока, главное не перезаписывать суперглобальные переменные, и иметь ввиду что там может быть не совсем массив (например, если использовать с array_merge()).
    В качестве ещё одного компромиссного решения в систему был добавлен \ExitException, которым заменяются вызовы exit()/die() (в том числе модифицируются сторонние библиотеки при надобности, кроме ситуаций когда реально нужно завершение всего скрипта), это позволяет перехватить выход на самом верху, и избежать завершения выполнения скрипта.

    Тестируем результат на пуле из 16 запущенных Http серверов (интерпретатор HHVM), Nginx балансирует запросы (прогрев 50 000 запросов на пул):
    Скрытый текст
    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: 99323 bytes

    Concurrency Level: 256
    Time taken for tests: 16.092 seconds
    Complete requests: 5000
    Failed requests: 1646
    (Connect: 0, Receive: 0, Length: 1646, Exceptions: 0)
    Total transferred: 498418546 bytes
    HTML transferred: 496643546 bytes
    Requests per second: 310.71 [#/sec] (mean)
    Time per request: 823.928 [ms] (mean)
    Time per request: 3.218 [ms] (mean, across all concurrent requests)
    Transfer rate: 30246.49 [Kbytes/sec] received

    Connection Times (ms)
    min mean[±sd] median max
    Connect: 0 0 0.9 0 6
    Processing: 100 804 308.3 750 2287
    Waiting: 79 804 308.2 750 2285
    Total: 106 804 308.1 750 2287

    Percentage of the requests served within a certain time (ms)
    50% 750
    66% 841
    75% 942
    80% 990
    90% 1180
    95% 1381
    98% 1720
    99% 1935
    100% 2287 (longest request)

    Уже неплохо, 310 запросов в секунду это в 1,26 раза больше чем HHVM в обычном режиме.

    Оптимизируем дальше


    Поскольку изначально код не писался асинхронным — один запрос перед другим не выскочит, поэтому можно добавить обычный, не асинхронный режим, и допустить что запросы будут исполняться строго по очереди.
    В таком случае мы можем обойтись обычными массивами в суперглобальных переменных, не нужно делать debug_backtrace() при создании системных объектов, а некоторые системные объекты вместо полного пересоздания можно частично переинициализировать и тоже сэкономить.
    Вот какой результать это дает на пуле из 16 запущенных Http серверов (HHVM), Nginx балансирует запросы (прогрев 50 000 запросов на пул):
    Скрытый текст
    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: 8497 bytes

    Concurrency Level: 256
    Time taken for tests: 5.716 seconds
    Complete requests: 5000
    Failed requests: 4983
    (Connect: 0, Receive: 0, Length: 4983, Exceptions: 0)
    Total transferred: 44046822 bytes
    HTML transferred: 42381822 bytes
    Requests per second: 874.69 [#/sec] (mean)
    Time per request: 292.676 [ms] (mean)
    Time per request: 1.143 [ms] (mean, across all concurrent requests)
    Transfer rate: 7524.85 [Kbytes/sec] received

    Connection Times (ms)
    min mean[±sd] median max
    Connect: 0 0 0.9 0 7
    Processing: 6 284 215.9 241 976
    Waiting: 6 284 215.9 241 976
    Total: 6 284 215.8 241 976

    Percentage of the requests served within a certain time (ms)
    50% 241
    66% 337
    75% 409
    80% 442
    90% 623
    95% 728
    98% 829
    99% 869
    100% 976 (longest request)

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

    Так же есть перспективы для ещё большего увеличения производительности (например ожидается поддержка keep-alive и других вещей в ReactPHP), но тут уже многое зависит от проекта где это используется.

    Ограничения


    Так как мы сохраняем максимальную совместимость с любым существующим кодом — при асинхронном режиме при разных временных зонах пользователей нужно использовать их явно, иначе date() может вернуть неожиданный результат.
    Так же пока не поддерживается загрузка файлов, но 2 pull request'а для поддержки multipart уже есть, в ближайшее время могут быть включены в react/http, тогда заработает и здесь.

    Подводные камни


    Главный подводный камень в таком режиме — утечка памяти. Когда после выполнения 1000 запросов потребление памяти было одно, а после 5000 на пару мегабайт больше.
    Советы по отлову утечек:
    • Обрезать объем выполняемого кода до минимума, запустить 5000 запросов, логируя объем памяти после каждого выполнения, сравнить потребление
    • Добавить немного выполняемого кода, повторить
    • Продолжать до проверки всего кода, количество запросов можно опускать постепенно до 2000 (для того чтобы не ждать долго), но в случае когда есть сомнения — накинуть ещё несколько тысяч запросов будет не лишним
    • Несколько запросов может потребоваться для стабилизации потребления памяти, сначала до 100 запросов, иногда при запуске полной системы бывало до 800 запросов на стабилизацию потребления памяти, после этого объем потребляемой памяти перестает расти.
    • Так как ситуация не очень мейнстримная, может случиться так, что память течет не в вашем коде, а в сторонней библиотеке, либо вообще расширении PHP (PHP-CGI как пример) — тут можно пожелать удачи и не забывать про супервизор над сервером:)

    Второе — соединение с БД — оно может оторваться, будьте готовы его поднимать при падении. Это совершенно не актуально при популярном подходе, тут же может создать проблем.
    Третье — ловите ошибки и не используйте exit()/die() если только вы не имеете ввиду именно это.
    Четвертое — вам нужно каким-то образом отделять глобальное состояние разных запросов если собираетесь работать с асинхронным кодом, если асинхронного кода нет — глобальное состояние достаточно просто подделать, главное не используйте зависимые от запроса константы, статические переменные в функциях и подобные штуки, если только не хотите внезапно сделать гостя админом:)

    Заключение


    С подобным подходом существенного роста производительности можно достичь либо без изменений, либо с минимальными (автоматический поиск и замена), а с Request/Response фреймворками это ещё проще сделать.
    Прирост скорости зависит от интерпретатора и того, что код делает — при тяжелых вычислениях HHVM компилирует тяжелые участки в машинный код, при запросам ко внешним API можно использовать менее производительный асинхронный режим, но асинхронно грузить данные с внешнего API (если запрос к API занимает сотни милисекунд это даст существенный прирост в общей скорости обработки запросов).
    Если есть желание попробовать — в CleverStyle CMS это и многое другое доступно из коробки и просто работает.

    Исходники


    Исходников не много, при желании можно модифицировать и использовать в многих других системах.
    Класс в Request.php принимает запрос от ReactPHP и отправляет ответ, functions.php содержит функции для работы с глобальным контекстом (в том числе несколько специфических для CleverStyle CMS), Superglobals_wrapper.php содержит класс, который используется для массиво-подобных суперглобальных объектов, Singleton.php — модифицированная версия трейта, который используется вместо системного для создания системных объектов (он же и определяет какие объекты общие для всех запросов, а какие нет).
    Share post

    Similar posts

    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 85

      +1
      habrahabr.ru/post/79377/ — старичек phpDaemon
      github.com/kakserpom/phpdaemon — просто как серпом по яи…
        0
        Круто, нужно будет попробовать вместо ReactPHP подставить и сравнить что быстрее, по функциональности явно выигрывает.
        0
        Complete requests: 5000
        Failed requests: 4983

        Мощь! Или тестировались настолько динамичные страницы, что возвращался каждый раз разный результат?
          +2
          Complete requests: 5000
          Failed requests: 4983
          (Connect: 0, Receive: 0, Length: 4983, Exceptions: 0)

          На странице, отображается количество запросов в БД и общее время выполнения скрипта, ясно что они будут меняться и вместе с ними размер документа.
            +18
            Под нагрузкой мои сайты могут отдавать до пяти тысяч ошибок в секунду.
            0
            а можете погонять без базы, выводить например «hello world»? интересно насколько php быстр)
              0
              Тот же HHVM, пул из 16 процессов с 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)

              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)
                0
                хм, довольно медленно, может оно упирается в отсутствие Keep-Alive? да и 5к запросов при 15к рпс для теста будет маловато
              –10
              С завидной периодичностью появляются статьи про, что «ПХП не так уж плох» и «ПХП можно ускорить». Если бы все было так хорошо как пишут — такие статьи бы не появлялись. Короче: «Не верю!».

              Есть фундаментальные органичения ПХП, которые обусловлены его устройством. Чудес не бывает. Его можно ускорить в 4 и даже в 10 раз, но относительно его «производительности», этого будет недостаточно — нужны порядки.
                +3
                Статьи появляются чтобы развеять стереотипы, зря вы не верите.

                Устройство PHP в случае HHVM достаточно хорошее, компилируя тяжелые участки кода в машинный код вы не сильно уж сможете ускорить по сравнению с тем же Python, Ruby или NodeJS, просто некуда быстрее, у меня даже есть подозрение, что PHP окажется быстрее всех упомянутых. Конечно, можно написать на С, но это уже совсем другая история с другой областью применения.

                Фундаментально PHP может работать с сокетами, другое дело что только небольшой процент использует это подобным образом. Не привыкли потому что. На Тостере всё ещё советуют ставить Apache2 и Nginx перед ним, просто потому что привыкли, хотя практического смысла в этом нет.

                В статье описывается ситуация, когда фактически ничего не изменилось — мы просто перестали поднимать интерпретатор каждый раз и создавать системные часто используемые объекты (HHVM в FastCGI тоже оптимизирует кое-что, но не так существенно), а если начать использовать асинхронную работу с БД, файловой системой и различным внешними сервисами — поднять на порядки реально, зависит от контекста.
                  +2
                  Статьи появляются чтобы развеять стереотипы, зря вы не верите.


                  Ожидаю еще ряд минусов, но справедливость требует написать еще один ответ.

                  Я отдал этому монстру несколько лет своей жизни. Я очень верил в этот язык, но чем больше я про него узнавал, тем меньше он мне нравился. В итоге это выродилось в лютую ненавист к этому языку (да — я признаю, что я эмоционален, когда речь идет о PHP).

                  Я прошел путь через разные оптимизаторы (которые ингода кстати глючат), узнал что перед ПХП нужно ставить реверс прокси, чтобы выхлоп не блокировал работу скрипта, ставил мемкешд, чтобы ликвидировать «узкое место при обращении к БД». Узнал что ПХП не умеет работать с FCGI так как это задумано. То есть там нельзя было создать цикл обработки (возможно сейчас это уже не так). Мы пробывали клеить автоматом файлы в один, чтобы получить прирость производительности. И еще кучу-кучу всяких мелочей, которые давали надежду получить еще немного прироста. В итоге мы получили сотни процентов прироста. А каков итог? Этого мало.

                  К сравнению выснилось, что сервер на С++, способен обработать запрос, сделать полезные вычисления и отправить ответ пользователю за то время, пока! пустой! скрипт на ПХП даже не успеет загрузиться.

                  Стереотипы? Да — я работал с ПХП давно, но у меня есть сильные опасения, что принципиально с того момента мало что изменилось. Многие разработчики прокляли тот момент, когда решили писать на ПХП, потому что менкеджер всех убедил, что «ну фейсбук и вк же написаны на ПХП», даже не подозревая как сильно тот ПХП, который они использовали отличался от того ПХП на которм они собирались писать и не понимая через какое количество «боли и унижения» пришлось пройти этим людям.

                  Скажу честно — для меня пост о том, что «ПХП не такой уж медленный» — это пост про то, что «БигМак не такой уже и вредный».
                    +4
                    Я очень верил в этот язык

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

                    которые ингода кстати глючат

                    видать вы давно трогали 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 к примеру, распределить приложение по разным серверам… зато бюджет проекта от этого не будет раздуваться на порядки.

                      –1
                      Никогда этого не понимал. Понимаю привычку, но слепую веру — это глупо.

                      Для того, чтобы узнать язык, на нем нужно какое-то время писать. Судя по всему у вас переход из состяния «не знаю/знаю» произошел дискретно в момент, когда вы впервые увидели ПХП. Снимаю перед вами шляпу — я таких людей в своей жизни встречаю впервые.

                      видать вы давно трогали PHP. Вообще можете уточнить когда и с чем вы работали? У меня создается впечатление что это было лет так 5-6 назад

                      Абсолютно верно — я об этом написал. Это было давно. Те тенденции, которые я видел тогда (а так же исходная точка), позволяли сделать вывод, что принципиально ничего не изменится. Судя по всему так и есть, т.к. разговор в конечно счете снова про «разы», а не про «порядки». Ну а далее «интерпритатор, типизация, чудес не бывает» и всякое бла-бла-бла в этом роде. Не буду повторятся.

                      Я бы и перед реализацией на Rust/Go/C++ его ставил что бы не гонять постоянно CPU.

                      А я бы не стал, т.к. в Go вообще все операции асинхронные, а в C++ «нормальные пацаны» пишут все асинхрон.

                      Уже были попытки сделать из PHP тру fcgi но как-то это не популярная парадигма

                      Вы понимаете, когда люди придумали FCGI — это был не «прикол так». В этом был глубинный смысл: переход от CGI к FCGI. И сделано это было еще до ПХП. Я очень рад, если в ПХП наконец сделали возможность настоящего FCGI, т.к. плюсы от прогретого окружения могут перекрыть все остальные попытки «ускорения».

                      Походу это было еще до APC/OpCache…

                      Это было очень-очень давно.

                      К слову, приход в Фейсбук Александреску ничего для «этих ваших ПХП» хорошего не сулит. С учетом того, что весомый вклад в ПХП сделал именно ФБ, стоило бы задуматься.
                        0
                        Судя по всему у вас переход из состяния «не знаю/знаю» произошел дискретно в момент, когда вы впервые увидели ПХП.

                        Немного не понял о чем вы… Я когда начал писать на PHP еще даже и не думал идти в WEB и в принципе в программирование. У меня тогда просто были какие-то задачи которые я хотел как-то автоматизировать. А там уж как-то так сложилось.

                        разговор в конечно счете снова про «разы», а не про «порядки»

                        Среднестатистический разработчик убьет любую программу кривым запросов в базу. И тут нет разницы отрабатыват логика за 1 милисекунду или за 100, если запрос отрабатывает секунду (кривые джойны, нет индексов и т.д.). Производительности PHP более чем хватает, и опять же все узкие места связанные с вычислениями и алгоритмами стоит писать на другом языке (на худой конец на том же Си, с возможностью использовать всю мощь SSE/AVX… а скоро и FPGA впилят если уже не впилили). Чего-то можно добиться на JIT, если будет доступна информация о типах. Один из кор контибьюторов даже предложил что если эта RFC пройдет то он реализует компилятор PHP в нативный код (по сути компиляция опкодов в нэйтив и кеширование этого).

                        К слову, приход в Фейсбук Александреску

                        Насколько я помню Александреску делает там только ресерчи и пилит тулзы для девелопмента. Из того что там есть на D в данный момент (насколько мне известно, моя информация могла устареть уже прилично) — средства для статического анализа и препроцессоры для C++. Мне D как язык очень нравится, но развивается он в сравнении с теми же Go или Rust значительно медленнее.
                          0
                          Говоря про «разы порядки» я имел ввиду, что ПХП очень медленный.

                          Если я на C++ ускорю обработку запросов на 20% — то это будет «Вау! Круто!». Потому, что речь может идти про тысячи запросов.
                          Если вы ускорите ПХП на 400%, то вам скажут «ммм… окей. А еще можно что-то ускорить? Было бы неплохо...». Но можно конечно и серверов навалить. Подход про «железо дешевле» я тоже слышал.

                          Или вы правда считаете, что магическим образом качественный переходу уже произошел? Давайте только говорить честно.
                          Плохой тормозной код можно написать на любом языке. Алгоритм O(n^2) отработает при больших n на C медленнее, чем O(n) для PHP — этого я оспраивать не будут. Но если мы возьмем код на С++, написанный алгоритмически вменяемым человеком, то даже если этот код не точили напильником, то он будет быстрее, чем заточенный до блеска код на PHP.

                          Поймите мою позицию правильно. Пусть PHP существует, но не стоит говорить о скорости, о том что все на самом деле быстро. Говорите про «низкий порог вхождения», «быстрый старт» и другие подобные плюсы. Если бы PHP был быстр, то нужны бы были статьи, которые «разрушают мифы»? Почему-то не видно статей, которые разрушают мифы о том, что C или C++ тормозной. Это повод задуматься.
                            +4
                            Разве хоть кто-то здесь пытался доказать что сам PHP соизмерим по скорости с C++? Все в курсе что он и много других языков медленнее на порядки, и угадайте что? Мизерное количество сайтов написано на С++, даже высоконагруженные далеко не всегда написаны на нем. А если страничка на PHP генерируется не 100мс, а 10мс, то по моему ничего плохого здесь нет, или что вместо 300rps мы получаем 1000rps, минимально изменяя код, это же здорово, разве нет?
                              0
                              Все в курсе что он и много других языков медленнее на порядки, и угадайте что? Мизерное количество сайтов написано на С++, даже высоконагруженные далеко не всегда написаны на нем.

                              Сомо собой разумеется. Я не спорю, что «порог входа» для С++ сильно выше, чем для PHP. Я так же не спорю с тем, что «стартануть» на PHP быстрее, причем намного. За все нужно платить. Вопрос лишь в осознании этой платы.

                              А если страничка на PHP генерируется не 100мс, а 10мс, то по моему ничего плохого здесь нет, или что вместо 300rps мы получаем 1000rps, минимально изменяя код, это же здорово, разве нет?

                              1000rps — это какая-то синтетика и вам это точно известно. Это изумительно, но это синтетика — это не рабочий проект. Я читал такие же статьи много лет назад. Совершенно фантастические приросты производительности. А толку? Для меня отправной точкой для того, чтобы закончить работу с ПХП, было понимание о наличие потолка производительности, который очень низок и который не пробить никакми оптимизаторами. Я говорю не про алгоритимческую сложность, а про сложность единицы. Для того, чтобы «внезапно» не получить даже 300rps вовсе не обязательно решать задачи на графы. Есть PHP, который медленнее C++ на порядки, а есть Go (компиляция+типизация), который медленнее только в разы. И вот учитывая скорость старта и порог вхождений, говорить про разы на мой взгляд разумно, а говорить про порядки — нет.

                              Если ваш проект эти проценты спасают, то это здорово. А вот некоторые люди могут стукнутся в непробиваемый потолок в тот самый момент, когда сил уже вложено необратимо много. То что вы в этот потолок еще не стукнулись — это либо ваше счастье, либо ваше горе. Смотря по сопутсвующим обстоятельствам. Однажды можно храбро бросится в новый переспективный проект и узнать про этот самый потолок много нового и интересного. Вот такой вот мой «очень дорогой» опыт. Незнаю много ли таких людей, но они есть. И для нас — это не «мифы» — это «факты».

                              Для кого вы писали статью? Для тех кто с радостью пишет на PHP? Судя по вступлению — нет. Вы хотели переубедить тех кто считает, что «PHP умирает». Вот он я — вот мои аргументы. Обвините меня в том, что я про ПХП ничего не знаю и что мои обвинения голословны. Вы можите? В ответ я получу еще несколько минусов, потому, что статья написана не для меня, а для тех кто «в клубе любителей». Тогда начните статью словами «Сегодня я расскажу вам пару трюков о том, как сделать PHP еще быстрее...».

                              Зря я сюда влез — вы уж простите. Но не могу я без боли смотреть на статьи про «производительность» PHP. Рука тянется к клавиатуре. Наверное единственный аспект, где я сдержаться не могу.
                                +4
                                Если ваш проект эти проценты спасают, то это здорово. А вот некоторые люди могут стукнутся в непробиваемый потолок в тот самый момент, когда сил уже вложено необратимо много. То что вы в этот потолок еще не стукнулись — это либо ваше счастье, либо ваше горе. Смотря по сопутсвующим обстоятельствам. Однажды можно храбро бросится в новый переспективный проект и узнать про этот самый потолок много нового и интересного. Вот такой вот мой «очень дорогой» опыт. Незнаю много ли таких людей, но они есть. И для нас — это не «мифы» — это «факты».

                                Вы постоянно пишете, что кто-то стучится в какой-то потолок и плачет, но, как показывает история, к моменту стука об этот потолок (а это оооочень далекий путь на самом деле) уже не важно на чем вы там писали этот код. Или вам нужны примеры?
                                  0
                                  >Но не могу я без боли смотреть на статьи про «производительность» PHP

                                  Конечно, вы правы, что C++ на порядок круче PHP в плане производительности. С этим вообще никто не спорит. Но реальность такова, что на свете есть много людей, которые по разным причинам используют PHP, и для них вопрос повышения производительности может быть актуален. Зря вы так критикуете статью, в ней нет ничего плохого.
                                +3
                                что ПХП очень медленный.

                                Да не очень то он и медленный. В 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 — так что можно будет сделать основу для этого добра.
                                  +1
                                  Да не очень то он и медленный.

                                  По вашей ссылке от 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
                                    0
                                    И часто вы на PHP пишете операции над последовательностью ДНК или множество мандельброта рисуете?
                                    Кстати у Rust цифры ещё лучше, может быть всем пересесть на него?
                                      0
                                      кстати, о том же множестве Мандельброта на php уже говорили сегодня в дайджесте PHP, процитирую:

                                      Представлена экспериментальная реализация JIT для PHP от Zend — Один из главных авторов PHPNG, Дмитрий Стогов, анонсировал реализацию JIT. На некоторых синтетических тестах заметен значительный рост производительности, а для специфичных случаев, например, подсчет множества Мандельброта, показывает 30 кратный рост и опережает реализацию на C.
                                        0
                                        Реализацию на С с -o2, смею заметить.

                                        В любом случае они пока забросили эксперементы с JIT и выкинули в opensource. Может к 8-ому пыху и сделают официально, пока вся надежда только на сторонних разработчиков которым будет интересно допилить это дело в рамках opcache.
                          +1
                          А какова версия PHP была в описываемое время? Любопытно очень.
                            –3
                            Я боюсь ошибиться, но судя по датам это была версия 5 или выше, т.к. там уже были области видимости внутри класса.

                            Кстати вот интересный вопрос: разработчики PHP все еще считают, что «закрытый член класса» — это такой член, «о котором снаружи никто не знает» или они уже пришли к заключению о том, что это член класса, «к которому нельзя снаружи обратиться»?
                              +2
                              PHP Fatal error: Cannot access private property Foo::$bar in /home/zTq6k1/prog.php on line 8

                              ideone.com/lWkkGJ

                              если я правильно вас понял. С инкапсуляцией у PHP все ок. И судя по всему вы застали переход от PHP4 к PHP5 и все.
                                –1
                                Судя по всему ничего не поменялось таки.
                                Модифицирую ваш пример.

                                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);
                                
                                  +1
                                  А как по вашему, как должно работать? Приватное свойство никак не влияет на цепочку наследников. Оно есть в классе Foo, в классе Bar его нет и интерпритатор воспринимает его как неявное публичное свойство. Все работает так же, как если бы вы в Bar объявили публичное свойство $bar. То есть поведение приведенное вами соответствует такому коду:

                                  class Foo {
                                      private $bar = 'bar';
                                  }
                                  
                                  class Bar extends Foo {
                                      public $bar;
                                  }
                                  


                                  Инкапсуляции от этого хуже не делается, наоборот, никто ничего не знает о реализации базовых классов. Совсем ничего. PHP вам кинет нотис о том что вы обратились к несуществующему свойству и все.
                                    0
                                    Фактически это означает, что изменение области видимости влияет на логику работы кода.
                                    Попробуйте вопроизвести подобный пример в Java или C++.
                                      0
                                      конечно, изменение области видимости должно влиять на логику кода. Иначе бы не было различных областей видимости.
                                        0
                                        Это средство контроля — не средство изменения логики. В С++ так и есть. И в Яве тоже.
                                        Скомпилированный код на С++ с разными областями видимости (если оно скомпилировалось) ничем бинарно не отличается.
                                        +1
                                        С каких пор C++ эталонный пример реализации инкапсуляции?

                                        Что до Java — там все так же: ideone.com/soDELi
                                          0
                                          Проверьте пример — кажется там не то.
                                          ideone.com/D9V4Rx
                                            0
                                            Там именно то. Когда в PHP вы обращаетесь к объекту у которого нет такого свойства, выкидывается предупреждение и создается публичное свойство. Динамически, в рантайме. Это другое свойство, оно никакого отношения не имеет к свойствам родительского класса. Можно написать свой обработчик ошибок который на подобные действия будет кидать исключения, но… суть все та же. Разница в поведении только в этом. Так сложилось исторически и по причинам сохранения обратной совместимости (из-за всяких wordpress) решено видимо было оставить подобное поведение.
                                              –3
                                              Я понимаю как оно написано. Я понимаю как оно работает. Тут для меня нет тайны.
                                              Но мы пришли к тому с чего начали
                                              разработчики PHP все еще считают, что «закрытый член класса» — это такой член, «о котором снаружи никто не знает»

                                              и что в PHP
                                              изменение области видимости влияет на логику работы кода.

                                              Мне кстати более таких языков не известно — наверное я их не очень много знаю.
                                                0
                                                разработчики PHP все еще считают, что «закрытый член класса» — это такой член, «о котором снаружи никто не знает»

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

                                                изменение области видимости влияет на логику работы кода.

                                                Вы видимо не работали с Python хотя бы… А уж как у вас начнет бомбить когда вы хотя бы годик на JS плотно попишите…
                                                  0
                                                  А я не люблю Python. И сказать про него много не могу. Но я же здесь не про Питон разжигаю, а про ПХП. На JS немного пописал — это тоже не мое. Но там ведь я не припомню private. Вообщем по поводу перечисленных яызков — возражений не имею.
                                                    0
                                                    У Python формально тоже нет модификаторов доступа. Да и мне лично хватает того что PHP хоть как-то ругается на эту тему. Так же есть статические анализаторы которые будут сильно ругаться на подобные штуки. В остальном меня более чем устраивает подобное поведение.
                                      0
                                      Специально для вас:

                                      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
                                        –2
                                        Да, а должно быть оба раза Cannot access. По «хорошему».
                                          0
                                          С какой стати? Это же private, а не protected.
                                            0
                                            Потому, что область видимости означает, что «к члену класса нельзя обратиться», а не то, что «этого поля никто не должен видеть». Такая реализация приводит к изменения логики работы программы при изменениии области видимости. Это не в какой ООП простите не лезет.
                                              +3
                                              Можете меня просветить, в таком случае, какие принципы ООП нарушает скрытие приватных свойств, а не запрет доступа к ним? Буду благодарен за ссылки на источники, которые позволят мне вырасти в этом понимании.
                                                –1
                                                Вы не вполне понимаете. От того, что произошло наследование, поле «foo» не стало «более private». Оно было унаследованно и осталось private. Как и было. ничего не поменялось. Точнее «ничего не должно было поменяться». Однако поменялось. Мембер только что «был, но к нему нельзя было обратиться», а теперь «исчез».

                                                Как вы думаете: «наступал» я на это ли нет, раз пишу об этом?
                                                  0
                                                  Используйте protected и никуда он не исчезнет, либо я чего-то тоже не догоняю?
                                                  Если вы определили его как private он доступен только внутри класса, где определён.
                                                  Если объявить как protected — можно будет получить доступ и далее при наследовании.
                                                    0
                                                    Речь про то что видно снаружи.
                                                    В пример в классе Foo его видно, но он не доступен.
                                                    А в классе Bar его уже не видно снаружи.

                                                    В частности это имеет значение при использование рефлексии. При изменении области видимости вы можите получить разные результаты (хотя это могло поменяться, но с учетом описанного выше, думаю что нет).
                                                    0
                                                    да нет, в наследуемом классе оно уже не private, иначе к нему он тоже мог бы обратиться.

                                                    Если вы про потенциальные ошибки (когда я забыл, что поле private и пытаюсь его использовать в наследнике, но программа не завершается принудительно при таком кощунстве) — может быть некоторый осадок.

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

                                                    Т.е., более логичным было бы как раз в обоих случаях говорить о «Undefined property”. Но это привело бы, к сожалению, к большему числу ошибок, т.к. программисты часто игнорируют предупреждения, а реагируют только на ошибки.
                                                      0
                                                      да нет, в наследуемом классе оно уже не private, иначе к нему он тоже мог бы обратиться.

                                                      Хорошо — я выразился не вполне верно. С точки зрения пользователя (а пример рассматривается с точки зрения пользователя) ничего не поменялось. Он как не мог обратиться к этому полю — так и не может. Поле не исчезло. Проведите подобный эксперимент в других языках.

                                                      Как вы правильно заметили — правильно было бы иметь одинаковое поведение.
                                                        0
                                                        С точки зрения пользователя, private переменных/методов класса не существует. Для него существует только public
                                              –1
                                              Не должно, потому что private property не наследуется. Так же и в c++.
                                                0
                                                В С++ нет «property» — там есть «member». Но сути это не меняет. Перепишите данный пример на С++.
                                                  +1
                                                  Да, я ошибся, в с++ действительно private свойства наследуются. Сбила с толку статья, где было описано, как наследуются public и protected свойства при public, protected и private наследовании, но не было сказано про наследование private свойств.
                                                  0
                                                  По древу наследования спускаемся вниз, находим приватное свойство — фэйлимся. В случае с PHP мы вместо этого «додумываем» публичное свойство у наследника, выкидываем на всякий нотис и живем себе. Вот и все. Причем вам никто не запрещает конвертировать эти нотисы в исключения.
                                                    0
                                                    Мы с вами говорим об одном и том же, с той только разницей, что я ставлю знак "-", а вы — знак "+".

                                                    Я попробую показать еще один пример: если вы попробуете использовать рефлексии, то
                                                    $api = new ReflectionClass($f);
                                                    
                                                    foreach($api->getProperties() as $p) {
                                                        print $p->getName() . "\n";
                                                    }
                                                    

                                                    даст вам разные результаты для private и protected, хотя и в том и в другом случае доступа к члену класса нет. Я имею ввиду пример с B extends A.

                                                    То есть вы порефакторили класс — только изменили область видимости и изменили логику работы программы. В C++ или Java я могу быть точно уверен, что логика работы от замены private на protected или наоборот не изменится. Мой код может не скомпилироваться — это верно, но работать он будет так же.
                                                      +1
                                                      Все правильно, такова особенность PHP — создание свойств на лету. Товарищ dnovikoff предъявляет претензию, что php неправильно интерпретирует модификатор private, но это не правда.
                                                        –2
                                                        «Модификаторы доступа» — общепринятая концепция, которая ограницичает доступ, а не видимость. То что «создание свойств на лету» (частное свойство языка) является более приоритетным, чем общепринятая концепция — это большая беда и болезнь языка.

                                                        В PHP используется термин «Visibility», хотя в большинстве языков используется термин «Access Modifiers». Удивительно, но даже в документации PHP речь идет про «access», хотя в заголовке написано про «visibility». Удивительная подмена понятий: говорим про «видимость», а рассказываем про «доступ».

                                                        В документации на php я нашел ровно этот случай с пометкой значения значения как «Undefined». Так что правильно или нет — вопрос вкуса. С точки зрения документации — да. С точки зрения логики и общепринятой практики — это большой вопрос.

                                                        Если вы считаете, что раз оно в PHP так, то это правильно, я не имею возможности с вами спорить. Нет логической возможности для оспаривания аксиоматических утверждений. Есть «модификаторы доступа», которые появились задолго до PHP. Есть практика их использования, есть разговор про «доступ», а не про «видимость». Если создадут язык в котом слово «class» означает объявление строки, а слово «public» — выделение места на куче, то сложно будет поспорить с тем, что это особенность языка.
                                                          0
                                                          да, я действительно ошибался, но не так уж и сильно. Родительское private свойство можно переопределить в потомке как public. Иначе получается, такой код не может иметь право на существование (пример на шарпах, но в плюсах поведение такое же):
                                                          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 можно использовать без явного их объявления.
                                                            +1
                                                            Родительское private свойство можно переопределить в потомке как public

                                                            Это будет другой член класса с таким же именем. Это назвается shadowing (затенение). Точно так же во многих языках допускается shadowing внутри scope. К разговору о доступе это отношения не имеет.

                                            0
                                            PHP все еще считают, что «закрытый член класса» — это такой член, «о котором снаружи никто не знает» или они уже пришли к заключению о том, что это член класса, «к которому нельзя снаружи обратиться»?
                                            Вы с Пайтоном перепутали сейчас.
                                              0
                                              В PHP такое точно было. Может быть в Питоне тоже.
                                                +1
                                                В PHP просто не было приватных и защищённых методов и свойств какое-то время (лет 15 назад).
                                          0
                                          Хмм…
                                          Я знаю способ писать программы, которые могут работать еще быстрее аналогов, написанных на C++.
                                          Это написание программ на ассемблере!

                                          Но почему-то даже системные программисты не часто выбирают такой подход для написания своих приложений.

                                          Так так ли важна скорость работы программы в контексте выбора ЯП для какой-либо задачи?
                                            +1
                                            Я знаю способ писать программы, которые могут работать еще быстрее аналогов, написанных на C++.

                                            Оптимизации в современных компиляторах обычно справляются с этой задачей намного лучше большинства людей.
                                              0
                                              Безусловно, но если речь идет, например, об использовании инструкции процессора, о которой оптимизатор еще не знает.
                                              Думаю, что можно изобрести еще примеры. Опять же ассемблерные вставки в C код не просто так там появляются.
                                                0
                                                Ну вы же понимаете что если брать по соотношению кода, то между PHP и C++ не такая уж сильно большая разница так что это не вполне корректное сравнение. Благо стандарты (x11, x14) последних лет реально упрощают жизнь. Скажем если писать на том же Go — там так же не намного сложнее чем на PHP в плане скорости разработки, просто добавляется оверхэд на компиляцию и откладку. А в целом — очень даже миленько все.
                                                  +1
                                                  Хорошо, тогда, если мы пропустим диспуты по поводу наличия или отсутствия подходящих библиотек, то в сухом остатке придем к выводу, что выбор ЯП (и соответствующего стека технологий) должен быть обусловлен в большей степени характером решаемой задачи.

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

                                                  Своим замечанием я и хотел это продемонстрировать.
                                                    0
                                                    А в целом — очень даже миленько все.

                                                    Да, это возможно. На мой взгляд для широкого применения Go в массах в нем очень не хватает MVC фреймворка.
                                                      0
                                                      MVC фреймворка.

                                                      MVC — UI архитектура, для сервера нужны request/response фреймворки. Собственно в PHP мире тоже нет MVC фреймворков, просто почему-то народу очень нравится эта аббревиатура. Ну а шаблонизаторов и ORM для go уже нормально.
                                                        0
                                                        MVC — UI архитектура, для сервера нужны request/response фреймворки. Собственно в PHP мире тоже нет MVC фреймворков

                                                        То есть веб сайт — не имеет UI я так понимаю?
                                                          0
                                                          Имеет, почитайте вот это:
                                                          blog.ircmaxell.com/2014/11/a-beginners-guide-to-mvc-for-web.html
                                                            0
                                                            Тогда, скорее, более интересным является продолжение статьи: blog.ircmaxell.com/2014/11/alternatives-to-mvc.html

                                                            В общем, и автор этих статей говорит об этом, существует два понятия: MVC архитектура и MVC фреймворк (автор использует кавычки для MVC). Думаю, что из контекста должно быть понятно какое из понятий используется в конкретном моменте.
                                                              0
                                                              Я о том и говорю. «MVC» фреймворки потому и не нужны. А request/response фреймворков для go хватает. Так же как и средств для организации модели, сервисного слоя и слоя представления.
                                                                0
                                                                «MVC» фреймворки потому и не нужны

                                                                Я имею в виду, что Go не хватает чего-то подобного Rails или Django или Yii как это не назови. Своей популярностью Ruby или Python в среде веб-разработки обязаны по большей части этим фреймворкам.

                                                                Для веб-сокетов Go, по всей видимости, неплох. Но разрабатывать на нем какой-нибудь веб портал пока совсем не тянет.
                                                                  0
                                                                  Не любитель я писать велосипеды…
                                          +2
                                          Есть фундаментальные органичения ПХП, которые обусловлены его устройством.

                                          Не посвятите?

                                          PHP и так быстрее Ruby (если заставить его работать по той же модели). Чего вам еще нужно?
                                            –11
                                            Не посвятите?

                                            PHP — это интерпретируемый язык без строгой типизации. Вопросы?
                                              +3
                                              Ясно понятно. И что? В PHP7 по всей видимости будет тайпхинтинг для скаляров, это конечно не то же самое, но на основе этого где-нибудь в 8ой версии или в виде экстеншена уже можно запилить вполне себе эффективный JIT/AOT. Более того, если у вас настолько специфичная задача что производительности PHP не хватает (это реально очень специфичные штуки типа обработка изображений и т.д.) — можно дописать эти узкие места, которые обычно составяют не более 5% функционала, на Си в виде экстеншена.

                                              В целом ваша позиция мне ясна. Вы предлагаете выкинуть все эти детские игрушки типа Python/Ruby/PHP в угоду православных C++/Rust/Go/D/etc… просто так… потому что вам кажется что это не эффективно. И вырезать на корню вообще всю нишу rapid development и т.д.
                                                –6
                                                Расскажите мне про это еще раз, когда «по всей видимости будет» " где-нибудь" — тогда будет смысл говорить. Всегда есть куча крутых идей в проэкте, но:
                                                1) Они не всегда реализуются
                                                2) Не всегда реализуются в том виде
                                                3) Не всегда дают ожидаемый эффект

                                                И «специфичных» задач на ПХП у меня нет. У меня нет никаких задач на ПХП уже очень давно. Я этому несказанно рад.
                                                  0
                                                  Расскажите мне про это еще раз, когда «по всей видимости будет» «где-нибудь»
                                                  в «Хаке» есть.
                                            0
                                            Скорости работы php уже давно хватает, как вы сами писали в данной ветке — подпирать приходилось сервер и хранилище, а фейсбуку мощностей хватало ещё до всяких придумывания всяких HHVM, хватало даже древнего php4, с тех пор производительность пилят, хотя она уже была ДОСТАТОЧНОЙ, в реальности ускорее получается небольшое, потому что упираемся во всякие сторадж, а не рассчитываем сложные алгоритмы для массивов данных для бигдаты.

                                            Теперь о статье. В традиционном подходе у php не проблема со скоростью, а с тем, что на каждый запрос выделяется отдельный процесс. Соответственно, если ты держишь по вебсокетах 1000 конектов, то у тебя поднимается ОДНОВРЕМЕННО 1000 процессов со скриптом. По сравнению с этим конкурентность 128, после которой падало — это ничто. В такой момент приходят к единому демону, который принимает все запросы и хендлит их по мере надобности. Автор же запустил в таком режиме cms-ку, которая изначально не задумывался для работы в режиме демона, это круто, попутно объяснил как надо и не надо писать, чтобы не было проблем с демонизацией. Современные же php фреймворки с DI и middleware как правило не имеют проблем с демонизацией, пишите на здоровье.

                                            Но все эти асинхронности и статическая типизация десятилетиями валяются на задворках pecl, так как процесс родился-отработал-умер практически идеален для бизнеса и для большинства задач. Потому php-шники В СРЕДНЕМ получают больше, чем сишники, для нашей страны это 2000 против 1700.
                                              0
                                              Про DI: далеко не во всех реализациях под РНР есть понятие «scope», без которого в таком режиме оно просто не будет адекватно работать, например, абсолютно любой сервис зависящий от «request» должен пересоздаваться при новых запросах, но это поведение не реализовано практически ни в одном из популярных DI-framwork-ов.
                                              Даже в тяжеловесном symfony di-container нет этого функционала из коробки, да там есть «scope», но совсем не для этого.

                                              Тем не менее, прирост такого рода статей за последнее время не может не радовать.
                                            +3
                                            «was able»
                                              0
                                              Какой-то негатив тут разгорелся на тему PHP, в отдельных местах. Коллеги, вы чего?

                                              Напрашиваются две мысли, после прочтения комментов:

                                              Кстати вот интересный вопрос: разработчики PHP все еще считают, что «закрытый член класса» — это такой член, «о котором снаружи никто не знает» или они уже пришли к заключению о том, что это член класса, «к которому нельзя снаружи обратиться»?

                                              Также интересно, пришли ли отдельные C++ разработчики таки к заключению, что разные языки хороши для решения разных задач, а иногда разумно использовать стек из разных технологий, что бы построить то или иное решение? Или они все еще считают, что ты пишешь либо на PHP, либо на C++! Точка!

                                              Словом… лучше уж пусть школьники пишут на PHP который будет умирать. Индустрии нужны люди которые пилят бложики.

                                              Действительно, ведь крутые C++ программисты напишут бложик на C++, или вообще никогда не столкнуться с такой низкоуровневой задачей/просьбой.
                                                0
                                                Поправка, не низкоуровневой, а не требующей высокой квалификации.

                                              Only users with full accounts can post comments. Log in, please.