Перейти к содержанию
toporchillo

Ускорение OpenCart. Профилирование PHP

Рекомендуемые сообщения

На одном работающем сайта OpenCart сильно грузил CPU, провел я профилирование, вот такие занятные результаты:

post-16755-0-04014300-1390304484_thumb.png

 

В данном случае в кэше около 100000 файлов. Кэш не ускорил, а поставил все колом. Чей там модуль фильтра любит кэшировать?

 

Я не уверен, но кажется когда в папке очень много файлов, то файловая система начинает тормозить жутко. Как раз такой случай?

 

Второе узкое место - SeoPro. Действительно метод rewrite уж очень тяжелый, а всего лишь формирует укороченный URL.

 

Эти два места в OpenCart стоит переделать.

 

 

А на том сайте банально отключил кэш (не удалил, а игнорирую его существование), и все ускорилось в разы

  • +1 2

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Попробуй GLOB_NOSORT добавить. У меня не было возможности потестировать на больших кешах.

https://github.com/rb2/opencart/commit/6d98f4362c9f02ddae3d21feb57aca04ab433729

Это не панацея, но способно сильно ускорить процесс (в разы, насколько помню).

Хотелось бы реальные цифры увидеть, раз уж тестовая площадка есть под рукой.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

checkMatch (вкмодовский) - вот его бы обойти, смотрю он погоду неплохую делает. Если уж кеша и так с лишком хватает, то заинклудить бы все изменения, и деинстальнуть.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

checkMatch (вкмодовский) - вот его бы обойти, смотрю он погоду неплохую делает. Если уж кеша и так с лишком хватает, то заинклудить бы все изменения, и деинстальнуть.

С vQmod наверно совсем надо другой подход придумать: устанавливать их из админки по кнопке, с принятием изменений в коде и бэкапом измененных файлов. Все эти изменения на лету - фигня какая-то. Получается какой-то git уже.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

С vQmod наверно совсем надо другой подход придумать: устанавливать их из админки по кнопке, с принятием изменений в коде и бэкапом измененных файлов. Все эти изменения на лету - фигня какая-то. Получается какой-то git уже.

Алгоритм толковый, только вот довести это дело до финального конца какого то, что б грамотно прописывалось, как то у меня не получается, помнится Фрилансер интересовался данным вопросом тоже... Но... тут камень преткновения в селекторах, нет универсального кода, особенно если шаблонов это касается...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

С vQmod наверно совсем надо другой подход придумать: устанавливать их из админки по кнопке, с принятием изменений в коде и бэкапом измененных файлов. Все эти изменения на лету - фигня какая-то.

Так есть ведь. Готовый инструмент. Понимающий к тому же vQmod XML, насколько помню описание.

См. Safepatch - альтернатива vQmod

А ещё я когда-то давно предлагал разработчикам класть простой нормальный .diff рядом со своими модулями - но что-то никто ни сном, ни духом. Жалко, что ли? Пыжатся, делают этот долбаный vQmod руками - а потом бери и обратно из этого XML изменения вытягивай. Вместо того, чтобы взять обычный патч и воспользоваться.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Так есть ведь. Готовый инструмент. Понимающий к тому же vQmod XML, насколько помню описание.

См. Safepatch - альтернатива vQmod

А ещё я когда-то давно предлагал разработчикам класть простой нормальный .diff рядом со своими модулями - но что-то никто ни сном, ни духом. Жалко, что ли? Пыжатся, делают этот долбаный vQmod руками - а потом бери и обратно из этого XML изменения вытягивай. Вместо того, чтобы взять обычный патч и воспользоваться.

Осталось только конвертер из vQmod в .diff сделать.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Осталось только конвертер из vQmod в .diff сделать.

Зачем?

Имеющиеся вкумоды можно накладывать или вкумодом или Safepatch-ем.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Можно использовать подобный метод для переписи, только до конца алгоритм не продуман:

private function writefile($filename, $pattern, $replace, $repeat) {				$real_filename = realpath($filename);				$content = $original_content = file_get_contents($real_filename);		if($content === FALSE) {			$this->error['warning'] = sprintf($this->language->get('error_notopen'),$filename);			return;		}				if($repeat){			$content = str_replace('// my_comment' , '', $content);					if($content !== $original_content){				return;			}		}					$content = str_replace($pattern, $replace, $content);						if($content === NULL) {			$this->error['warning'] = sprintf($this->language->get('error_regex'),$pattern);			return;		}						if($content !== $original_content) {							if(!is_writeable($real_filename)) {				$this->error['warning'] = sprintf($this->language->get('error_notwrite'),$filename);				return;			} else {									$result = file_put_contents($real_filename, $content);				if($result) {					return;				} else {					$this->error['warning'] = sprintf($this->language->get('error_writefail'),$filename);					return;				}			}		}	}

а сама функция перезаписи, примерно такого вида (сперва спарсив сам vqmod):

public function vqToPhp(){	$this->writefile('../catalog/model/catalog/category.php', 'return $query->row;', '// my_commentreturn $query->rows;', 0);			}

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Померил влияние влияние кэша, заваленного файлами (100 тысяч штук) на производительность, вот для сравнения цифры:

