Серверная оптимизация OpenCart

[snastik]

key_buffer ?

table_cache ?

my_isam_sort_buffer_size ?

tmp_table_size ?

И так далее..

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

Посмотреть где затыкается  - вы можете настроив db_log от фрилансира, или моим профайлером, а потом при помощи визуального анализатора этих запросов в phpmyadmin очень хорошо видно, какие именно операции тянут много времени, то ли это отсутствие индексов, то ли это cache_write или disc_write.

[snastik]

хороший конфиг кстати вот, но это для 4-8 гиг серванта. Соответственно поделите на 4, если у вас всего гиг мозгов.

#Tuning
key_buffer              = 1200M
thread_stack            = 512K
thread_cache_size	    = 32
table_cache             = 60000
thread_concurrency      = 12
net_buffer_length       = 32

query_cache_limit       = 2M
query_cache_size        = 256M

myisam_sort_buffer_size = 256M
tmp_table_size          = 256M
max_heap_table_size     = 128M

read_buffer_size        = 2M
read_rnd_buffer_size    = 4M

sort_buffer_size        = 2M
join_buffer_size        = 4M

max_allowed_packet	    = 256M
max_sort_length         = 512

[Vladzimir]

Ваш же конфиг для 4 ядерного с 4 гигами, с и без кеша запросов. Кеш запросов в 1,5 раза хуже чем без него. :?

[snastik]

Соответственно поделите на 4, если у вас всего гиг мозгов.

 

[Vladzimir]

 

Соответственно поделите на 4, если у вас всего гиг мозгов.

 

 

Собственно для 4 ядерного с 4 гигами

[snastik]

А каким боком количество ядер влияет на настройки кешей ?

[Vladzimir]

А каким боком количество ядер влияет на настройки кешей ?

Там указано что у сервера RAM = 4Gb

[snastik]

OMG.

Параметры настроек поделите на 4 - получите конфиг для 1 гига.

И я так понимаю. Что разницы между количеством памяти и количеством ядер процессора вы не совсем понимаете.

[Vladzimir]

А зачем мне для 1 гига если у меня 4 гига?

[snastik]

Тю блин.. Вы бы написали сразу. Тогда прописывайте - как есть и все.

Ну и если у вас 4 ядра - не лишним будет подстроить количество worker_process в nginx до 4х. А также уменьшить параметр swappines системы до 50, чтобы для mysql осталось достаточное количество памяти.

[Vladzimir]

Так я про это уже три раза сказал. А у нгинкса там все в порядке.

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

ВОт сами попробуйте на своем конфиге, и я думаю что результат повторится.

[snastik]

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

[Vladzimir]

Ну а все-таки кеш вкл/выкл.

[snastik]

если хотите - можете провести эксперимент на магазине. Поменяйте в модели product

Все SELECT на SELECT SQL_NO_CACHE и запустите loadimpact, чтобы нагрузочка пошла. После этого вернемся к обсуждению вопроса.

[Vladzimir]

А зачем мне сравнивать мяягкое с квадратным?

Речь с самого начала шла о кеше запросов, не более.

И у меня стоит

query-cache-type = 0
query-cache-size = 0

[snastik]

Т.е. силами сообщества с подачи Топорчило в код ocsotore вносится изменение, которое как раз на полную и использует кеширование результатов запросов в базу.

Если интересно какое именно - то вот тут на гитхабе.

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

Ржу))) :ugeek:

[Vladzimir]

Дело в том что у меня как раз и стоит данное изменение. Но вот как оказалось, что данное решение не есть кросплатформенное, поскольку конечный пользователь не всегда может влиять на настройку программного окружения.

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

Так что это я ржунимагу.

 

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

[polarnik]

А зачем постоянно делать запрос, если можно его закешировать  и вывести? Или оптимизация ради оптимизации?

[Vladzimir]

Для тех, кому лень читать сначала:

1. MySQL тоже кэширует запросы

