Speed up - [VM2&3] Модификации и хаки

Joomla! 2.5.17
VM 2.0.26
-------------------
При открытии категории с товаром (100 позиций) получаю 1500 запросов к базе, что не есть хорошо.
Скорость открытия порядка 7 секунд. Все каши включены, серв выделенный.
Какие есть варианты уменьшения количества запросов к БД (родителськие-дочерние товары резать нельзя)?
Кто пользовался Speed up VirtueMart от codingmall ? (дорогой очень)

7 секунд на 100 позициях... Мне кажеться дело далеко не только в VirtueMart.
А что за Speed up такой? Можно ссылку?

codingmall.com/products-mainmenu-8/65-speed-up-virtuemart

Вот пример: 30 товаров. 2708 SQL-запросов зафиксировано. 35.76 MB. 7 секунд. Все каши включены.

мой VDS:
CPU type   Intel® i7-4770S (Haswell Latest)
CPU Cores 4 Super Fast Haswell Cores
CPU Threads 8 Threads
CPU Speed 3.1-3.9 GHz
CPU Cache 8 MB
RAM   32 GB DDR
Hard disk 2x 1TB SATA
Operating system   Centos 5

Когда у меня был первый вирт, я порезал лишние запросы и всё было окей. По второму VirtueMart я не могу найти тем по резке sql. Странно всё это.

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

Когда у меня был первый вирт, я порезал лишние запросы и всё было окей. По второму VirtueMart я не могу найти тем по резке sql. Странно всё это.

а зачем темы? сами порежьте что не нужно, если customfield не используется то их тоже, запросов будет намного меньше

а зачем темы? сами порежьте что не нужно, если customfield не используется то их тоже, запросов будет намного меньше

Я боюсь своими корявыми руками лезть в код.
Custom'ы и Parant'ы я использую, а убирание их обычно является базой всех спид хаков.

Я боюсь своими корявыми руками лезть в код.
Custom'ы и Parant'ы я использую, а убирание их обычно является базой всех спид хаков.

тогда вам дорога на vps не ниже 2ГБ озу, не знаю сколько у вас товаров и сколько планируете выводить, если много и посещаемость за 1000-2000 в день то лучше 4Гб (в принципе за 10-20тр в год можно и больше 8ГБ взять vps), и если даже будет загрузка по 10-15 сек. это уже будет не страшно, и поверьте это нормальное явление иметь свой кусочек сервера для магазина и чем это становится доступней тем разработчики меньше обращают внимание на запросы и прочее

тогда вам дорога на vps не ниже 2ГБ озу, не знаю сколько у вас товаров и сколько планируете выводить, если много и посещаемость за 1000-2000 в день то лучше 4Гб (в принципе за 10-20тр в год можно и больше 8ГБ взять vps), и если даже будет загрузка по 10-15 сек. это уже будет не страшно, и поверьте это нормальное явление иметь свой кусочек сервера для магазина и чем это становится доступней тем разработчики меньше обращают внимание на запросы и прочее

Друг ты упустил из вида моё сообщение выше:

мой VDS:
CPU type   Intel® i7-4770S (Haswell Latest)
CPU Cores 4 Super Fast Haswell Cores
CPU Threads 8 Threads
CPU Speed 3.1-3.9 GHz
CPU Cache 8 MB
RAM   32 GB DDR
Hard disk 2x 1TB SATA
Operating system   Centos 5

А из программного обеспечения кроме самого сентоса что? Сентос надеюсь х64 (а то что не бывает еще)? VirtueMart не лучший выбор для большого магазина. Или надо иметь обширные познания.

А из программного обеспечения кроме самого сентоса что? Сентос надеюсь х64 (а то что не бывает еще)? VirtueMart не лучший выбор для большого магазина. Или надо иметь обширные познания.

CentOS Linux 6.5 x86_64
Ящик не только под один сайт, стоит много всего, всё крутятся хорошо, включая один магазин на первом VirtueMart.

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

А что кроме сентоса?

А что кроме сентоса?

Если из осей, то ничего. бд, почтовый сервер, апач... что еще стоит, мне всё перечислить? =)
P.S. Прошу прощения, но я не очень понял вопрос.

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

Друг ты упустил из вида моё сообщение выше:

мой VDS:
CPU type   Intel® i7-4770S (Haswell Latest)
CPU Cores 4 Super Fast Haswell Cores
CPU Threads 8 Threads
CPU Speed 3.1-3.9 GHz
CPU Cache 8 MB
RAM   32 GB DDR
Hard disk 2x 1TB SATA
Operating system   Centos 5

да пропустил, тогда в чем проблемы на стороне сервера настроить, ну и сам вирт подправить что можно

посмотрите что еще генерирует запросы как beagler советует, и посмотрите что несет нагрузку на сервер, можно просто top-ом из консоли посмотреть

