Strict Types :: Opcode и память

Full-R

Новичок
Привет, клуб.

В поисках удешевить стоимость сервера я перевел свой framework на strict types и смог реализовать отдельный статический кэш БД.
Из сторонних компонентов есть только перепрограмминованный MMDB Reader и Decoder для Geo IP Max Mind под strict types.

Я также не использую никакие лишние функции PHP. Все работает нативно и без mb_string и iconv. То есть примерно 30% мне требуется от стандартного набора функционала самого языка для запуска framework.

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

Все хорошо, но я обнаружил, что OpCode cache не работает на Strict Types и PHP Fast CGI + FPM, а также память затраченная на стабильный закэшированный бэкенд плавает на 100-200 Кб.

Логически я понимаю, что для final классов не нужно ключевое слово static для методов и свойств, однако я и это сделал.
Extend отключен, а память все равно неодинаковая. Как это объяснить, если я отключаю все ненужные для PHP функции?
Как правильно посчитать затраченную память? Например PHP наверняка не покажет, как работает handler fopen, если размер файла, который открыт для чтения будет например 100Gb, а доступно памяти в системе около 8Gb так как файл читается частями [0%===<O>===============100%].

Или я ошибаюсь?

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

Также мне нашептали, что static не канает для opcode если его ставить после ключевого слова: protected static - не кэшится, а static protected - кэшится.
В чем сраная разница, если не учитывать некоторых упоротых экслюзивных любителей трактовать работу класса по разному в зависомости от положения ключевого слова?

Много ли хуже реализовывать подскачку класса на базе инжекта методов trait в нужные private, public и protected, а не extend? Использую в основном массивы для стэков данных коллекций, а не объекты и получаю нерельную экономию памяти и быстродействие сравнимое со скомпилированным C++ приложением.
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
Или я ошибаюсь?
Да, практически все написанное - бред сивой кобылы.
PHP компилируется в AST, а затем в байткод, и все сущности - это ZVAL-структуры. Любая сущность - это структура одного вида. Opcode cache просто держит байткод в памяти.
Это значит, не может быть зависимости работы байткод-кеша ни от порядка написания модификаторов, ни от типизации.

Работа с памятью в php была хорошо описана в статье на хабре несколько лет назад, блог mailru. PHP выделяет память "как бог на душу полжит" - большими блоками, и освобождает ее не сразу.

А если интересует ускорение на уровне именно PHP без учета базы - @Sam Dark пишет, что с rodrunner можно укорить ответ в 20 раз, не то что фигней страдать с mb_string и экономить на чае.
 

Yoskaldyr

"Спамер"
Партнер клуба
А если интересует ускорение на уровне именно PHP без учета базы - @Sam Dark пишет, что с rodrunner можно укорить ответ в 20 раз, не то что фигней страдать с mb_string и экономить на чае.
Только если использовать roadrunner, то ускорение идет за счет выкидывания бутстрапа приложения (1 кратное выполнение на все запросы). И это аналогично swoole (в некоторых режимах) и php-pm (не fpm).

Но теперь главный вопрос - где автор и где бутстрап приложения, roadrunner, swoole, php-pm ???? :)
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
Если автор потратил сотни часов "В поисках удешевить стоимость сервера, смог реализовать отдельный статический кэш БД",
и получил "время выполнения всего ядра в пределах 0.07 - 0.1 секунды", почему бы теперь не потратить еще пару сотен часов, освоить roadrunner/swoole/amp, и получить время выполнения своего ядра вместе с приложением в пределах 0.01 сек? Я попробовал, мне понравилось.
А с выходом 8ки с jit можно попробовать дойти до 500 простых запросов в секунду на ядро.
 
Сверху