Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > PHP: Для профи > Оптимизация потребления памяти

Автор: Alex13 7.12.2008, 18:34

Задача такая: есть большой скрипт (форум). Памяти он потребляет от 4 до 6 мб на страницу. Необходимо это число сократить до приемлемых размеров. Есть ли какой-то способ определить, что именно занимает память, какие переменные или ресурсы? Пока не придумал ничего лучшего, чем с помощью get_defined_vars() получить список переменных и пересмотреть их, но особого результата это не дало - общий размер полученных таким образом переменных значительно меньше потребляемой памяти. Пересматривать и анализировать весь код вручную тоже не представляется возможным - это там около 3 Мб.

Автор: Vreden 8.12.2008, 21:45

Пых файл не должен весить 3мб, макс 100кб потом дробить, код по ходу дела заведомо прожорливый, тут только оптимизация, я не представляю как можно оптимизировать файл 3мб. Ещё вариант: ООП

Автор: skyboy 9.12.2008, 00:25

Цитата(Alex13 @  7.12.2008,  17:34 ) что именно занимает память, какие переменные или ресурсы? не знаю таких методов. однако, могу предположить, что используется буфферизированные запросы к БД(mysql_query или подобные) с большим количеством выбираемых данных. Или несколько результатов запросов храняться одновременно. Также возможно создание графического ресурса с большим разрешением(впрочем, для форума - маловероятно). навряд ли можно оптимизировать без знания структуры, логики и кода самого кода.

Автор: Alex13 9.12.2008, 15:29

Vreden, 3 мб - общий вес. Файлов там не меньше полусотни. Цитата(skyboy @  9.12.2008,  04:25 ) однако, могу предположить, что используется буфферизированные запросы к БД(mysql_query или подобные) с большим количеством выбираемых данных. Или несколько результатов запросов храняться одновременно. Скорее всего, корень зла где-то здесь. Насколько я заметил, ресурсы там освобождаются далеко не всегда. Сейчас как раз занимаюсь настройкой XDebug, чтобы как-то отследить где именно съедаются ресурсы.

Автор: Wolf1994 9.12.2008, 16:59

Цитата(Vreden @  8.12.2008,  21:45 ) Пых файл не должен весить 3мб, макс 100кб потом дробить, Это влияет на читабельность кода или на скорость его выполнения / потребляемые ресурсы? Имеет ли смысл, скажем, делить файл размером 120 кб на 2 по 60, при условии, что выполнятся при одном обращении будет только один из этих файлов (то есть либо include "1.php", либо "2.php")? Прошу прощения за оффтоп. Просто интересует этот вопрос.

Автор: Alex13 9.12.2008, 17:07

Wolf1994, это влияет на скорость загрузки скрипта в память и его трансляции. Думаю, в вашем случае стоит разбить файл на два.

Автор: Wolf1994 9.12.2008, 17:40

Alex13, спасибо за ответ.

Автор: ksnk 9.12.2008, 17:42

Wolf1994, imho, для файлов <100кб, преимущественно на читабельность. Хотя при наличии Code Explorer'а читабельность сильно не страдает. В Eclips'е все классы выстраиваются в такое-же примерно дерево что для одного файла, что для кучки... Ну и в конце концов есть "правила хорошего тона" - один класс в одном файле.   Если файл больше 100кб  - начинают уже играть скорость трансляции и скорость чтения с диска.

Автор: youri 12.12.2008, 02:30

единственный вариант, который я вижу - следить за объемом памяти потребляемой скриптом, т.е. скрипт должен быть в отдельном процессе можно запускать скрипт в командной строке и вставлять бесконечный цикл, сначала посередине, потом двигать куда-нибудь и смотреть при этом на объем потребляемой процессом памяти можно поставить Zend Core, Zend Platform и Zend Studio. При этом никакой цикл никуда двигать не нужно будет. При запуске через внутренний отладчик будет создаваться отдельный процесс php.exe, при удаленной отладке - расти будет один из процессов php-cgi.exe

Автор: Endeveit 12.12.2008, 06:10

