Помогите разобраться с логом Mysql

[ArtemPitov]

Артем подскажите пожалуйста как это можно сделать. Количество товара отключено, а вот с категориями не могу разобраться.

Настройки магазина -> Количество товаров в подкатегории: нет

[ArtemPitov]

Да чего мелочиться - давайте кешировать готовые страницы. :-)

Это кусок из модифицированного мной кеша, там все раскладывается по папочкам, и совершенно не напрягает. К тому же все единообразно: на входе метода модели проверили кеш, далее запросили, на выходе сохранили.

Кешыть не всегда нужно и всегда хорошо

[sharman35]

Настройки магазина -> Количество товаров в подкатегории: нет

именно так и стоит. по другому не было.

[chukcha]

Цитата DISTINCT преобразовывается к GROUP BY для всех столбцов, для DISTINCT в сочетании с ORDER BY, помимо этого, во многих случаях также требуется временная таблица.

Вот-вот.

А это дополнительные расходы для ОДНОЙ записи.

[ArtemPitov]

именно так и стоит. по другому не было.

тут уже нужно смотреть сколько товаров и что тормозит систему 

[chukcha]

db_log в поощь

[sharman35]

тут уже нужно смотреть сколько товаров и что тормозит систему 

пока что 36к, будет около 630к. 

[Otvet]

Да чего мелочиться - давайте кешировать готовые страницы. :-)

Это кусок из модифицированного мной кеша, там все раскладывается по папочкам, и совершенно не напрягает. К тому же все единообразно: на входе метода модели проверили кеш, далее запросили, на выходе сохранили.

как раз таки кешировать страницы это та же степь

в модели плодить кеши getCategory, потом каждый раз дергать сотню файлов при построении дерева это глупость

 

а закешировать одно дерево (module/category или header) в 1 файл это оптимизация

[chukcha]

Да чего мелочиться - давайте кешировать готовые страницы.

 

Не совсем

 

Можно, полностью закешировать некоторые модули, например рекомендуемые, слайдеры, которые не требуют динамических данных

Можно закешировать футер, если в него не попадают, какие-нибудь динамические данные

 

header кешировать нельзя, из-за наличия динамических данных стилей, скриптов

Т.е. подход к кешированию, должен быть обдуманный

 

 

OFFTOP

 

Но, для правильной организации кеша, нужно предусмотреть другой механизм генерации

 

1. Генерация контента

2. Генерация position

3. Генерация footer

4. Генерация header

И это все в разных потоках

 

п.2 можно исключить, потому что он принадлежит потоку

 

Т.е.

в output попадает не сгенерированный контент

А элементы массива

 

$output['header']

$output['content'] array(

'column_left',

'content'

'column_right'

)

$output['footer']

 

Но эти рассуждения НИ О ЧЕМ...

[druzhkov]

как раз таки кешировать страницы это та же степь

в модели плодить кеши getCategory, потом каждый раз дергать сотню файлов при построении дерева это глупость

 

а закешировать одно дерево (module/category или header) в 1 файл это оптимизация

 

Вы не путайте getCategory и getCategories. При построении меню используется второе.

 

Соответственно:

если будут только корневые директории - прочитаем 1 файл

корневые + поддиректории - прочитаем, условно, 10 файлов

корневые + поддиректории + подподдиректории - прочитаем, условно, 100 файлов (здесь да, имеет смысл сохранять готовое дерево)

 

Правильно кеширование делать именно в моделях, т.к. неизвестно из какого контроллера прийдет туда запрос. Это основа, и она всегда должна работать быстро. Ну, если и этого не хватает - тогда добавляйте дополнительный кеш уже на уровне контроллера, целого модуля, блока или вообще целой страницы. Например, вот такая "матрешка" для высоконагруженного проекта:

- кеш mysql

- кеш на уровне моделей (файловый, мемкеш)

- кеш на уровне контроллеров (особо тяжелые куски)

- кеш модуля

- кеш всей страницы

[chukcha]

