Перейти к содержанию
Форум поддержки пользователей VamShop

Быстродействие VamShop 1.99.8


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

Есть магазин на вамшоп 1.76:

http://www.superfisher.ru/

8 запросов к БД

Есть этот же магазин, пропатченый до версии 1.99.8:

http://v1.superfisher.ru/

212 запросов к БД

Это как так???

Настройки одинаковые, кэширование работает.

Ссылка на сообщение
Поделиться на другие сайты
8 часов назад, uzUlUgr сказал:

Есть магазин на вамшоп 1.76:

http://www.superfisher.ru/

8 запросов к БД

Есть этот же магазин, пропатченый до версии 1.99.8:

http://v1.superfisher.ru/

212 запросов к БД

Это как так???

Настройки одинаковые, кэширование работает.

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

Это у Вас значит кэш включён и sql кэш в Админке - Настройки - Кэш.

Либо какой-то свой кэш добавлен.

Код остался такой же ведь, что в 1.76, что в 1.99.8

На главной странице разве что добавилось блоков.

А так, к примеру, можно отключить счётчик товаров в категориях в Админке - Настройки - Мой магазин.

Этот подсчёт добавляет много запросов.

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

Может быть и не может быть, но есть, и работает.

Кэш включен на обоих версиях, но разница налицо.

Ради эксперимента  отключал ВСЕ блоки в админке и удалял из index.html вообще весь код - все равно 160 запросов к БД! Это что он такое таинственное делает, и почему это не кэшируется?

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

Ссылка на сообщение
Поделиться на другие сайты
3 часа назад, uzUlUgr сказал:

Может быть и не может быть, но есть, и работает.

Кэш включен на обоих версиях, но разница налицо.

Ради эксперимента  отключал ВСЕ блоки в админке и удалял из index.html вообще весь код - все равно 160 запросов к БД! Это что он такое таинственное делает, и почему это не кэшируется?

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

Ну не может быть 9 запросов на главную страницу никак.

Там только подсчёт количества товаров в категориях - это десятки запросов.

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

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

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

Всякое может быть.

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

Во всяком случае я ничего подобного не делал.

 

Статистика по версиям и запросам такая:

1.76 - 9

1.78 - 65
1.84 - 68
1.98 - 77
1.99 - 154

Время генерации в 1.99 по сравнению с 1.76 больше в два раза.

Прискорбно это всё...

Ссылка на сообщение
Поделиться на другие сайты
2 часа назад, uzUlUgr сказал:

Всякое может быть.

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

Во всяком случае я ничего подобного не делал.

 

Статистика по версиям и запросам такая:

1.76 - 9

1.78 - 65
1.84 - 68
1.98 - 77
1.99 - 154

Время генерации в 1.99 по сравнению с 1.76 больше в два раза.

Прискорбно это всё...

От 1.76 до 1.78 всего 2 обновления, там принципиально в коде ничего не менялось.

и как 9 и 65.

Я не знаю всю историю Вашего магазина, но 9 запросов на главную страницу superfischer.ru - это нереально.

Больше 9 запросов будет только на подсчёт количествоа товаров в категориях которые у Вас слева Разделы.

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

Этого не может быть потому что не может быть никогда, или по какой то другой причине?

Берем логи сервера БД для вамшоп 1.76 и 1.99.8, и видим очевидную разницу.

В обоих случаях открывается главная страница сайта, все кэши включены.

mysql176.log

mysql199.log

Ссылка на сообщение
Поделиться на другие сайты
5 часов назад, uzUlUgr сказал:

Этого не может быть потому что не может быть никогда, или по какой то другой причине?

Берем логи сервера БД для вамшоп 1.76 и 1.99.8, и видим очевидную разницу.

В обоих случаях открывается главная страница сайта, все кэши включены.

mysql176.log

mysql199.log

Второй лог больше похож на реальный.

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

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

В первом логе даже нет запросов на подсчёт количества товаров в категориях.

Как и многого другого.

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

Но при этом все работает. Все блоки прекрасно включаются, список категорий обновляется при добавлении новой.

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

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

Включите SQL кэш в Админке - Настройки - Кэш, буду кэшироваться.

Я вообще не вижу проблемы особой.

Для mysql ни 100, ни 200, ни 2000 запросов не проблема.

Если хостинг нормальный с большим количеством оперативной памяти.

mysql любит именно оперативную память для быстрой работы.

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

Все кэши включены!

Вы плохо представляете, как работает mysql. Ему не нужно много памяти, ему нужно достаточно памяти. Мне на базу в 10 тысяч товаров вполне хватает мегабайт двести памяти, больший выделенный объем никакого ускорения не дает, в некоторых случаях даже наоборот.  Свободную память лучше оставить под системный кэш - апач начинает шустрее работать.

Если mysql настроен правильно, все упирается в быстродействие процессора. Ваши 2000 запросов на несколько секунд заткнут один поток процессора. Если на сайте один посетитель, это не критично, а если несколько - начинаются тормоза. А если не дай боги еще и робот какой нибудь топчется в это время по сайту - вообще абзац. Например сегодня с 11 до 12 роботы сгенерировали 14 миллионов запросов к БД.  

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

 

 

 

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

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

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

Для того чтобы включить, нужно изменить параметр query_cache_type ставим 1.

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

 

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

Без кэша этот говнокод генерирует страницу 15-20 секунд!
Еще раз повторяю 200 мегабайт, если у вас собственный сервер с одной БД, более чем достаточно, что бы туда поместилась вся БД!  Я пробовал выделять 8 гигабайт - работает даже немного медленнее.
Тормоза не из за обращений к диску. Просто не доросли еще современные процессоры до такого качества программирования.