По-поводу того стоит ли хранить код в одном файле или в нескольких сказать сразу нельзя. Тут есть множество нюансов. А по сабжу верное решение нашел сам топикстартер – xdebug, все остальное ерунда. Для профилирования запросов MySQL советую включить лог медленных запросов и лог запросов, не использующих индексы. Цитата(Alex13 @  9.12.2008,  16:29 ) 3 мб - общий вес. Файлов там не меньше полусотни. Кстати, если не установлено никаких оптимизаторов PHP, то может иметь смысл слить всю эту кучку файлов в один, тем самым избавившись от лишних дисковых операций. Но это, опять же, сугубо личная ситуация каждого проекта.

Автор: youri 12.12.2008, 10:48

Цитата(Endeveit @  12.12.2008,  06:10 ) По-поводу того стоит ли хранить код в одном файле или в нескольких сказать сразу нельзя. Тут есть множество нюансов. хранить код надо так, чтобы его было удобно читать (Правило Экономии: Время программиста дорого; сократите его, используя машинное время., http://ru.wikipedia.org/wiki/Философия_Unix#.D0.A0.D0.B5.D0.B9.D0.BC.D0.BE.D0.BD.D0.B4:_.D0.98.D1.81.D0.BA.D1.83.D1.81.D1.81.D1.82.D0.B2.D0.BE_.D0.BF.D1.80.D0.BE.D0.B3.D1.80.D0.B0.D0.BC.D0.BC.D0.B8.D1.80.D0.BE.D0.B2.D0.B0.D0.BD.D0.B8.D1.8F_.D0.B2_UNIX), экономить на количестве файлов надо в редких случаях (http://ru.wikipedia.org/wiki/Философия_Unix#.D0.9F.D0.B0.D0.B9.D0.BA:_.D0.A1.D1.82.D0.B8.D0.BB.D1.8C_.D0.BF.D1.80.D0.BE.D0.B3.D1.80.D0.B0.D0.BC.D0.BC.D0.B8.D1.80.D0.BE.D0.B2.D0.B0.D0.BD.D0.B8.D1.8F_.D0.BD.D0.B0_C) Цитата А по сабжу верное решение нашел сам топикстартер – xdebug, все остальное ерунда. Для профилирования запросов MySQL советую включить лог медленных запросов и лог запросов, не использующих индексы. ну для начала я бы действительно поискал большой и медленный запрос (с помощью соответствующего лога)

Автор: Endeveit 12.12.2008, 14:11

youri, прочитайте последние две строчки моего предыдущего сообщения.

Автор: youri 12.12.2008, 14:34

Цитата(Endeveit @  12.12.2008,  06:10 ) Кстати, если не установлено никаких оптимизаторов PHP, то может иметь смысл слить всю эту кучку файлов в один, тем самым избавившись от лишних дисковых операций.Но это, опять же, сугубо личная ситуация каждого проекта. эти что ли? Я их читал уже  Во-первых у человека проблема не со скоростью, а с объемом потребляемой памяти, во-вторых прочитайте http://ru.wikipedia.org/wiki/Философия_Unix#.D0.9F.D0.B0.D0.B9.D0.BA:_.D0.A1.D1.82.D0.B8.D0.BB.D1.8C_.D0.BF.D1.80.D0.BE.D0.B3.D1.80.D0.B0.D0.BC.D0.BC.D0.B8.D1.80.D0.BE.D0.B2.D0.B0.D0.BD.D0.B8.D1.8F_.D0.BD.D0.B0_C хотя, возможно, бывают проекты, которым это может помочь, но думаю это редкость

Автор: Endeveit 12.12.2008, 14:44

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

Автор: Alex13 12.12.2008, 18:24

Что касается SQL запросов - их я оптимизировал в первую очередь. Скорость выполнения так же довел до приемлемой. А вот потребление памяти - это проблема. Пока смог выиграть только порядка мегабайта путем отключения инклудов там, где подключаемые файлы по факту не используются, но 4,5 мб - все равно много. Так что вот сижу, анализирую трейсы xdebug и ищу врагов.

Автор: ksnk 14.12.2008, 20:51

Alex13, Есть такая http://dklab.ru/chicken/nablas/49.html у Котерова - "Пара слов в пользу eAccelerator"...Возможно, пригодится...

Автор: Alex13 15.12.2008, 12:42

ksnk, спасибо, я ее уже давно читал. Проблема-то как раз не в скорости, а в памяти. eAccelerator потребляет довольно много памяти для кеширования байт-кода, а ее как раз недостаток.

Автор: MuToGeN 16.12.2008, 17:38

Если под рукой есть рут от сервера, где это крутится, то в плане экономии памяти в гораздо большей степени может помочь поднять систему на 2хуровневой архитектуре с nginx на морде и внутренним тяжелым апачем, и не трогать форум - как жрал по 4-6 метров, так и будет жрать, и чорт бы с ним, что жрет - для более-менее серьезных скриптов такие цифры скорее даже слишком низкие. А свободная оператива значительно увеличится. Это, как-бы, конечно офтоп, просто немного иной и чаще всего гораздо более легкий подход к оптимизации веб-систем.

Автор: Alex13 16.12.2008, 17:44

рута, к сожалению пока нет, но этот вариант, наверное стоит обдумать, еще раз спасибо

Автор: youri 16.12.2008, 17:56

Цитата(MuToGeN @  16.12.2008,  17:38 ) А свободная оператива значительно увеличится. а за счет чего?

Автор: MuToGeN 16.12.2008, 23:32

youri, прежде всего за счет того, что ради CSSины или картинки весом меньше чем в килобайт не надо запускать еще один тяжеловесный процесс (тобишь, форкать апача и подцеплять к нему все модули). Этим будет заниматься легковесный сервер типа nginx или zerowait. Апач будет заниматься только динамикой. Вообще это в мануалах по битриксу было описано наиболее доступным языком, буквально "на пальцах", советую поискать там.

Автор: youri 17.12.2008, 02:23

Alex13, судя по тому, что ты пытаешься переопределить стандартные функции, xdebug не помог. А чем тогда мой совет не подходит? студию допустим не быстро ставить, но запускать страничку из консоли, перемещая по ней бесконечный цикл и наблюдая за размером процесса, проще.  Возможно поставив цикл где-нибудь в начале ты выяснишь, что память расходуется на подключаемые файлы, иначе стоит искать причину в запросах к бд или работе с графикой, как уже говорили люди P.S. Хотя твоей идеи я пока не понимаю, или я ошибаюсь в том, что переопределение стандартных функций тебе понадобилось для оптимизации памяти

Автор: Alex13 17.12.2008, 10:19

youri, xdebug помог. Более того, я уже практически закончил  А переопределение мне требовалось для других нужд и совершенно другого проекта.

Автор: youri 17.12.2008, 10:32

тогда отлично  а на что тратилось много памяти?

Автор: Alex13 17.12.2008, 10:39

На все понемногу. Больше всего съедали инклуды и выборочно отключив некоторые из них кое-где удалось выиграть до трех мегабайт. Плюс кеширование некоторых тяжелых операций.

Автор: sTa1kEr 23.12.2008, 19:57

Цитата(Alex13 @  15.12.2008,  13:42 ) eAccelerator потребляет довольно много памяти для кеширования байт-кода, а ее как раз недостаток. Во первых, eAccelerator может хранить байткод на диске, а во вторых он наоборот значительно экономит память как-раз на инклюдах. И еще не забывайте про экстеншены PHP - они тоже жрут порядочно памяти.

Автор: MuToGeN 23.12.2008, 23:22

Цитата(sTa1kEr @  23.12.2008,  19:57 ) И еще не забывайте про экстеншены PHP Еще модули веб-сервера в ту же кучу. Тем более что при дефолтных конфигах того же апача половина из них зачастую вообще не используется. Просто зачем-то жрет память.

Автор: realPROme 24.12.2008, 01:59

Цитата(Alex13 @  17.12.2008,  10:39 ) Больше всего съедали инклуды только открыл тему, хотел сказать, сам на днях столкнулся с таком странной ситуацией, когда инклуд 40кб файла, в котором просто содержались необходимые функции, больше ничего, за одним только фактом инклуда сжирал 2мб памяти... причины этого мне до конца так и не ясны...

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)