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

[druzhkov]

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

 

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

 

Я прекрасно знаю влияние этих параметров. Это я запускал на своем компе - конечно, тюнинга особого нет. Ладно, попробуем на шареде таймвеба:

 

Из базы: 4.74962 sec

Из кеша: 2.904995 sec

 

Полагаю, на таймвебе все-таки база получше настроена, чем у меня. В файловом кеше округленно лежит 1000 файлов. Так вроде всё типовое. Диск SSD. Индексы по базе проставлены.

 

Еще вопросы, замечания?

[snastik]

Я прекрасно знаю влияние этих параметров. Это я запускал на своем компе - конечно, тюнинга особого нет. Ладно, попробуем на шареде таймвеба:

 

Из базы: 4.74962 sec

Из кеша: 2.904995 sec

 

Полагаю, на таймвебе все-таки база получше настроена, чем у меня. В файловом кеше округленно лежит 1000 файлов. Так вроде всё типовое. Диск SSD. Индексы по базе проставлены.

 

Еще вопросы, замечания?

судя по всему вы ничего не знаете, если округленно 1000 файлов в кеше это много по вашему. Это первое. Второе, вам уже трижды написали, что синтетический тест и боевой режим данной реализации - две совершенно разные вещи. И третье. Индексы все проставлены по вашему мнению, вы думаете что все.

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

[druzhkov]

судя по всему вы ничего не знаете, если округленно 1000 файлов в кеше это много по вашему. Это первое. Второе, вам уже трижды написали, что синтетический тест и боевой режим данной реализации - две совершенно разные вещи. И третье. Индексы все проставлены по вашему мнению, вы думаете что все.

 

 

ОК, вот есть реальный магазин на шареде. Типовой, у которого уже появляются проблемы с нагрузкой, но которому до полноценного тюнинга еще далеко. Предложите методику измерения эффективности "с" и "без" данного кеша, помимо синтетического теста.

[snastik]

ОК, вот есть реальный магазин на шареде. Типовой, у которого уже появляются проблемы с нагрузкой, но которому до полноценного тюнинга еще далеко. Предложите методику измерения эффективности "с" и "без" данного кеша, помимо синтетического теста.

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

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

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

Что собственно и было реализовано в turbocache для 1.5 и в turbo для 2.x.

Еще раз повторюсь. Театр начинается с вешалки, а быстрая система на Opencart - с базы данных. Все оптимизаторы-теоретики, начитались подобных себе "гуру" и пытаются бездумно всовывать его везде, показывая клиенту результат работы с данными из кеша и рассказывая - смотри как круто, теперь грузится за тысячные секунды. Это не оптимизация, а попытка надышаться перед смертью. Любая система, а в особенности высоконагруженная. В первую очередь должна лишиться бутылочных горлышек, а уже потом обрасти всякого рода кешами. Вы же со своей верой в синтетические тесты и отсутствием реального опыта боевых действий, пытаетесь вместо решения проблемы создать еще одно узкое бутылочное горлышко. Так что http://www.mysql.ru/docs/man/ на сегодня ваше все.

[chukcha]

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

Я работал на миллионах  записей, на 20(в сек) одновременных коннектах в базу. Коннектах!!! Но вам это ничего не скажет.

 

Я, проверял не такие легкие запросы, в два Left Join, а с десяток присоединенных таблиц как слева, так и справа, с большим количеством вложенных запросов, и с созданием временных таблиц. Где файловое кеширование - пустой звук.

 

Свои придумки о highload  оставьте при себе.
 

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

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

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

:)

Печалько...

Скажите, если сервер на локалхосте, или рядом стоит, соединенный быстрым интерфейсом, в чем будет разница?
Если, а. у первого совместное использование дискового пространства, + TCP coonect

Или у второго с разделенным доступом + TCP coonect

 

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

[Yoda]

Да, и это я пытался человеку донести.

Даже используя ssd, скорость доступа сопоставима.

 

 

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

 

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

1. Mysql - это хранилище с поддержкой быстрой выборки по ключам. Уже на 3-4-5к файлов в папке будут тормоза с поиском файла, и механизм индексирования к файловой системе не особо применим.

2. Правильно сконфигурированный сервер базы, позволяет держать все таблицы в памяти, обеспечивая все таки более быстрый доступ к данным, чем даже обращение к файлу на SSD диске.

3. Очередь обращения к данным в памяти практически не влияет на скорость доступа, а вот очередь обращения к файлам опять же на том же ssd, никуда не денешь.

 

Если говорить о реализации тяжелого проекта, в котором надо реализовать подобную задачу, и говорить о жестокой реализации. То нужно денормализовать структуру. Создать отдельный справочник (category_id, data_subcategory) обновляемый при любых изменениях в категориях. И использовать его, вместо постоянных запросов с JOIN. Равно как и для getTotalProduct, можно сделать RT-индекс и подвесить все в тот же сфинкс.

 

 

 

:)

Печалько...

Скажите, если сервер на локалхосте, или рядом стоит, соединенный быстрым интерфейсом, в чем будет разница?

Если, а. у первого совместное использование дискового пространства, + TCP coonect

Или у второго с разделенным доступом + TCP coonect

 

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

 

 

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