2. Система кэширование MySQL гораздо умнее и быстрее OpenCart - учитывает частоту и продолжительность запросов, хранит кэш в том числе в памяти

3. MySQL НЕ кэширует запросы с NOW() и т.п.

Кеш мускуля увеличивает время запроса в 1,5 раза.

[Vladzimir]

Snastik привел пример настройки MySQL для своей системы. В phpMyAdmin можно посмотреть эффективность настройки вашей системы. Экспериментируйте.

 

Поверьте, у Snastik'а достаточно опыта, чтобы говорить, что кэш SQL-запросов в большинстве случаев может ускорить.

Хотя можно придумать базу, когда SQL-кэш будет только все портить. В вашем случае скорее всего дело в настройках МySQL. Хотя возможна и иная причина.

Я ставил приведенные Snastik настройки себе, ситуация была аналогичной. Включил кеш - тормоза, отключил - летает.

У меня появилась догадка, я ее обосновал, все критикуют, но никто не пытался повторить и опровергнуть ее.

Почему так?

[Vladzimir]

Продолжаем программу телепередач на завтра.

Теперь я вроде бы начинаю понимать недоумение kikasso по поводу SQL-кеша.

Задача для любознательных.

В my.cnf включаем кеш запросов только по требованию (query-cache-type = DEMAND, query-cache-size = 16M), и в моделе product вносим небольшую правку, в запросе с SQL_CALC_FOUND_ROWS после SELECT вставляем SQL_CACHE.

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

Повторяем это несколько раз.

Потом идем в phpMyAdmin и делаем запрос на вывод информации по нашему кешированию запросов.

SHOW GLOBAL STATUS LIKE 'Qcache%'

Выйдет примерно следующая табличка.

Qcache_free_blocks 1

Qcache_free_memory 16754024

Qcache_hits 2

Qcache_inserts 249

Qcache_lowmem_prunes 0

Qcache_not_cached 76602

Qcache_queries_in_cache 0

Qcache_total_blocks 10

Обращаем внимание на Qcache_hits (запросов из кеша), Qcache_inserts (вставок в кеш), Qcache_queries_in_cache (количество закешированных запросов).

Удивляемся почему Qcache_queries_in_cache равно 0, офигиваем от соотношения вставлено/получено, и начинаем разбираться, как же так что кеш пишется, но практически никогда не читается, да и сам кеш куда-то испарился.

Жду ответы :-)

[Vladzimir]

$this->NOW = date('Y-m-d H').':00:00';

Розачарую вас, но это уже стояло по умолчанию.

[Vladzimir]

Ваше исследование очень полезно!

Следующее мое подозрение - отключите вот эту дрянь:

public function updateViewed($product_id) {
	$this->db->query("UPDATE " . DB_PREFIX . "product SET viewed = (viewed + 1) WHERE product_id = '" . (int)$product_id . "'");
}

Возможно постоянное изменение таблицы product при просмотре товара сбрасывает кэш.

В самую "дырочку"!

А еще кеш будет сбрасываться при оформлении заказа, если у товаров стоит статус "вычитать со склада".

Да и кеш должен работать не менее часа

[snastik]

Запрос на выборку товаров - не такой и тяжелый.
А вот дерево категорий. Там кеш живет отлично.
И самое главное это кеш сео про. Запрос на 10 000 товаров к примеру каждый раз обрабатывает 10 000 строк. При любых раскладах. И вот для этой ситуации отключать кеширование на уровне mysql совсем не здравая идея.И к тому же там нет привязок к датам. Так что жить может хоть сутки.

[Vladzimir]

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

$query = $db->query("SELECT * FROM " . DB_PREFIX . "setting WHERE store_id = '0' OR store_id = '" . (int)$config->get('config_store_id') . "' ORDER BY store_id ASC");

Тут же возрастает время генерации страницы.

Скорее всего кеш mysql эффективен только на небольших данных.