Зачем нужны 70 запросов к таблицам banners и banners_history примерно понятно. Если не судьба их закэшировать, то можно их хоть как то вырезать? Не из шаблона разумеется, а из кода - чтоб не было обращений к БД.
А вот зачем 120 запросов к reviews и reviews_description - уму непостижимо! Особенно учитывая, что у меня этих отзывов всего то шесть штук...

Не поделитесь ли версией vamshop 1.98 - неохота обновлениями накатывать.

 

Ссылка на сообщение
Поделиться на другие сайты
3 часа назад, uzUlUgr сказал:

Без кэша этот говнокод генерирует страницу 15-20 секунд!
Еще раз повторяю 200 мегабайт, если у вас собственный сервер с одной БД, более чем достаточно, что бы туда поместилась вся БД!  Я пробовал выделять 8 гигабайт - работает даже немного медленнее.
Тормоза не из за обращений к диску. Просто не доросли еще современные процессоры до такого качества программирования.

Зачем нужны 70 запросов к таблицам banners и banners_history примерно понятно. Если не судьба их закэшировать, то можно их хоть как то вырезать? Не из шаблона разумеется, а из кода - чтоб не было обращений к БД.
А вот зачем 120 запросов к reviews и reviews_description - уму непостижимо! Особенно учитывая, что у меня этих отзывов всего то шесть штук...

Не поделитесь ли версией vamshop 1.98 - неохота обновлениями накатывать.

 

Закомментируйте в /includes/modules/reviews_all.php строку:

'PRODUCT' => $product->buildDataArray($reviews),

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

http://vamshop.ru/vamshop-demo.zip 

Это текущая версия.

Вырезайте, раз Вам не нужно ничего это.

Удалите содержимое файлов:

/includes/modules/reviews_all.php

/includes/banners.php

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

/includes/modules/reviews_all.php  не при чем - в файле /includes/classes/product.php закоментировал строки:

$reviews_query = vam_db_query("select count(*) as total, TRUNCATE(SUM(reviews_rating),2) as rating from ".TABLE_REVIEWS." r, ".TABLE_REVIEWS_DESCRIPTION." rd where r.products_id = '".(int)$products_id."' and r.reviews_id = rd.reviews_id and rd.languages_id = '".$_SESSION['languages_id']."' and rd.reviews_text !=''");

и

$reviews_query = vam_db_query("select count(*) as total from ".TABLE_REVIEWS." r, ".TABLE_REVIEWS_DESCRIPTION." rd where r.products_id = '".(int)$products_id."' and r.reviews_id = rd.reviews_id and rd.languages_id = '".$_SESSION['languages_id']."' and rd.reviews_text !=''");

и запросов к БД стало не 154 а всего 13! А вы говорите такого не может быть никогда...

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

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

Ссылка на сообщение
Поделиться на другие сайты
5 часов назад, uzUlUgr сказал:

/includes/modules/reviews_all.php  не при чем - в файле /includes/classes/product.php закоментировал строки:

$reviews_query = vam_db_query("select count(*) as total, TRUNCATE(SUM(reviews_rating),2) as rating from ".TABLE_REVIEWS." r, ".TABLE_REVIEWS_DESCRIPTION." rd where r.products_id = '".(int)$products_id."' and r.reviews_id = rd.reviews_id and rd.languages_id = '".$_SESSION['languages_id']."' and rd.reviews_text !=''");

и

$reviews_query = vam_db_query("select count(*) as total from ".TABLE_REVIEWS." r, ".TABLE_REVIEWS_DESCRIPTION." rd where r.products_id = '".(int)$products_id."' and r.reviews_id = rd.reviews_id and rd.languages_id = '".$_SESSION['languages_id']."' and rd.reviews_text !=''");

и запросов к БД стало не 154 а всего 13! А вы говорите такого не может быть никогда...

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

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

Спасибо за отзыв.

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

 

Добавил в раздел Ошибки - 

Что б не потерялось.

Ссылка на сообщение
Поделиться на другие сайты
$reviews_query = vam_db_query("select count(*) as total from ".TABLE_REVIEWS." r where r.products_id = '".(int)$products_id."'");

Объединение таблиц, а главное проверка на != '' - это очень ресурсоёмкий процесс

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

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

Ссылка на сообщение
Поделиться на другие сайты
  • 4 weeks later...
В 01.11.2019 в 10:00, KoVaLsKy сказал:

$reviews_query = vam_db_query("select count(*) as total from ".TABLE_REVIEWS." r where r.products_id = '".(int)$products_id."'");

Объединение таблиц, а главное проверка на != '' - это очень ресурсоёмкий процесс

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

Ссылка на сообщение
Поделиться на другие сайты
1 час назад, Роман_DD сказал:

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

А можно подробнее, где проверка на пустой отзыв?!

Что-то я наверное не совсем понял.

Ссылка на сообщение
Поделиться на другие сайты
1 час назад, support сказал:

А можно подробнее, где проверка на пустой отзыв?!

Что-то я наверное не совсем понял.

ну вот это видимо, вы выше обсуждали and rd.reviews_text !=''");

Ссылка на сообщение
Поделиться на другие сайты
2 минуты назад, Роман_DD сказал:

ну вот это видимо, вы выше обсуждали and rd.reviews_text !=''");

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

Это и добавило кучу запросов.

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

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