Перейти к содержанию
Официальный форум поддержки Simpla

[2.*] Модуль кеширования MySQL запросов


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

Отсутствие системы кеширования и большое количество запросов к Базе Данных создаваемых как самой CMS Simpla, так и сторонними модулями может привести к регулярной ошибке MySQL сервера "Too many connections" или любезному отключению аккаунта хостинг провайдером (для экономии ресурсов сервера) с намеком на переход на  VPS или выделенный сервер. 

 

Особенно это касается интернет-магазинов база данных которых переваливает за 1000 товарных позиций и средней посещаемости ресурса от 500чел/сут.

 

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

Теперь не стоит боятся большого количества запросов. :)

 

Модуль кеширования MySQL запросов:

  1. Автоматическое кеширование всех запросов.
  2. Отслеживает изменения в таблицах интернет-магазина и удаляет связанные с этими таблицами кеш-файлы. (Благодаря чему, у вас всегда будет актуальный кеш запроса)
  3. В новой версии нет ограничений на количество кеш-файлов. Все запросы сохраняются и хранятся вечно. Удалить можно напрямую через ФТП. Максимальное количество кеш-файлов: 2000шт. по умолчанию (есть возможность изменить), по достижению максимального кол-ва кеш-файлы удаляются.   
  4.  Возможность хранения данных в сжатом формате - gzip. Эта опция существенно может сэкономить место на диске занимаемое кешом. PS: Стоит помнить, что распаковывание файлов влияет так же на нагрузку процессора.
  5. Протоколирование работы системы кеширования. Возможен вывод debug'а.

 

                                   

Данный модуль желателен для интернет-магазинов:

  1. база данных которых содержит более 1000 товарных позиций
  2. посещаемость которых от 500 и выше
  3. у которых много товарных опций участвующих в фильтре товаров (как в стандартном фильтре, так и в ajax фильтрах)
  4. у которых установлены сторонние модули выполняющие тяжелые запросы к БД, содержащие в себе подзапросы к другим таблицами, модули инициирующие большое количество мелких запросов к БД. К таким модулям можно отнести практически каждый третий платный/бесплатный модуль.
  5. которые обслуживаются у капризных провайдеров с дешевыми тарифными планами.

Проведение  тестов показало:

  1. Время получения информациии ииз кеш-файлов происходит в 2-3 раза быстрее, чем получении информации из БД. (Для примера: Кол-во запросов: 11; время выполнения запросов: Queries execution time: 0.0259737968445 sec. Время получения запросов из кеш:Queries execution time: 0.00172019004822 sec. )Время получения информации из кеш-файлов одинаково (бывает чуть быстрее) не отличается от времени выполнения запросов.
  2. Время генерации страницы в некоторых случаях сокращается, а так на том же уровне.

PS: Никаких переделок в модулях и самом движке (кроме подключения модуля) не потребуется, вы так же обращаетесь к БД как и раньше. ($this->db->query(); $this->db->results(); и т.п.)

 

Cтоимость модуля: 20$ + бесплатная установка.

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

 

Демо на стандартной Simpla: http://demo.gorgaz.com.ua/

Для проделывания всяких изменений, милости прошу в админку: (Логин и пароль: demo) для сайта demo.gorgaz.com.ua

Изменено пользователем cernos
Ссылка на сообщение
Поделиться на другие сайты

Как раз интересно посмотреть демо на стандартном шаблоне.  А работает у Вас как-то странно:

 

1. Отсутствует блок просмотренных товаров - а на нем как раз интересно понаблюдать работу.

2. Пробую разные применения фильтра, в том числе руками в адресной строке пишу разное типа  max_price=33.8965, а в результате все время одно и то же DataBase queries: 0.  Сомнительно, что накешировали все запросы по всем дробным числам...

3. На странице товара, например,  http://demo.energodom.com.ua/products/mikser_zelmer_4814.html

выходит сообщение об ошибке MySQL.

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

 

Как раз интересно посмотреть демо на стандартном шаблоне.  А работает у Вас как-то странно:

 

1. Отсутствует блок просмотренных товаров - а на нем как раз интересно понаблюдать работу.

2. Пробую разные применения фильтра, в том числе руками в адресной строке пишу разное типа  max_price=33.8965, а в результате все время одно и то же DataBase queries: 0.  Сомнительно, что накешировали все запросы по всем дробным числам...

3. На странице товара, например,  http://demo.energodom.com.ua/products/mikser_zelmer_4814.html

выходит сообщение об ошибке MySQL.

 

Попробуйте менять адресную строку сразу в: отладчике. К примеру в хроме: 

view-source:http://demo.energodom.com.ua/_bytovaya-tehnika/fotoapparaty/?min_price=399.9&max_price=14743?min_price=399.9&max_price=14743

Вот что я получил:

 DataBase queries: 4
 Cache read queries: 17
 Queries execution time: 0.0502939224243 seconds 

 

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

В данный момент веду доработку, потому могут возникать некоторые косяки ;)

 

Сегодня постараюсь сделать демо-версию на новой симпле + стандартный шаблон с выводом дебага.

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

1. Автоматическое кеширование всех запросов.

 

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