1. Файловый кэш, попаданий в кэш не было:

Overall Summary	
Total Incl. Wall Time (microsec):	14,173,002 microsecs
Total Incl. CPU (microsecs):	12,540,093 microsecs
Total Incl. MemUse (bytes):	11,238,232 bytes
Total Incl. PeakMemUse (bytes):	11,565,304 bytes
Number of Function Calls:	60,487

2. Файловый кэш, все берется из кэша:

Overall Summary	
Total Incl. Wall Time (microsec):	8,406,150 microsecs
Total Incl. CPU (microsecs):	3,943,401 microsecs
Total Incl. MemUse (bytes):	11,222,544 bytes
Total Incl. PeakMemUse (bytes):	11,549,632 bytes
Number of Function Calls:	58,137

3. Кэш отключен:

Overall Summary	
Total Incl. Wall Time (microsec):	427,090 microsecs
Total Incl. CPU (microsecs):	207,968 microsecs
Total Incl. MemUse (bytes):	11,206,472 bytes
Total Incl. PeakMemUse (bytes):	11,534,760 bytes
Number of Function Calls:	60,224

Вывод: замусоренный файловый кэш хуже, чем совсем без кэша. Проверьте свои модули, что они пишут в кэш?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

В качестве альтернативы файловому кэшу предлагаю использовать кэш в базе данных. В приложенных файлах замена cache.php. Для хранения кэша используется таблица, которая создается sql-скриптом:

CREATE TABLE `cache` (
`key` VARCHAR( 50 ) NOT NULL ,
`data` LONGTEXT NOT NULL ,
`expiry` INT NOT NULL ,
PRIMARY KEY ( `key` )
) ENGINE = MYISAM ;

Тестирование производительности:

Overall Summary	
Total Incl. Wall Time (microsec):	318,256 microsecs
Total Incl. CPU (microsecs):	180,973 microsecs
Total Incl. MemUse (bytes):	11,207,832 bytes
Total Incl. PeakMemUse (bytes):	11,534,992 bytes
Number of Function Calls:	59,671

Поглядим, как поведет себя кэш в базе, когда таблица разрастется.

cache.php

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

В качестве альтернативы файловому кэшу предлагаю использовать кэш в базе данных. В приложенных файлах замена cache.php. Для хранения кэша используется таблица, которая создается sql-скриптом:

нет инвалидации кеша

на большинстве хостингов стоит ограничение на работу с базой, например 50cp(хз, что это, цифровые попугаи). часто сталкивался

 

из файла читать быстрее чем из базы, но проблема возникает когда этих файлов кеша очень много

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

нет инвалидации кеша

на большинстве хостингов стоит ограничение на работу с базой, например 50cp(хз, что это, цифровые попугаи). часто сталкивался

 

из файла читать быстрее чем из базы, но проблема возникает когда этих файлов кеша очень много

			if ($row['expiry'] >= time()) { //Проверка на протухание кэша
				return unserialize($row['data']);
			}
			else {
				$this->delete($key); //Не это ли инвалидация?
			}

Я знаю, что на хостингах у базы есть ограничения. Кэш можно было бы хранить например в Redis или mongoDB, кабы они были.

 

Из файла читать действительно быстрее, но вот эта штука:

		$files = glob(DIR_CACHE . 'cache.' . preg_replace('/[^A-Z0-9\._-]/i', '', $key) . '.*');

- поиск файла в замусоренной папке оказывается медленнее, чем доступ к строке таблицы по ее индексу.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

С vQmod наверно совсем надо другой подход придумать: устанавливать их из админки по кнопке, с принятием изменений в коде и бэкапом измененных файлов. Все эти изменения на лету - фигня какая-то. Получается какой-то git уже.

Решение можно позаимствовать у Мадженто. Там имеется развитый кэш манагер, в котором выполняется много разных функций, в том числе и принудительная перекомпиляция разных фрагментов кода, перестроение кэша изображений товаров и категорий и т.п. В этом интерфейсе с 10 позиций. Там нет vQmod но суть та же самая.