Если вы не настраивали MySQL, то попробуйте настроить.
Замените содержимое файла /etc/my.cnf на содержимое файла /usr/share/mysql/my-huge.cnf. Это для RAM > 2Gb для Centos 6 x86_64 и MySQL 5.*.
Также закомментируйте в my.cnf строку log-bin=mysql-bin, иначе быстро израсходует диск. И удалите старые логи. Перезапустите сервис mysqld.

Это один из возможных шагов. Далее нужно смотреть другое, запустить mysqltuner и посмотреть, что он скажет. Но если БД не повреждена, то должно получиться по идее. У вас очень мощный сервер, но RAM 32Gb - вы уверены?

Вот часть такого my.cnf (добавил от себя туда кое-что к my-huge.cnf) для VM1 на 20 000 товаров, RAM 4Gb. Особых проблем не наблюдаю со временем открытия страниц. VM1 не модифицировал.

Спасибо всем кто откликнулся. Проблема всё ещё в процессе.

Speed up VirtueMart от codingmall прислали мне триал-версию. Обещанные 80% запросов плагин не убрал, всего лишь около 5%.
Вот ответ разработчиков: Something is conflicting. It may not be workable on your site.

Переходим к следующим вариантам. По возможности буду отписывать результаты.

Вот последние замеры: Страница в 20 товаров - 1426 запросов (Включены все каши). 2,5 sec.

Если вы не настраивали MySQL, то попробуйте настроить.
Замените содержимое файла /etc/my.cnf на содержимое файла /usr/share/mysql/my-huge.cnf. Это для RAM > 2Gb для Centos 6 x86_64 и MySQL 5.*.
Также закомментируйте в my.cnf строку log-bin=mysql-bin, иначе быстро израсходует диск. И удалите старые логи. Перезапустите сервис mysqld.

Это один из возможных шагов. Далее нужно смотреть другое, запустить mysqltuner и посмотреть, что он скажет. Но если БД не повреждена, то должно получиться по идее. У вас очень мощный сервер, но RAM 32Gb - вы уверены?

Вот часть такого my.cnf (добавил от себя туда кое-что к my-huge.cnf) для VM1 на 20 000 товаров, RAM 4Gb. Особых проблем не наблюдаю со временем открытия страниц. VM1 не модифицировал.

Спойлер

[свернуть]

Премного благодарен, очень дельный совет!

У себя я поудалял все, что только можно в базе VirtueMart, включая ненужные валюты и какие-то остатки от quickstart шаблона (английские демотовары). Небольшой прирост
Добавил в базе недостающий индекс - получил прирост в 2-3 раза при импорте товаров.
Тюнинг MySQL, описанным выше способом дает на неоптимизированном хосте очень существенное ускорение всего сайта, но нужно читать мануалы и запасаться оперативкой.
У меня магазин-каталог без корзины, все закешированно, кешь и дает самый большой прирост. Держит 100000 наименований, оперативки 1гб.
Следующий магазин я на VirtueMart думаю делать не буду, потому как летает только с кешированием.

У себя я поудалял все, что только можно в базе VirtueMart, включая ненужные валюты и какие-то остатки от quickstart шаблона (английские демотовары). Небольшой прирост
Добавил в базе недостающий индекс - получил прирост в 2-3 раза при импорте товаров.
Тюнинг MySQL, описанным выше способом дает на неоптимизированном хосте очень существенное ускорение всего сайта, но нужно читать мануалы и запасаться оперативкой.
У меня магазин-каталог без корзины, все закешированно, кешь и дает самый большой прирост. Держит 100000 наименований, оперативки 1гб.
Следующий магазин я на VirtueMart думаю делать не буду.

Я практически раскошелился на битрих, но руки зачесались ...
А что значит добавили недостающий индекс ?

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

Экспериментирую, отпишусь.

Индексы применяются там, где нужен быстрый поиск в таблице. Добавлял индекс к артикулу товара, т.к. в загрузке, а особенно в обновлении товаров происходил постоянный поиск артикула, а индекса в таблице у него не оказалось.
Почитай про них. Они ускоряют выполнение некоторых запросов, но почти все нужные там вроде есть.
В phpMyAdmin можно на них глянуть.

У битрикса все круто с синхронизацией с 1с, но пожиратель ресурсов он не меньший, если не больший.

Либо на сегодня хватит, либо лишнего не изъять:

Страница в 20 товаров (все каши включены) - 1420 SQL-запросов зафиксировано.
Использование памяти - 29.96 MB (31,413,912 Bytes)

70 типов SQL-запросов зафиксировано, отсортировано по вхождениям

Запросы типа SELECT:

• 101 × SELECT `iam_virtuemart_categories_ru_ru`.* ,`iam_virtuemart_categories`.*
    FROM `iam_virtuemart_categories_ru_ru` JOIN iam_virtuemart_categories using (`virtuemart_category_id`)
  