А как Вы отслеживаете изменения в таблицах? Через SHOW TABLE STATUS ?

 

3. Максимальное количество кеш-файлов: 2000шт., после чего производится их авто-очистка кеша.

Может лучше делать проверку на время жизни кэша при его запросе? Если он долго хранится - то удалять... То очищать все по достижению количества, как по мне не совсем правильно. Ведь если магазин с большим количеством товаров то можно предвидеть что эти очистки будут довольно часты. Что сильно снижает эффективность кэширования.  

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

 

 

 

 

Попробуйте менять адресную строку сразу в: отладчике. К примеру в хроме: 

view-source:http://demo.energodom.com.ua/_bytovaya-tehnika/fotoapparaty/?min_price=399.9&max_price=14743?min_price=399.9&max_price=14743

Вот что я получил:

 DataBase queries: 4
 Cache read queries: 17
 Queries execution time: 0.0502939224243 seconds 

 

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

В данный момент веду доработку, потому могут возникать некоторые косяки ;)

 

Сегодня постараюсь сделать демо-версию на новой симпле + стандартный шаблон с выводом дебага.

 

А можно на это демо повесить фильтр который сейчас есть на сайте http://demo.energodom.com.ua  :)

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

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

 

Cernos, я правильно понял для обработки фильтра используется 18 запросов к базе?  :)

 

 

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

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

Итак доступно демо на стандартной версии Simpla:

http://demo.gorgaz.com.ua/

 

сейчас Корс спросит - почему запросов 12 а не 16  :ph34r:

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

Итак доступно демо на стандартной версии Simpla:

http://demo.gorgaz.com.ua/

Переходя по ссылкам то появляются картинки товаров то опять пропадают.
Ссылка на сообщение
Поделиться на другие сайты

Отвечаю на возникшие вопросы:

 

Как раз интересно посмотреть демо на стандартном шаблоне.

Смотрим Kors по уже доступной ссылке: http://demo.gorgaz.com.ua/ Так же предоставляю доступ к админке логин и пароль: demo

 

 

А как Вы отслеживаете изменения в таблицах? Через SHOW TABLE STATUS ?

 

Может лучше делать проверку на время жизни кэша при его запросе? Если он долго хранится - то удалять... То очищать все по достижению количества, как по мне не совсем правильно. Ведь если магазин с большим количеством товаров то можно предвидеть что эти очистки будут довольно часты. Что сильно снижает эффективность кэширования.  

1. Отслеживание происходит не через show table status. Каждый запрос проходит через обработчик, который следит за оператором запроса, скажем INSERT INTO s_products ...... из этого запроса ясно, что идет обновление таблицы s_products, вот собственно и удаляем весь кеш связанный с таблицей s_products. (ясно в деле это выглядит более сложно чем на словах)

2. Не стоит делать проверку на время жизни кеша по нескольким причинам: 

2.1 Кеш может устареть в отличии от оригинальных возвращаемых данных; Если действовать по типу мое решение + время, то будет путаница, лишние логические узлы.

2.2 Требуется много процессорного времени + нагрузка на HDD возникает при проверке всех файлов на дату создания.

2.3 Эффективность кеширования состоит не в том, чтобы вовсе убрать запросы к БД, а в том, чтобы значительно их снизить, количество живущих файлов можно увеличить по своему усмотрению, за это отвечает специальная переменная.

 

А можно на это демо повесить фильтр который сейчас есть на сайте http://demo.energodom.com.ua  :)

В принципе, тот фильтр который стоит, делает довольно таки много лишних запросов (говорю с намеком на покупку твоего :)). Нет сейчас времени устанавливать его на новое демо.

 

 

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

 

Cernos, я правильно понял для обработки фильтра используется 18 запросов к базе?  :)

 

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

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

 

 

Переходя по ссылкам то появляются картинки товаров то опять пропадают.

Это связано уже с симплой =) Незнаю почему, но картинки на лету не отрабатываются, только после рефреш страниицы... Я даже помню, этот вопрос поднимался здесь на форуме и там было решение проблемы.

Кажется в этой теме описана проблема: http://forum.simplacms.ru/topic/8339-%D1%84%D0%BE%D1%82%D0%BE-%D0%BA%D0%B0%D1%80%D1%82%D0%BE%D1%88%D0%BA%D0%B0-%D0%BE%D1%88%D0%B8%D0%B1%D0%BA%D0%B0-%D0%BF%D1%80%D0%BE%D1%81%D0%BC%D0%BE%D1%82%D1%80%D0%B0/?hl=%D1%84%D0%BE%D1%82%D0%BE

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

В принципе, тот фильтр который стоит, делает довольно таки много лишних запросов (говорю с намеком на покупку твоего :)). Нет сейчас времени устанавливать его на новое демо.

 

вопрос не актуален, я уже понял что это не твой фильтр  :) Но для примера актуальности кэширования очень даже кстати

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

вопрос не актуален, я уже понял что это не твой фильтр  :) Но для примера актуальности кэширования очень даже кстати

 