И еще в движках, рассчитанных на большую номенклатуру товаров и большой объем изображений, вроде Prestashop или Magento, кэш изображений строиться как много многоуровневая папка. В той же Престе например подкаталоги в кэше изображения формируются дроблением ID товара, к которому привязаны изображения (например для изображений товара с кодом 1234 в кэше изображений будут сформирован подкаталог типа http://site.ru/img/p/1/2/). Да и файловое кэширование у них построено так же (в Престе например дробится хэш используемый для формирования имени файла).

Изменено пользователем EVMedvedev

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Вывод: замусоренный файловый кэш хуже, чем совсем без кэша. Проверьте свои модули, что они пишут в кэш?

Файловая система становится менее эффективной, чем база, когда там чересчур много файлов в одной папке. Давно известный факт. Первый способ существенно улучшить производительность малыми переделками - добавить GLOB_NOSORT (я не увидел результатов - сложно что ли проверить?). Второй - разнести файлы кеша по подпапкам (первым одному или двум символам хэша, к примеру).

Перенос кеша в базу - тупиковый путь, мне кажется.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Файловая система становится менее эффективной, чем база, когда там чересчур много файлов в одной папке. Давно известный факт. Первый способ существенно улучшить производительность малыми переделками - добавить GLOB_NOSORT (я не увидел результатов - сложно что ли проверить?). Второй - разнести файлы кеша по подпапкам (первым одному или двум символам хэша, к примеру).

Перенос кеша в базу - тупиковый путь, мне кажется.

Тестируйте свои идеи самостоятельно, или обращайтесь в ixbt. А я буду говорить "мне кажется...", "давно известно...". Кто тут ocTeam?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

так же за кеш на диске, разбитый на подкаталоги, а не в базе

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

А вот кое-кто уже протестировал кэшеры:

http://www.balancer.ru/tech/forum/2011/05/t82115--testy-proizvoditelnost-raznykh-mekhanizmov-keshirovaniya-v-p.7369.html

 

Истину выявляют голосованием, как это мило :-)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Тестируйте свои идеи самостоятельно, или обращайтесь в ixbt. А я буду говорить "мне кажется...", "давно известно...". Кто тут ocTeam?

Ок. Но всё же поясню.

Я проверял, но на меньших количествах.

У Вас увидел готовую базу с хорошими объёмами, плюс готовую и настроенную среду -- и потроха опенкарта, и профайлер. Изменить 4 строчки и записать один раз цифры - мне показалось, что будет проще попросить, чем бросать всю свою работу и заниматься опенкартом.

Почему я в ocTeam - для меня самого загадка. Хотя я и не против. Я не знаю. Возможно, потому, что когда-то что-то делал по мелочам для проекта и могу (или мог) быть ему полезен. Я такой же пользователь и разработчик Опенкарт, как и вы, может разве что с немного большим кол-вом организационной попоболи (к той, к которой имею доступ), и которой ещё изредка занимаюсь, отдавая часть времени сообществу.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

К стати, у MySQL оказывается есть интерфейс доступа через так называемый Handle Socket http://habrahabr.ru/post/113040/

- это ответ Оракла модным NoSQL-базам (Монго, Редис, Коуч). Обещают быстрый доступ по индексам.

Можно таки денормализовать критические таблицы (товары) и читать данные о товаре по индексам.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Истину выявляют голосованием, как это мило :-)

есть базовые понятия.

последовательное чтение данных с диска быстрее mysql, если эти данные не в оперативной памяти. memcached на порядок быстрее диска и базы

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

А вот кое-кто уже протестировал кэшеры:

http://www.balancer.ru/tech/forum/2011/05/t82115--testy-proizvoditelnost-raznykh-mekhanizmov-keshirovaniya-v-p.7369.html

 

Истину выявляют голосованием, как это мило :-)

 

Ну я лично полагаю, что разработчики той же Magento люди довольно опытные и не глупые, а так же имеющие богатую экспериментальную базу по использованию их детища в том числе в очень больших проектах, вроде lamoda.ru. Так что если они используют файловое кэширование и очень активно, значит это дает свой положительный эффект. Я верю в то, что "Умный учится на своих ошибках, мудрый на чужих, а дурак ни чему не учится." :-).

Да и данные в ссылочке тухлецой могут попахивать с 2011 года. Вам не кажется :-)?

Изменено пользователем EVMedvedev

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Ну я лично полагаю, что разработчики той же Magento люди довольно опытные и не глупые, а так же имеющие богатую экспериментальную базу по использованию их детища в том числе в очень больших проектах, вроде lamoda.ru. Так что если они используют файловое кэширование и очень активно, значит это дает свой положительный эффект. Я верю в то, что "Умный учится на своих ошибках, мудрый на чужих, а дурак ни чему не учится." :-).

Да и данные в ссылочке тухлецой могут попахивать с 2011 года. Вам не кажется :-)?

Что касается Мадженты, то кто копался в ее коде и делал для нее плагины, тот знает, что это за ад. Зато много свистков и перделок.

 

Не думаю, что Redis или MySQL так сильно шагнули назад в плане производительности. Ну если только SSD все себе поставили и файловые системы стали быстрее.

 

Мне надоело спорить. Если реальные тесты для вас не показатель, а все решает догма, что "файловая система быстрее", то мне нечего добавить к этой теме.

  • +1 1

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Для публикации сообщений создайте учётную запись или авторизуйтесь

Вы должны быть пользователем, чтобы оставить комментарий

Создать учетную запись

Зарегистрируйте новую учётную запись в нашем сообществе. Это очень просто!

Регистрация нового пользователя

Войти

Уже есть аккаунт? Войти в систему.

Войти

  • Последние посетители   0 пользователей онлайн

    Ни одного зарегистрированного пользователя не просматривает данную страницу

×

Важная информация

На нашем сайте используются файлы cookie и происходит обработка некоторых персональных данных пользователей, чтобы улучшить пользовательский интерфейс. Чтобы узнать для чего и какие персональные данные мы обрабатываем перейдите по ссылке. Если Вы нажмете «Я даю согласие», это означает, что Вы понимаете и принимаете все условия, указанные в этом Уведомлении о Конфиденциальности.