• 100 × SELECT `iam_virtuemart_products_ru_ru`.* ,`iam_virtuemart_products`.* ,`iam_virtuemart_product_manufacturers`.`virtuemart_manufacturer_id` ,`iam_virtuemart_product_customfields`.`virtuemart_customfield_id`
    FROM `iam_virtuemart_products_ru_ru` JOIN iam_virtuemart_products using (`virtuemart_product_id`)
    LEFT JOIN `iam_virtuemart_product_manufacturers`
    on `iam_virtuemart_product_manufacturers`.`virtuemart_product_id`=`iam_virtuemart_products_ru_ru`.`virtuemart_product_id`
    LEFT JOIN `iam_virtuemart_product_customfields`
    on `iam_virtuemart_product_customfields`.`virtuemart_product_id`=`iam_virtuemart_products_ru_ru`.`virtuemart_product_id`
  
• 100 × SELECT `ordering`,`id`
    FROM `iam_virtuemart_product_categories`
  
• 100 × SELECT pc.`virtuemart_category_id`
    FROM `iam_virtuemart_product_categories` as pc
    LEFT JOIN `iam_virtuemart_categories` as c
    ON c.`virtuemart_category_id` = pc.`virtuemart_category_id`
  
• 100 × SELECT pc.`virtuemart_category_id`
    FROM `iam_virtuemart_product_categories` as pc
  
• 100 × SELECT `slug`
    FROM `iam_virtuemart_products_ru_ru`
  
• 100 × SELECT `iam_virtuemart_medias`.*
    FROM `iam_virtuemart_medias`
  
• 100 × SELECT `virtuemart_shoppergroup_id`
    FROM `iam_virtuemart_product_shoppergroups`
  
• 100 × SELECT `iam_virtuemart_manufacturers_ru_ru`.* ,`iam_virtuemart_manufacturers`.*
    FROM `iam_virtuemart_manufacturers_ru_ru` JOIN iam_virtuemart_manufacturers using (`virtuemart_manufacturer_id`)
  
• 100 × SELECT *
    FROM `iam_virtuemart_product_prices`
  
• 100 × SELECT `virtuemart_media_id`
    FROM `iam_virtuemart_product_medias`
  
• 80 × SELECT field.`virtuemart_product_id`, `custom_params`,`custom_element`, field.`virtuemart_custom_id`, field.`virtuemart_customfield_id`,field.`custom_value`, field.`custom_price`, field.`custom_param`
    FROM `iam_virtuemart_customs` AS C
    LEFT JOIN `iam_virtuemart_product_customfields` AS field
    ON C.`virtuemart_custom_id` = field.`virtuemart_custom_id`
  

Я не жалуюсь на скорость загрузки страницы - она около 2 секунд. Но как по мне - так запросов многовато.

Я не жалуюсь на скорость загрузки страницы - она около 2 секунд. Но как по мне - так запросов многовато.

на каком основании вы сделали вывод, что их "многовато"? 2 секунды, что вас не устраивает?

на каком основании вы сделали вывод, что их "многовато"? 2 секунды, что вас не устраивает?

Я привёл пример с категорией в 20 товаров. Она одна из самых маленьких у меня.
В среднем же, все по 100 позиций и вот их данные: 104 товара - 8882 запроса - 4.5 сек. Согласитесь это уже менее приятные цифры.

104 товара - 8882 запроса - 4.5 сек

Сложно сказать в чем причина на поверхностный взгляд. Попробуйте очистить папку /cache. Бывает, что веб-сервер не может ее очистить, а MySQL обращается к ней. Вы выше писали, что VM1 работает OK. Похоже на то, что  вы переносили сайт с VM2 на VDS c другого хостинга, и Apache работает как модуль PHP, а не в режиме FastCGI. Но Joomla пытается обратиться в /cache, и MySQL сначала идет в нее и долбится в закэшированные в ней запросы. Элементарная проверка - вы можете в админке Joomla очистить кэш? Если нет, интерфейс php-apache какой? Ну в самом деле, неужели VM2 хуже VM1.

Я привёл пример с категорией в 20 товаров. Она одна из самых маленьких у меня.
В среднем же, все по 100 позиций и вот их данные: 104 товара - 8882 запроса - 4.5 сек. Согласитесь это уже менее приятные цифры.

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

Сложно сказать в чем причина на поверхностный взгляд. Попробуйте очистить папку /cache. Бывает, что веб-сервер не может ее очистить, а MySQL обращается к ней. Вы выше писали, что VM1 работает OK. Похоже на то, что  вы переносили сайт с VM2 на VDS c другого хостинга, и Apache работает как модуль PHP, а не в режиме FastCGI. Но Joomla пытается обратиться в /cache, и MySQL сначала идет в нее и долбится в закэшированные в ней запросы. Элементарная проверка - вы можете в админке Joomla очистить кэш? Если нет, интерфейс php-apache какой? Ну в самом деле, неужели VM2 хуже VM1.

Стоял VM1 но и на старом хосте. После я его убил и магазин сейчас сделал с нуля на VM2, взял новый хост. И всё же проверю, спасибо.

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

У меня стоит так сказать One Page Loading. Загружается страница с 18 товарами - далее, при прокрутке страницы вниз, подгружается остальной товар по 9 позиций, пока не кончится.