Кеширование так же хорошо при большой базе товаров и сложных выборках из БД - сюда же можно привести в пример поиск по сайту ajax-вый, сортировку, фильтр (как стандартный, так и от сторонних разработчиков) который содержит в себе много подзапросов.

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

2.1 Кеш может устареть в отличии от оригинальных возвращаемых данных; Если действовать по типу мое решение + время, то будет путаница, лишние логические узлы.

 

2.2 Требуется много процессорного времени + нагрузка на HDD возникает при проверке всех файлов на дату создания.

 

2.3 Эффективность кеширования состоит не в том, чтобы вовсе убрать запросы к БД, а в том, чтобы значительно их снизить, количество живущих файлов можно увеличить по своему усмотрению, за это отвечает специальная переменная.2.2 Требуется много процессорного времени + нагрузка на HDD возникает при проверке всех файлов на дату создания.

 

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

К примеру можно при подключении к БД, через SHOW TABLE STATUS, получить время изменения таблиц. А дальше, уже при обращении к кэшу, сверять время его создания с временем последнего изменения таблицы. В результате добавится один простой запрос но он в свою очередь может значительно улучшить процесс. А ограничивать их количество, по моему мнению, не правильно.

1) постоянные проверки количества файлов (как я понимаю при каждом запросе или возможно при старте)

2) Я уже говорил. Если, допустим, в магазине 10тыс товаров и на сайте 50 человек. то кэш по сути даже сработать не успеет. Поскольку постоянно будет очищаться... Нагрузка на БД не уменьшится, а на HDD только возрастет...

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

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

 

Спасибо за заинтересованность в модуле и пожелания, я их учту.

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

Итак доступно демо на стандартной версии Simpla:

http://demo.gorgaz.com.ua/

Спасибо, очень даже интересно.

 

Только положить в корзину не получается. Анимация идет, а в корзине пусто...

 

И на демо, может, откроете показ инфы по запросам на самой странице, чтоб каждый раз код не открывать?

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

Корзина исправлена и работоспособна на http://demo.gorgaz.com.ua/.

Ведется работа над модулем на demo.energodom.com.ua - возможны перебои в работе.

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

А сейчас в демо всегда  ненулевое число запросов. Даже когда страницу  (например http://demo.gorgaz.com.ua/products/samsung-s5570-galaxy-mini) обновляю несколько раз, 1 запрос все равно есть. А должно бы быть 0...

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

Так что с модулем? Работает или нет? У меня есть острое ощущение что он мне нужен. )

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

Как только будет готов окончательно, отпишусь!

 

 

А сейчас в демо всегда  ненулевое число запросов. Даже когда страницу  (например http://demo.gorgaz.com.ua/products/samsung-s5570-galaxy-mini) обновляю несколько раз, 1 запрос все равно есть. А должно бы быть 0...

Спасибо, был замечен маленький БАГ из-за которого запросы с 0-м результатом не кешировались.

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

Готов новый модуль. Можете смотреть в работе! http://demo.gorgaz.com.ua/

  

А сейчас в демо всегда  ненулевое число запросов. Даже когда страницу  (например http://demo.gorgaz.com.ua/products/samsung-s5570-galaxy-mini) обновляю несколько раз, 1 запрос все равно есть. А должно бы быть 0...

Сделал вывод количества запросов и дебага на страницу. Можете смотреть!

 

 

Что нового:

  1. Добавлена таблица в БД для хранения пары "MD5 key => tables". Запросы к таблице осуществляются только при добавлении и удалении кеша. При считывании кеша нет запросов в БД.
  2. Добавлено GZIP сжатие для хранимых кеш-файлов, что может существенно сэкономить место на диске. Не стоит забывать, что распаковка сжатых файлов так же создает нагрузку на CPU. Тут уже стоит выбирать, чем жертвовать.
  3. Более подробное протоколирование работы системы кеширования.
  4. Существенно переработан и оптимизирован PHP код, что благоприятно отразилось на скорости работы. Теперь считывание кеша происходит гораздо быстрее чем обращение к БД + уменьшен расход ОЗУ в сравнении со старой версией модуля.
  5. Снято ограничение на количество кеш-файлов. Кеш-файлы хранятся вечно. При обновлении базы данных удаляются только кеш-файлы которые имеют отношение к измененным таблицам. 
Ссылка на сообщение
Поделиться на другие сайты

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

 

Предусмотрены ли настройки кеширования

1. Включить-отключить

2. Использовать ли сжатие

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

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

 

Предусмотрены ли настройки кеширования

1. Включить-отключить

2. Использовать ли сжатие

1. При запросе в БД отобразить его в протоколе можно, мне не составит труда.. сделаю.

2. Показ времени затраченного на каждый запрос - вы думаете это нужно? Добавить код, лишние арифмитические действия + если время там и будет, то ... впринципе сделать не сложно дял демо версии могу и органиовать.

3. Отключать и включать кеширование и сжатие - можно, единственное сейчас только в ручном режиме (исправляя значение переменной с true на false. Вывод рубильников (вкл/выкл) в саму админку планирую.

 

Что касательно оформления заказа - проверяю.

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

Присоединяйтесь к обсуждению

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

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

Загрузка...
×
×
  • Создать...