Нет, не правильно. APC был, сейчас Opcache.
Проблему описал в комментарии выше.
Как работает обработка пхп файла когда вы выполняете подобный код?
include «class.php»;
по шагам, утрированно:
1. читаем с диска
2. преобразуем в op-коды
3. выполняем оп-коды
Пункты 1-2 APC/Opcache делает 1 раз. но пункт 3 приходится делать каждый раз когда вы инклудите этот файл в рабочую область скрипта.
При этом, это происходит жаже если файл — просто описание класса, который никогда не будет выполнен, или из него будет взята только константа. Выполнение этого файла и добавление его в текущую описание занимает как CPU, так и память.
Рельсы — всё же не PHP. В питоне тоже нет подобной проблемы, насколько я знаю.
В PHP же проблема что сервер умеет кешировать код, но при этом, ему приходится загрузить этот кешированный файл в рабочую область текущего запроса. И на это уходит полезный ресурс — память и соответственно время
> Тут больше не потребление памяти наверное играло роль, а то что все грузилось в рамках одного запроса, даже то что не должно.
Да, проблему можно сократить и до этого.
Крутилось всё на пхп 5.3, с APC. Обновили до пхп 5.5 с opcache — количество длинных запросов сократилось ещё в 2 раза. При этом количество запросов обрабатываемых на том же железе — увеличилось. (т.е. на том же железе — стало всё быстрее, и при этом нужно меньше железа для обработки тех же данных).
При этом, мы конечно сравнивали ситуации на машине с PHP 5.5+ opcache, но с неоптимизированным кодом и с оптимизированным кодом — разница заметна на глаз была.
Хорошо. Пока думаю на тему — какой проект для этого использовать. Тут нужен реальный проект для примера, но при этом — не могу использовать свой рабочий проект.
В добавок — проект не должен быть слишком сложный, иначе примеры будут слишком сложнопонимаемые :)
Именно поэтому я не хотел обращать внимание на профайлинг mysql запросов. Подобный профайлинг описан во большом количестве мест, и писать о нём ещё раз — не интересно :)
Самые главные мысли которые я хотел донести:
1. Показать необычный кейс, о котором многие разработчики даже не задумываются, и возможно помочь кому либо оптимизировать свой код.
1. Нужно внимательно анализировать даже на те вещи, которые маловероятны.
2. Соблюдение всех ООП практик по разделению кода на классы — может повлиять негативно в плане использования памяти. Есть большая вероятность что процессору придётся обрабатывать ненужные вещи. (тут конечно можно поспорить на тему «что такое лучшие ООП практики»)
Проблему описал в комментарии выше.
Как работает обработка пхп файла когда вы выполняете подобный код?
include «class.php»;
по шагам, утрированно:
1. читаем с диска
2. преобразуем в op-коды
3. выполняем оп-коды
Пункты 1-2 APC/Opcache делает 1 раз. но пункт 3 приходится делать каждый раз когда вы инклудите этот файл в рабочую область скрипта.
При этом, это происходит жаже если файл — просто описание класса, который никогда не будет выполнен, или из него будет взята только константа. Выполнение этого файла и добавление его в текущую описание занимает как CPU, так и память.
В PHP же проблема что сервер умеет кешировать код, но при этом, ему приходится загрузить этот кешированный файл в рабочую область текущего запроса. И на это уходит полезный ресурс — память и соответственно время
Да, проблему можно сократить и до этого.
Крутилось всё на пхп 5.3, с APC. Обновили до пхп 5.5 с opcache — количество длинных запросов сократилось ещё в 2 раза. При этом количество запросов обрабатываемых на том же железе — увеличилось. (т.е. на том же железе — стало всё быстрее, и при этом нужно меньше железа для обработки тех же данных).
При этом, мы конечно сравнивали ситуации на машине с PHP 5.5+ opcache, но с неоптимизированным кодом и с оптимизированным кодом — разница заметна на глаз была.
В добавок — проект не должен быть слишком сложный, иначе примеры будут слишком сложнопонимаемые :)
Самые главные мысли которые я хотел донести:
1. Показать необычный кейс, о котором многие разработчики даже не задумываются, и возможно помочь кому либо оптимизировать свой код.
1. Нужно внимательно анализировать даже на те вещи, которые маловероятны.
2. Соблюдение всех ООП практик по разделению кода на классы — может повлиять негативно в плане использования памяти. Есть большая вероятность что процессору придётся обрабатывать ненужные вещи. (тут конечно можно поспорить на тему «что такое лучшие ООП практики»)