Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 103
> Если будет интересно, есть в планах идея описать способы профилирования кода и поиска узких мест с помощью XHprof.
Интересно!
Интересно!
Хорошо. Пока думаю на тему — какой проект для этого использовать. Тут нужен реальный проект для примера, но при этом — не могу использовать свой рабочий проект.
В добавок — проект не должен быть слишком сложный, иначе примеры будут слишком сложнопонимаемые :)
В добавок — проект не должен быть слишком сложный, иначе примеры будут слишком сложнопонимаемые :)
Возьмите любую не очень популярную CMS, забитую тестовыми данными, я думаю сгодится для тестов.
Можно уточнить, что в данной оптимизации является нестандартным?
Профайлинг mysql запросов — вполне себе best practics,
рефакторинг кода, особенно после адекватного анализа — тоже вполне разумный и популярный шаг,
То есть я бы сказал, что вы все сделали верно, даже профессионально, но где же изюминка?
Профайлинг mysql запросов — вполне себе best practics,
рефакторинг кода, особенно после адекватного анализа — тоже вполне разумный и популярный шаг,
То есть я бы сказал, что вы все сделали верно, даже профессионально, но где же изюминка?
Именно поэтому я не хотел обращать внимание на профайлинг mysql запросов. Подобный профайлинг описан во большом количестве мест, и писать о нём ещё раз — не интересно :)
Самые главные мысли которые я хотел донести:
1. Показать необычный кейс, о котором многие разработчики даже не задумываются, и возможно помочь кому либо оптимизировать свой код.
1. Нужно внимательно анализировать даже на те вещи, которые маловероятны.
2. Соблюдение всех ООП практик по разделению кода на классы — может повлиять негативно в плане использования памяти. Есть большая вероятность что процессору придётся обрабатывать ненужные вещи. (тут конечно можно поспорить на тему «что такое лучшие ООП практики»)
Самые главные мысли которые я хотел донести:
1. Показать необычный кейс, о котором многие разработчики даже не задумываются, и возможно помочь кому либо оптимизировать свой код.
1. Нужно внимательно анализировать даже на те вещи, которые маловероятны.
2. Соблюдение всех ООП практик по разделению кода на классы — может повлиять негативно в плане использования памяти. Есть большая вероятность что процессору придётся обрабатывать ненужные вещи. (тут конечно можно поспорить на тему «что такое лучшие ООП практики»)
Если взять ВСЕ ООП практики, то они вполне могут и противоречить друг другу.
Именно поэтому для крупных проектов нужен не senior programmer а program architect, который спроектирует хотя бы ядро системы и общую политику для проекта.
НО, это опять таки best practice ;)
Именно поэтому для крупных проектов нужен не senior programmer а program architect, который спроектирует хотя бы ядро системы и общую политику для проекта.
НО, это опять таки best practice ;)
Мне лично больше интересует почему вообще возникла такая проблема, что 20мб памяти на запрос это много и тормозит. Меня крайне интригует этот момент. Тут больше не потребление памяти наверное играло роль, а то что все грузилось в рамках одного запроса, даже то что не должно. В этом плане какой-нибудь IoC контейнер решил бы массу проблем. Ну и так же интересно на какой версии PHP у вас все это крутилось, установлен ли opcache и с какими настройками. Сколько вообще ОЗУ.
Ну и да, я думаю если бы вы обновились хотя бы до php 5.4 уже был бы ощутим прирост производительности.
я щас может кого шокирую =) у нас рельсовое приложение кушает по 800мб на воркера, и всё достаточно шустро работает.
так что 20мб это сказочная цифра
так что 20мб это сказочная цифра
Рельсы — всё же не PHP. В питоне тоже нет подобной проблемы, насколько я знаю.
В PHP же проблема что сервер умеет кешировать код, но при этом, ему приходится загрузить этот кешированный файл в рабочую область текущего запроса. И на это уходит полезный ресурс — память и соответственно время
В PHP же проблема что сервер умеет кешировать код, но при этом, ему приходится загрузить этот кешированный файл в рабочую область текущего запроса. И на это уходит полезный ресурс — память и соответственно время
Воу воу, opcache хранит все в shared memory. Вообще никакого оверхэда за счет этого, один и тот же кэш на все воркеры. Более того, начиная с php5.4 появилась куча внутренних оптимизаций, сильно сокращающих оверхэд по использованию памяти. opcache же расширяет действия некоторых оптимизаций храня данные не для воркера а для всего пула воркеров.
Если обновить php с 5.3 до 5.5 то это уже может дать прирост в 30% если ситуация именно такая, как описана в статье.
У PHP проблема в том что он умирает. Есть примеры где приложение запущенное из под ReactPHP в качестве сервера работало ощутимо быстрее, потому как часть сервисов можно вообще не выгружать между запросами.
Если обновить php с 5.3 до 5.5 то это уже может дать прирост в 30% если ситуация именно такая, как описана в статье.
У PHP проблема в том что он умирает. Есть примеры где приложение запущенное из под ReactPHP в качестве сервера работало ощутимо быстрее, потому как часть сервисов можно вообще не выгружать между запросами.
У PHP проблема в том что он умирает.
Почему, я бы сказал воскресает.
Представьте что у вас есть огромный массив данных в файле.*
Этот массив был обработан, преобразован в opcache и добавлен в shared memory. Всё выглядит ок.
Теперь, как только вы захотите загрузить данный массив в текущую рабочую область конкретного запущенного скрипта — он скопируется и будет использовать память из текущего потока.
Другими словами: если вы хотите использовать массив на 10мб, то каждый скрипт должен использовать как минимум 10 мб памяти. И да, получится что каждый скрипт копирует одни и теже данные к себе в рабочую область из shared области.
Но в shared области — данные хранятся «в общем виде», а в «текущей рабочей области» — хранятся только для данного скрипта, причём с возможность быстрого чтения по индексу, и тп.
Абсолютно таже проблема, если мы берём не «массив», а «класс». Нам нужно его из shared памяти перетащить в «рабочую память».
PS:
* Сейчас не идёт разговор о том, как оптимизировать скрипт так, чтобы он не читал этот файл вообще, или читал его куски только. Это тоже можно и нужно делать, но это совсем другой вопрос.
Этот массив был обработан, преобразован в opcache и добавлен в shared memory. Всё выглядит ок.
Теперь, как только вы захотите загрузить данный массив в текущую рабочую область конкретного запущенного скрипта — он скопируется и будет использовать память из текущего потока.
Другими словами: если вы хотите использовать массив на 10мб, то каждый скрипт должен использовать как минимум 10 мб памяти. И да, получится что каждый скрипт копирует одни и теже данные к себе в рабочую область из shared области.
Но в shared области — данные хранятся «в общем виде», а в «текущей рабочей области» — хранятся только для данного скрипта, причём с возможность быстрого чтения по индексу, и тп.
Абсолютно таже проблема, если мы берём не «массив», а «класс». Нам нужно его из shared памяти перетащить в «рабочую память».
PS:
* Сейчас не идёт разговор о том, как оптимизировать скрипт так, чтобы он не читал этот файл вообще, или читал его куски только. Это тоже можно и нужно делать, но это совсем другой вопрос.
Возможно я чего-то не знаю, но мне казалось что разделяемая память на то и нужна что бы не нужно было ничего копировать в локальное адресное пространство процесса. Просто несколько процессов делят между собой одно адресное пространство, через mmap или другие штуки специфичные для своей платформы.
Ну то есть возможно копирование данных там и идет (что бы не допускать сильно долгих блокировок и конфликтов) но это же не обязательно.
Ну то есть возможно копирование данных там и идет (что бы не допускать сильно долгих блокировок и конфликтов) но это же не обязательно.
Вы можете доказать, что опкоды копируются из shared memory в область скрипта?
возьмём пример:
мы делаем include файла в котором только описание класса (или массив).
У нас стоит opcache/apc, и мы не первый раз загружаем данный файл, один и тот же поток апача, по мониторингу apc/opcache — происходит cache hit.
Просто include данного файла, без создания экземпляра данного класса — увеличивает потребление памяти текущим пхп скриптом. Вопрос — на что это тратиться?
Т.е. пример:
$memory = memory_get_usage();
include «class.php»;
echo memory_get_usage()-$memory;
Почему увеличилось использование памяти? Ведь данные должны быть общими для всех запросов, и мы могли бы их использовать напрямую из shared memory.
Могу перефразировать, возможно у меня неточность формулировки:
копируются не опкоды, а результат их выполнения в текущую область скрипта. Т.е когда в файле только описание класса, то opcache его преобразует в опкоды 1 раз. После этого, каждый раз при использовании данного файла, пхп выполняет опкоды, и результат выполнения опкодов — добавляется в текущую рабочую область скрипта каждый раз.
Такая формулировка понятнее? :)
мы делаем include файла в котором только описание класса (или массив).
У нас стоит opcache/apc, и мы не первый раз загружаем данный файл, один и тот же поток апача, по мониторингу apc/opcache — происходит cache hit.
Просто include данного файла, без создания экземпляра данного класса — увеличивает потребление памяти текущим пхп скриптом. Вопрос — на что это тратиться?
Т.е. пример:
$memory = memory_get_usage();
include «class.php»;
echo memory_get_usage()-$memory;
Почему увеличилось использование памяти? Ведь данные должны быть общими для всех запросов, и мы могли бы их использовать напрямую из shared memory.
Могу перефразировать, возможно у меня неточность формулировки:
копируются не опкоды, а результат их выполнения в текущую область скрипта. Т.е когда в файле только описание класса, то opcache его преобразует в опкоды 1 раз. После этого, каждый раз при использовании данного файла, пхп выполняет опкоды, и результат выполнения опкодов — добавляется в текущую рабочую область скрипта каждый раз.
Такая формулировка понятнее? :)
Да, такая формулировка ставит всё на свои места.
Почему увеличилось использование памяти? Ведь данные должны быть общими для всех запросов, и мы могли бы их использовать напрямую из shared memory.
Ну во первых какие-то накладные расходы все равно выходят, но это капля в море и вообще не должна влиять на производительнось. Простой SQL запрос по сравнению со всем этим будет казаться вечностью.
Во вторых, с точки зрения этого самого процесса, все адресное пространство его и только его. Процессу должно быть пофигу что кусок адресного пространства разделен между несколькими процессами. Посему если у нас процесс потребляет 10 метров своей памяти и между всеми процессами есть общая память в 2 метра то суммарное потребление будет показываться как 12 для каждого из них. Я предполагаю что mem_get_usage не сильно различает какая именно память была скушана в рамках этого запроса.
Возможно я не прав, я не сильно шарю в IPC и в том как это реализовано в PHP. Но все же, если судить по вашей логике, в оптимизациях типа string interning не особо много смысла.
Рельсовое приложение грузится один раз при запуске, а пхпшное при каждом запросе.
> Тут больше не потребление памяти наверное играло роль, а то что все грузилось в рамках одного запроса, даже то что не должно.
Да, проблему можно сократить и до этого.
Крутилось всё на пхп 5.3, с APC. Обновили до пхп 5.5 с opcache — количество длинных запросов сократилось ещё в 2 раза. При этом количество запросов обрабатываемых на том же железе — увеличилось. (т.е. на том же железе — стало всё быстрее, и при этом нужно меньше железа для обработки тех же данных).
При этом, мы конечно сравнивали ситуации на машине с PHP 5.5+ opcache, но с неоптимизированным кодом и с оптимизированным кодом — разница заметна на глаз была.
Да, проблему можно сократить и до этого.
Крутилось всё на пхп 5.3, с APC. Обновили до пхп 5.5 с opcache — количество длинных запросов сократилось ещё в 2 раза. При этом количество запросов обрабатываемых на том же железе — увеличилось. (т.е. на том же железе — стало всё быстрее, и при этом нужно меньше железа для обработки тех же данных).
При этом, мы конечно сравнивали ситуации на машине с PHP 5.5+ opcache, но с неоптимизированным кодом и с оптимизированным кодом — разница заметна на глаз была.
Кейс, кстати, часто встречается.
По моим наблюдениям, разработчики, как правило, понимают ООП как наследование и в лучшем случае добавить интерфейсов. Причём, если нет наследования (IoC, composition) то многих это ставит в ступор.
По поводу практик: вот шикарная книга (Patterns of Enterprise Application Architecture) — можно выбрать те паттерны, которые вам подходят больше всего.
По моим наблюдениям, разработчики, как правило, понимают ООП как наследование и в лучшем случае добавить интерфейсов. Причём, если нет наследования (IoC, composition) то многих это ставит в ступор.
По поводу практик: вот шикарная книга (Patterns of Enterprise Application Architecture) — можно выбрать те паттерны, которые вам подходят больше всего.
на тему необычности — меня в свое время гораздо больше порадовало, что можно добиться существенного ускорения пхп за счет минимизации кода (как в джаваскрипте — выкидываем проблеы лишние, сокращаем локальные переменные и т.п.) — тупо парсеру нужно будет читать меньше данных
тупо парсеру нужно будет читать меньше данных
PHP 5.4 + opcache + отключить инвалидацию кэша для продакшена и никакой разницы от аглификации (парсить код не нужно, а за счет string interning частое использование длинных названий функций/методов/классов/переменных не так сильно будет влиять на память.
Вообще не пойму что тут удивительного… меньше символов распарсить — быстрее разбор. Так у всех интерпритируемых языков. У PHP просто еще такая особенность что без опкод кешеров парситься все будет на каждый запрос.
да, согласен, этот мой печальный опыт был во времена молодого пхп 4.3, забавно, что за прошедшие 10 лет принципиальных улучшений не произошло — топикстартер воюет все с теми же граблями.
удивительно было какой сильный эффект это давало в то время, казалось бы такой шаг минификации пхп мог бы и сам сделать в момент чтения к примеру.
удивительно было какой сильный эффект это давало в то время, казалось бы такой шаг минификации пхп мог бы и сам сделать в момент чтения к примеру.
казалось бы такой шаг минификации пхп мог бы и сам сделать в момент чтения к примеру.
Что бы минифицировать названия переменных их нужно распарсить. Если вы уже распарсили имена переменных смысла минификация уже не имеет.
за прошедшие 10 лет принципиальных улучшений не произошло — топикстартер воюет все с теми же граблями.
Вы о каких таких граблях? Не оптимизированная/кривая архитектура? Причем тут PHP?
Откуда взялась мода советовать контейнеры при оптимизации ?)
Контейнеры добавляют удобство разрешения зависимостей, но никак не оптимизирует Ваш код.
Как раз наоборот, использование контейнеров добавляет расходы:
— маппинг определений и параметров хранится в памяти
— расходы на автозагрузку не меняются, более того, грузится еще и библиотека для реализации контейнеров
— резолвинг зависимостей тратит время и грузит процессор
Контейнеры добавляют удобство разрешения зависимостей, но никак не оптимизирует Ваш код.
Как раз наоборот, использование контейнеров добавляет расходы:
— маппинг определений и параметров хранится в памяти
— расходы на автозагрузку не меняются, более того, грузится еще и библиотека для реализации контейнеров
— резолвинг зависимостей тратит время и грузит процессор
— а где ему еще храниться?
— при наличии opcache настроенного, у вас все уже висит в памяти и никаких расходов особо на автозагрузку нет. А при наличии ленивой инициализации контейнер предотвратит от выстрела в ногу в виде «инджектим 100500 классов в один и используем только несколько из них».
— хороший контейнер умеет компилировать весь этот граф в быстрый шматок кода, который будет не медленнее (а то и быстрее, в зависимости от кривизны рук) чем просто инициализировать объекты на местах.
— при наличии opcache настроенного, у вас все уже висит в памяти и никаких расходов особо на автозагрузку нет. А при наличии ленивой инициализации контейнер предотвратит от выстрела в ногу в виде «инджектим 100500 классов в один и используем только несколько из них».
— хороший контейнер умеет компилировать весь этот граф в быстрый шматок кода, который будет не медленнее (а то и быстрее, в зависимости от кривизны рук) чем просто инициализировать объекты на местах.
Смысл моего комментария в том, что использование контейнеров не поможет оптимизироваться смысл Вашего — остается для меня загадкой…
1. Маппинг хранится в памяти и увеличает ее расход, а не уменьшает, значит оптимизации никакой здесь нет.
2. Ну и как тогда может помочь контейнер с автозагрузкой?
3. github.com/mnapoli/PHP-DI/blob/master/src/DI/Container.php#L104 — вот код который достает класс, Вы правда считаете что это быстрее чем «new»?
1. Маппинг хранится в памяти и увеличает ее расход, а не уменьшает, значит оптимизации никакой здесь нет.
2. Ну и как тогда может помочь контейнер с автозагрузкой?
3. github.com/mnapoli/PHP-DI/blob/master/src/DI/Container.php#L104 — вот код который достает класс, Вы правда считаете что это быстрее чем «new»?
1. Opcache решает эту проблему, а на память мне плевать (если речь идет о паре десятков килобайт, как в этом случае). Не бывает «и память не жрет и быстро».
2. Opcache решает эту проблему если сделать composer dump-autoload --optimize. Контейнер зависимостей тут не причем.
3. чем просто new — конечно же нет. Но давайте посмотрим правде в глаза, вы всеравно будете делать какой-то свой сервис локатор аля pimple с фабриками и прочим что бы код не превратился в гуано из бойлерплейта. Я думаю когда в PHP-DI наконец запилят компиляцию контейнера, опять же при грамотно настроенном opcache (имеется в виду отключение инвалидации кэша, подстройка сколько памяти оно может есть и т.д.) оверхэд будет минимален и незначителен. Есть так же и другие контейнеры, типа dice или тот же thephpleague/container.
2. Opcache решает эту проблему если сделать composer dump-autoload --optimize. Контейнер зависимостей тут не причем.
3. чем просто new — конечно же нет. Но давайте посмотрим правде в глаза, вы всеравно будете делать какой-то свой сервис локатор аля pimple с фабриками и прочим что бы код не превратился в гуано из бойлерплейта. Я думаю когда в PHP-DI наконец запилят компиляцию контейнера, опять же при грамотно настроенном opcache (имеется в виду отключение инвалидации кэша, подстройка сколько памяти оно может есть и т.д.) оверхэд будет минимален и незначителен. Есть так же и другие контейнеры, типа dice или тот же thephpleague/container.
Может тогда и советовать использовать opcache, а не контейнеры?)
Я еще раз повторю — контейнеры как способ оптимизировать приложение — бред, их используют абсолютно для других целей.
Я еще раз повторю — контейнеры как способ оптимизировать приложение — бред, их используют абсолютно для других целей.
Проблемы описанные в статье — это не проблемы именно алгоритмов или чего-то еще. Это архитектурные прощеты. Там описывается что много чего удалось достичь рефакторингом кода и добавлением отложенной инициализации. Контейнер не сильно поможет решить проблемы архитектуры, это верно, но половину проблем описанных в статье это дело решает. И дело тут не в потреблении памяти, а в том на что эта память расходуется.
Держать же продакшен без opcache/apc вообще нынче смысла нет.
Держать же продакшен без opcache/apc вообще нынче смысла нет.
прочим что бы код не превратился в гуано из бойлерплейта.
Я не не понимаю ничего в PHP (и не собираюсь) но обычно выбор состоит в том, чтобы это гуано из DI было явным или неявным.
Лично я предпочитаю явное гуано и контролируемый Rumtime Env. вместо того чтобы иметь hidden global state повсюду.
Это особенно болезненно когда хочется иметь хороший и быстрый код и нужно начинать писать тесты. Вот тогда познается весь «сок» магических посредников.
Лично я предпочитаю явное гуано и контролируемый Rumtime Env.
Ваше право, хотя вот честно, я не представляю как именно это «не явное» (если можете, приведите пример, возможно я вас не верно понял) мешает писать тесты. Принцип инверсии зависимостей соблюдается, вы как инджектили зависимости в конструктор объектов так и инджектите. А в тестах все зависимости мокаются и на DI вообще как бы пофигу. В случае с интеграционными/функциональными тестами так же нет проблем.
Есть просто очень много разных методов DI. В каждой среде по своему.
Я скорее о том чтобы действительно можно без напряга мокать все что пожелаешь.
И чтобы зависимости были явными. Все остальное менее важно.
Не явное, это тот вид жести, когда по коду разбросаны вызовы к глобальным переменным/состояниям :)
Или которые не явно затягивают переменные из родительского scope
Если про сервера, то это особенно касается Node/Python/Ruby/Java где приложение постоянно крутится на порте
с каким-то состоянием.
Еще всякие синглтоны этим ой как грешат.
Если код написан так что их можно «мокнуть» (:
Я скорее о том чтобы действительно можно без напряга мокать все что пожелаешь.
И чтобы зависимости были явными. Все остальное менее важно.
Ваше право, хотя вот честно, я не представляю как именно это «не явное»
Не явное, это тот вид жести, когда по коду разбросаны вызовы к глобальным переменным/состояниям :)
Или которые не явно затягивают переменные из родительского scope
Если про сервера, то это особенно касается Node/Python/Ruby/Java где приложение постоянно крутится на порте
с каким-то состоянием.
Еще всякие синглтоны этим ой как грешат.
А в тестах все зависимости мокаются
Если код написан так что их можно «мокнуть» (:
Ну я говорил про нормальный IoC контейнер, где от магии только проверка какие реализации каких интерфейсов хочет получить сервис, а дальше в зависимости от конфигурации. То есть никаких проблем с тестированием (если этих проблем не создал разработчик но тут уж IoC контейнер не сильно поможет).
Это просто когда нету состояния у запрашиваемого объекта
Вот когда нужно получить объект с внутренним состоянием, тогда начинаются вопросы правильной постройки.
И разработчик без хорошего понимания среды напишет код не очень хорошо.
Среда выполнения каждого языка имеет свои особенности. В С++ люди себе стреляют в ногу. В остальных
хочется выстрелить кому-то в голову (:
Вот когда нужно получить объект с внутренним состоянием, тогда начинаются вопросы правильной постройки.
И разработчик без хорошего понимания среды напишет код не очень хорошо.
Среда выполнения каждого языка имеет свои особенности. В С++ люди себе стреляют в ногу. В остальных
хочется выстрелить кому-то в голову (:
Это просто когда нету состояния у запрашиваемого объекта
Ну по сути контейнер создает инстанс только если он его еще не создавал (по сути шаблон одиночка), так что с состоянием у запрашиваемого объекта проблем нет.
За Singleton в приличном обществе можно и нужно получить по лицу (:
Там где его используют не по назначению. Вы еще скажите что goto это абсолютное зло.
Хотя бы один кейс хорошего использования Singleton?
Если вам нужно что бы в пределах приложения (в контексте PHP это обработка одного запроса) был только один инстанс сервиса — то тут стоит применить сингелтон. Собственно это основная идея сего паттерна.
В контексте DI это будет выглядеть так:
Можно назвать это registry а не singelton, но суть та же.
Проблема сингелтона не в том что он есть (его же не придумывали чисто как анти-паттерн), а в том как его чаще всего используют.
В контексте DI это будет выглядеть так:
$instances = [];
if (!isset($instances[$service])) {
$instances[$service] = invoke($service);
}
return $instances[$service];
Можно назвать это registry а не singelton, но суть та же.
Проблема сингелтона не в том что он есть (его же не придумывали чисто как анти-паттерн), а в том как его чаще всего используют.
Синглетон это антипаттерн сам по себе. Это не явная глобальная переменная. Часто еще и статическая.
Вот к примеру как вы будете тестировать этот код выше?
Вот к примеру как вы будете тестировать этот код выше?
Вы видите где-то у меня статику? А тестить… да как-то так думаю:
Оукей, если мы назавем это Registry вы успокоитесь? Что до статики и «глобальности» — то есть статические методы фабрики для вас тоже дикость? Или статический метод в абстрактном классе который пораждает своих наследников? (нарушая при этом LSP).
Есть академические каноны и есть прагматизм. Стоит различать когда что применимо.
class ContainerSpec extends ObjectBehaviour
function let(Invoker $invoker) {
$this->serviceInstance = new ServiceStub();
$invoker->invoke('service')->willReturn($serviceInstance);
$this->beConstructedWith($invoker);
}
function it_creates_instace_of_service()
{
$this->get('service')->shouldReturn($serviceInstance);
}
function it_returns_already_created_instance_if_have_one(Invoker $invoker)
{
$invoker->invoke('service')->shouldBeCalledTimes(1);
$this->get('service')->shouldReturn($this->serviceInstance);
$this->get('service')->shouldReturn($this->serviceInstance);
}
}
Оукей, если мы назавем это Registry вы успокоитесь? Что до статики и «глобальности» — то есть статические методы фабрики для вас тоже дикость? Или статический метод в абстрактном классе который пораждает своих наследников? (нарушая при этом LSP).
Есть академические каноны и есть прагматизм. Стоит различать когда что применимо.
Ок, я имел ввиду суть статической переменной. «попробовав раз ем и сейчас».
Дело не в фабриках и статике. Я не про академию, я про поддерживаемый код одним и более человеком.
Просто если вы можете выбросить весь свой рантайм то это очень и очень хорошо.
Насколько я понимаю тут:
пересобирается весь «рантайм» а старый выбрасывается на помойку?
Дело не в фабриках и статике. Я не про академию, я про поддерживаемый код одним и более человеком.
Просто если вы можете выбросить весь свой рантайм то это очень и очень хорошо.
Насколько я понимаю тут:
$this->serviceInstance = new ServiceStub(); пересобирается весь «рантайм» а старый выбрасывается на помойку?
Это просто стаб, по которому я проверяю что контейнер возвращает один и тот же объект. Это может быть new stdObject или что угодно что передается по ссылке. В рамках этого теста в принципе это не особо важно, нам важнее узнать что вызывался метод мока и во втором случае вызывался только один раз.
Причем тут рантайм не пойму… Я понимаю там… разговоры о разделении на слой приложения и слой фреймворка, слабую связанность и все такое. А рантайм… как его можно выкинуть или пересобрать? Он же рантайм…
Ну а что до поддерживаемости — DI как раз и создан для того что бы код был поддерживаемым и поддавался контролю. Разделение ответственности и все такое.
Причем тут рантайм не пойму… Я понимаю там… разговоры о разделении на слой приложения и слой фреймворка, слабую связанность и все такое. А рантайм… как его можно выкинуть или пересобрать? Он же рантайм…
Ну а что до поддерживаемости — DI как раз и создан для того что бы код был поддерживаемым и поддавался контролю. Разделение ответственности и все такое.
Это просто стаб, по которому я проверяю что контейнер возвращает один и тот же объект
Вы в коде можете создать новый контейнер и заменить им старый?
мы сейчас о чем? код который я привел выше это спека для phpspec и с кодом самого контейнера или приложения она никак не связана.
Новый контейнер создать можно. Единственное что в рамках одного запроса — не нужно.
Новый контейнер создать можно. Единственное что в рамках одного запроса — не нужно.
Я про программирование, а вы про обработку запросов в PHP. Я его последний раз лет 10 назад читла, не в курсе что там у phpspec
Просто если можете заменить контейнер то это не singleton. А если не можете заменить, то это он самый.
Singleton (классический) это антипаттерн. Вот собственно и все. Все просто.
Просто если можете заменить контейнер то это не singleton. А если не можете заменить, то это он самый.
Singleton (классический) это антипаттерн. Вот собственно и все. Все просто.
Слишком много ООП!
Использование длинных классов, хотя нужна только малая часть класса
// тут длинный код на 1000-2000 строк
Жесть.
Да даже если ваша приложуха будет отвечать за 50 мс, то такой код держать нельзя.
Мне кажется вам надо срочно вот сюда codeclimate.com
А еще лучше, вот сюда refactoring.guru/ru/
Слушайте, так всё же просто и решается вполне типовыми методами. Используйте DI, следите за количеством зависимостей, не инстанцируйте там, где не надо — и готово. Это не столько оптимизация, сколько банальный рефакторинг.
Ещё можно перейти на версию PHP 5.5+, думаю тоже ощутимо было бы.
Поддержку комментаторов выше. Примеры 1-4, по-крайней мере в том виде, в котором вы их описали, — это следствие неправильного использования ООП, попробуйте посмотреть в сторону принципов SOLID.
Сегодняшний PHP не умеет загружать исходный код единожды и шарить его (скомпилированный) между разными обработчиками HTTP-запросов? Если умеет, то какие-то сомнительные пассы здесь приведены по большей части (они в любом случае сомнительные, но если таковы ограничения платформы, то что поделаешь).
Простите, я правильно понимаю что до этого вы не использовали APC совсем?
Нет, не правильно. APC был, сейчас Opcache.
Проблему описал в комментарии выше.
Как работает обработка пхп файла когда вы выполняете подобный код?
include «class.php»;
по шагам, утрированно:
1. читаем с диска
2. преобразуем в op-коды
3. выполняем оп-коды
Пункты 1-2 APC/Opcache делает 1 раз. но пункт 3 приходится делать каждый раз когда вы инклудите этот файл в рабочую область скрипта.
При этом, это происходит жаже если файл — просто описание класса, который никогда не будет выполнен, или из него будет взята только константа. Выполнение этого файла и добавление его в текущую описание занимает как CPU, так и память.
Проблему описал в комментарии выше.
Как работает обработка пхп файла когда вы выполняете подобный код?
include «class.php»;
по шагам, утрированно:
1. читаем с диска
2. преобразуем в op-коды
3. выполняем оп-коды
Пункты 1-2 APC/Opcache делает 1 раз. но пункт 3 приходится делать каждый раз когда вы инклудите этот файл в рабочую область скрипта.
При этом, это происходит жаже если файл — просто описание класса, который никогда не будет выполнен, или из него будет взята только константа. Выполнение этого файла и добавление его в текущую описание занимает как CPU, так и память.
require_once(...) попробуйте, или логика именно на инклюдах?
От замены include(_once) на require(_once) — ситуация не меняется, и использование памяти/cpu такое же.
В вашем комменте был include, без once…
Я ещё раз повторюсь что это не играет никакой роли в данной ситуации. Разница между include_once и include — только в том, что include_once не даст добавить в рабочую область скрипта один и тот же скрипт несколько раз. Но это в любом случае не получится, если вы используете классы — будет фатальная ошибка с тем что имя класса уже используется.
Такая же ситуация с require и require_once — в рамках данной статьи и примера выше — разницы никакой.
Такая же ситуация с require и require_once — в рамках данной статьи и примера выше — разницы никакой.
проблему решает переход на Python/Ruby/Node etc. Желательно с предзагрузкой кода в мастер-процесс. Ну или даже Go :)
очень сомнительное заявление. PHP не настолько медленнее, чтобы из-за этого переезжать на другой язык всей командой разработки. И на тормозящие на этих языках приложения я тоже насмотрелся.
Акжан, что-то тебя заминусили ) На самом деле тут работает принцип «коней на переправе не меняют». Часто смена платформы это долго дорого и неэффективно, приходится оптимизировать то что есть. А говнокод и на python/ruby тоже случается, особенно если некто считает что этот язык/платформа тупо быстрее PHP и можно делать что левой задней ноге вздумается.
После оптимизации мы максимально избавились от этих функций где возможно. Данные в файлах мы решили хранить в виде массива, сохранённого через var_export и загружать обратно через с помощью include/require. Таким образом мы смогли задействовать APC режим.Просто используйте igbinary.
К сожалению, для данных которые хранятся в memcache, данный подход не работает.
Это всё равно сериализация, которая всё равно есть CPU.
Загрузка конфига, который уже закэширован в виде опкода, сильно быстрее чем любая сериализация, бенчи это показывают.
Быстрее только бинарный слепок памяти массива, но такого в php пока нет, это к сожалению не C.
Загрузка конфига, который уже закэширован в виде опкода, сильно быстрее чем любая сериализация, бенчи это показывают.
Быстрее только бинарный слепок памяти массива, но такого в php пока нет, это к сожалению не C.
Вы так говорите, как будто загрузка опкода это не CPU.
Загрузка конфига, который уже закэширован в виде опкода, сильно быстрее чем любая сериализация, бенчи это показывают.Буду признателен на ссылку на замеры.
Самому стало интересно, и не нашёл ни одного теста где сравниваются:
1. serialize
2. igbinary
3. var_export + include
4. var_export + include с opcache
если брать первые 3 пункта, то во всех тестах что видел — побеждает igbinary.
Что на самом деле странно, так как можно было бы подумать что должен побеждать include файла.
Пора проводить новые тесты :) на пхп 5.5 с opcache включённым.
1. serialize
2. igbinary
3. var_export + include
4. var_export + include с opcache
если брать первые 3 пункта, то во всех тестах что видел — побеждает igbinary.
Что на самом деле странно, так как можно было бы подумать что должен побеждать include файла.
Пора проводить новые тесты :) на пхп 5.5 с opcache включённым.
Что уж странного? Более простой и специализированный интерпретатор должен работать быстрее.
Когда-то я делал alekciy.livejournal.com/10826.html что собственно и определило лично для меня использование igbinary как стандартного сериализатора данных. Минус, точнее неудобство, только одно. Нельзя глазами заглянуть в результат сериализации и посмотреть, что там. Бывало нужно, хотя и крайне редко.
Советы довольно интересные, спасибо.
Расскажите и про xhProf, нужная тема.
Расскажите и про xhProf, нужная тема.
Вы утверждаете в статье, что чисто загрузка 12Мб кода из APC опкод кеша у вас занимало больше 300мс? У вас точно не было тяжёлой инициализации с запросами в БД, криво настроенного APC (размер кеша, проверка mtime на каждый запрос etc), тяжёлого автолоадера с просмотром файловой системы и прочей связанной печали? Потому как такого порядка потребление CPU фантастическое и больше опытного на порядок.
Конечно же есть запросы к БД, к мемкеш и тп. Их в данный момент не меняли — т.е. график показывает только изменение при вышеуказанной оптимизации… А оптимизация конечно идёт по всем фронтам. В данной статье представлен только один из них.
Проблема в том, что кмк вы исправляете последствие проблемы, а не причину. PHP очень эффективно работает с опкод кешем (особенно opcache), и ломать логику приложения (см. примеры 1-3) в этом случае — бессмысленная трата времени.
Вы пробовали провести чистый бенчмарк данной проблемы, без вашего кода?
Вы пробовали провести чистый бенчмарк данной проблемы, без вашего кода?
Почитайте, пожалуйста, мои комментарии в данной теме. В любом случае подключение лишнего кода в «рабочую область процесса» — замедляет общее выполнение процесса. Opcache уменьшает проблему, но не избавляет от неё полностью: вам всё равно надо выделять память на «структуру класса», загрузку массива, тратить CPU на всё это, плюс на выполнение опкодов из opcache.
Как раз таки примеры 1-3 это примеры того, как можно небольшими усилиями, исправить ситуацию в архитектуре приложения, не сильно меняя саму архитектуру.
Как раз таки примеры 1-3 это примеры того, как можно небольшими усилиями, исправить ситуацию в архитектуре приложения, не сильно меняя саму архитектуру.
Поддерживаю. Данное поведение более характерно для промаха кеша.
@Для автора:
* Предположим у вас opcode cache выставлен на 64 МиБ, а занято 20 МиБ. Значит ли это что кеша вам хватает? Вовсе нет, он может быть сильно фрагментирован и большие файлы в него не попадают и вызывают промах кеша. И в этой ситуации конечно же ваша оптимизация спасает. но проще увеличить память.
* Я тут когда писал пост. Посмотрите картинку вначале и выводы в конце.
@Для автора:
* Предположим у вас opcode cache выставлен на 64 МиБ, а занято 20 МиБ. Значит ли это что кеша вам хватает? Вовсе нет, он может быть сильно фрагментирован и большие файлы в него не попадают и вызывают промах кеша. И в этой ситуации конечно же ваша оптимизация спасает. но проще увеличить память.
* Я тут когда писал пост. Посмотрите картинку вначале и выводы в конце.
в тему снижения потребления памяти просится уменьшение времени жизни объектов, но сработает далеко не каждом коде. То есть если объект создается в начале запроса, а первое использование — где то в конце, то он все это время жрет память. Умножаем время жизни на число одновременных запросов — получаем масштаб бедствия. Переносим создание объекта поближе к его первому использованию, уменьшаем время*объем используемой памяти.
Повторюсь, сработает далеко не везде, но вот на эту тему было бы действительно интересно посмотреть.
Повторюсь, сработает далеко не везде, но вот на эту тему было бы действительно интересно посмотреть.
Переносим создание объекта поближе к его первому использованию, уменьшаем время*объем используемой памяти.
Для этого и придумали IoC контейнеры, которые берут на себя всю рутину по созданию экземляров классов на себя и инициализируют их только по требованию. Продвинутые IoC контейнеры даже могут обернуть автоматически ваши классы в проки для инициализации только если вы начали их использовать. Так же некоторые умеют компилировать контейнер за счет чего, при наличии опкэша, оверхэда от их использования практически не ощущается.
>>Данные в файлах мы решили хранить в виде массива, сохранённого через var_export
Абсолютно верно, я так делаю уже лет 10. Это надо крупными буквами писать везде, где идёт описание функций serialize или .ini, что не надо их использовать где попало. Особенно умиляли ресурсоёмкие парсинги ini файлов или конфигов xml, вот это изврат.
Да, жаль что в APC/memcache нельзя положить и достать слепок массива как есть, без serialize и без var_export. Во всяких новомодных hhvm/hack/phpng такой возможности так и не появилось?
Абсолютно верно, я так делаю уже лет 10. Это надо крупными буквами писать везде, где идёт описание функций serialize или .ini, что не надо их использовать где попало. Особенно умиляли ресурсоёмкие парсинги ini файлов или конфигов xml, вот это изврат.
Да, жаль что в APC/memcache нельзя положить и достать слепок массива как есть, без serialize и без var_export. Во всяких новомодных hhvm/hack/phpng такой возможности так и не появилось?
Кроме xhprof порекомендую ещё blackfire.io, очень удобно и наглядно
Интересно совпали цвета на втором графике )
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Нестандартная оптимизация проектов на PHP