public function getCategory($category_id)
	{
		$category_info = $this->cache->get((int)$this->config->get('config_language_id') . '.' . (int)$this->config->get('config_store_id') . '.' . (int)$category_id);
		
		if (FALSE === $category_info)
		{
			$query = $this->db->query("SELECT DISTINCT * FROM " . DB_PREFIX . "category c
			LEFT JOIN " . DB_PREFIX . "category_description cd ON (c.category_id = cd.category_id)
			LEFT JOIN " . DB_PREFIX . "category_to_store c2s ON (c.category_id = c2s.category_id)
			WHERE c.category_id = '" . (int)$category_id . "' AND cd.language_id = '" . (int)$this->config->get('config_language_id') . "'
			AND c2s.store_id = '" . (int)$this->config->get('config_store_id') . "' AND c.status = '1'");
			
			$category_info = $query->row;
			
			$this->cache->set((int)$this->config->get('config_language_id') . '.' . (int)$this->config->get('config_store_id') . '.' . (int)$category_id, $category_info);
		}
		
		return $category_info;
	}

@druzhkov, кто предложил этот код?

Вы не путайте getCategory и getCategories.

Кто и что путает?

Вы уж определитесь.

[druzhkov]

Кто и что путает?

Вы уж определитесь.

Вот запрос топикстартера:

 

SELECT * FROM oc_category c
LEFT JOIN oc_category_description cd ON (c.category_id = cd.category_id)
LEFT JOIN oc_category_to_store c2s ON (c.category_id = c2s.category_id)
WHERE c.parent_id = '503' AND cd.language_id = '1'
AND c2s.store_id = '0' AND c.status = '1'
ORDER BY c.sort_order, LCASE(cd.name)

Вот мой код из getCategories:

 

SELECT * FROM " . DB_PREFIX . "category c
LEFT JOIN " . DB_PREFIX . "category_description cd ON (c.category_id = cd.category_id)
LEFT JOIN " . DB_PREFIX . "category_to_store c2s ON (c.category_id = c2s.category_id)
WHERE c.parent_id = '" . (int)$parent_id . "' AND cd.language_id = '" . (int)$this->config->get('config_language_id') . "'
AND c2s.store_id = '" . (int)$this->config->get('config_store_id') . "'  AND c.status = '1'
ORDER BY c.sort_order, LCASE(cd.name)

Совпадают?

Я не понимаю, чего вы привязались к getCategory. Если не нравится, можно туда не смотреть. Это попутно скопировались из редактора.

[chukcha]

Что скопировалось?

 

Это

$category_info = $this->cache->get((int)$this->config->get('config_language_id') . '.' . (int)$this->config->get('config_store_id') . '.' . (int)$category_id);

 

что-то я не вижу разницы в запросе

Один скомпилированный, второй - в модели.

 

Кто предложил кешировать этот запрос? (привел пример)

[druzhkov]

 

что-то я не вижу разницы в запросе

Один скомпилированный, второй - в модели.

 

Кто предложил кешировать этот запрос? (привел пример)

 

Разницы и не должно быть.

ТС привел лог и сказал, что тормозит магазин. Логично заключить, что это медленные запросы. Я привел вариант, как их можно закешировать.

[chukcha]

Вам здесь пытаются объяснить, что кешировать getCategory - бессмысленно

 

Кроме того, также показана неверная  конструкция SELECT c использованием DISTINCT

[druzhkov]

Кроме того, также показана неверная конструкция SELECT c использованием DISTINCT

Если вас не устраивает, сделайте пулл реквест на гитхаб опенкарта. Данная конструкция стоит как в 1.5, так и в 2.0.

 

Вам здесь пытаются объяснить, что кешировать getCategory - бессмысленно

Еще раз напишите обоснование бесмысленности. Не понимаю вашу мысль.

[chukcha]

Повторять две страницы?

 

Увольте.

 

Те кто заинтересовался - прочтет и поймет.

Там

1. Вопрос для понимания

2. Тесты

3. Рассуждения о бессмысленности кеширования одной строки в выборке

[druzhkov]

Вы, коллега, полагаю, с высоконагруженными проектами не работали?

 

В любом случае, нужно пояснить:

- mysql не резиновый, и при высокой посещаемости всякая мелочь, которой очень много, начинает реально тормозить

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

- а еще бывает, что в команде разработчиков кто-то начал делать запросы к незакешированному методу (бывает и в цикле), а тимлид не уследил, потому что он не тысячерукий бог Шива, и снова пошла нагрузка

- и т.д. и т.п.

 

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

[Yoda]

Вы, коллега, полагаю, с высоконагруженными проектами не работали?

 

В любом случае, нужно пояснить:

- mysql не резиновый, и при высокой посещаемости всякая мелочь, которой очень много, начинает реально тормозить

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

- а еще бывает, что в команде разработчиков кто-то начал делать запросы к незакешированному методу (бывает и в цикле), а тимлид не уследил, потому что он не тысячерукий бог Шива, и снова пошла нагрузка

- и т.д. и т.п.

 

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

Я работал. И однозначно могу сказать что вы пишите бред! 

Mysql - резиновый и упирается только в ресурсы сервера.

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

 

А бывает что не только базы выносят на сервер, а под сегменты таблиц ставят отдельную редиску, которая обслуживает к прмеру клиентов, у которых имя начинается на A, а потом еще одну, у которых на B и так 33 штуки до Z.

630 000 - это не мало и не много. MySql кушает и не кашляет. Но вот некоторые реализации требуют напильника.

 

 

Умные матюки про teamlead - оставьте молоденьким девчонкам. 

100 файлов кеша на getCategory это в 100 раз хуже, чем один кеш на все дерево. И в 10 000 раз хуже, чем один запрос на все дерево и формирование дерева через узлы массива. 

 

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

[druzhkov]

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

 

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

 

100 файлов кеша на getCategory это в 100 раз хуже, чем один кеш на все дерево. И в 10 000 раз хуже, чем один запрос на все дерево и формирование дерева через узлы массива.

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

[Yoda]

Вы не за меня радуйтесь - а за себя грустите. 

 

Потому как тот механизм который предлагаете вы, база отрабатывает быстрее чем кеш!

 
И в нем смысла нет.

Еще раз повторяю. Заканчивайте вредные советы!

[snastik]

 

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

 

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

 

Все придумано и реализовано до вас в модуле Turbo.

[Otvet]

@druzhkov,

 

ок, я малость смешал в кучу

 

придется расписать...

 

1. getCategory очень легкий запрос, и вызывается единицы раз на страницу. Mysql работает значительно быстрее нежели засоренная ФС через glob

 

 

2. getCategories чуть тяжелее, вызывается множественно только во всяких меню. Не имеет смысла кешировать детали паззла если можно собранный

 

 

 

P/S  Создавая кучу файлов, пускай даже прямого влияния на сам кешированный запрос и не будет, зато замедлит работу кеша в целом, например сео_про. И мифическая оптимизация приведет к общему минусу

Не стоит сравнивать mysql с ФС, как минимум до тех пор пока:

• это не SSD
• физически полностью не выделен, что позволяет задействовать аппаратные технологии ускорения ФС (а когда на одном устройстве сотня клиентов этого не будет)
• используется glob

 

[druzhkov]

Потому как тот механизм который предлагаете вы, база отрабатывает быстрее чем кеш!

 

 

Вот тест:

public function test()
	{
		$this->load->model('catalog/category');
		
		$mtime = explode(" ", microtime());
		$start_time = $mtime[1] + $mtime[0];
		
		for ($j = 0; $j < 100000; $j++)
		{
			$category_info = $this->model_catalog_category->getCategory(209);
		}
		
		$mtime = explode(" ", microtime());

		printf ("page generated %f sec", $mtime[1] + $mtime[0] - $start_time);
	}

Из базы 8.771922 sec , из кеша 3.218499 sec. Замечания, наблюдения?

[Yoda]

Вот тест:

public function test()
	{
		$this->load->model('catalog/category');
		
		$mtime = explode(" ", microtime());
		$start_time = $mtime[1] + $mtime[0];
		
		for ($j = 0; $j < 100000; $j++)
		{
			$category_info = $this->model_catalog_category->getCategory(209);
		}
		
		$mtime = explode(" ", microtime());

		printf ("page generated %f sec", $mtime[1] + $mtime[0] - $start_time);
	}

Из базы 8.771922 sec , из кеша 3.218499 sec. Замечания, наблюдения?

 

Параметры базы, параметры сервера, структура таблиц, индексы на таблицах, количество файлов в папке с кешем, очередь чтения c диска в боевом режиме, внутренний механизм кеширования mysql - не, не слышал?

 

Если на reg.ru на шареде за две копейки - разница будет раз в 100 отличаться. 

 

 

Только разница между вашими теоретическими выкладками и моими тезисами в том, что вы знаете слово teamlead и живете в синтетических тестах, а я сутки на пролет занимаюсь построением больших систем и оптимизацией  средних. Поэтому все о чем вы сейчас пытаетесь с пеной у рта рассказать, пройдено в третьем классе так сказать.

Я долго не мог понять, кто эти специалисты, после которых люди приходят ко мне со словами "пятеро уже работали, а тормозит как тормозило".

 

И еще конкретно этот пример оптимизируется совершенно иным методом. 

Если речь идет о методе из 2.x, если внимательно посмотреть в запрос в нем идет выборка SELECT * из нескольких таблиц c последующей сортировкой по lcase(name). Если включить немного мозг и изучить матчасть по mysql. То логичным будет делать выборку SELECT category_id с составным индексом по полям status и parent_id. В этом случае скорость работы запроса увеличвается в несколько сот раз на больших магазинах. И после этого к результирующему набору дособрать необходимые данные (name, title, descr etc...) и уже средствами php по минимальному набору данных осуществить сортировку по названию. Ни один кеш стандартного метода и рядом стоять не будет, я уже молчу про глобальное снижение нагрузки на всю систему.