Советы по оптимизации VaM Shop

[support 447]

Нормально, я думаю.

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

[geval 3]

Поменять полностью логику работы страницы. Сейчас этот запрос обрабатывает ВСЕ заказы. Нужно ли Вам сразу смотреть все 20 тысяч заказов?  Практически нет. А если все же нужно, то надо их посматривать порциями, то есть делать разбивку по страницам. И добавлять фильтр по свойствам.  Это азбука построения сайтов с большими объемами информации.

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

магазин версии 1.54, сегодня столкнулись с тем, что при размере таблицы orders_products больше 100 000 значений ( магазин семян и в каждом заказе 30-100 позиций, получается одним заказом занимаем сразу 100 строк) безбожно всё тормозит, нагрузка сервера вырастает до 50% стабильно, mysql забирает все запросы..

на другом таком же сервере- где нет таких заказов- но такая же посещаемость- 0,5-1% загрузки. разница в 50-100 раз получается, только изза того, что в магазине столько заказов!!!

ну как это называется?

кто-то может решить проблему?

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

уже про это писал тут, но уважаемый Vam не отреагировал.

http://vamshop.ru/forum/index.php?topic=8057.0

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

а вот заказы очищать как-то не ахти..

[support 447]

А с чего Вы это решили, что "только изза того, что в магазине столько заказов!!!".

Каким образом Вы это выяснили, желательно в деталях.

У меня есть доступ к 2 примерно одинаковым магазинам, где в сутки более 100-150 заказов и в архиве магазина более 30.000 у одного и у другого более 50.000 заказов и вот же странно, но почему-то всё работает и без переделок каких-либо.

[geval 3]

всё элементарно.

обнаружил что сервер по команде top показывает 100-200% загрузку mysql, процессор в целом на 50-60% загружен, тогда как на другом сервере - те же магазины, та же посещаемость- эти цифры примерно в 50-100 раз меньше.

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

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

смотрю дальше- вижу еще таблицу orders_products где 140 000 записей!!!! чищу её и

в 50 раз нагрузка сервера снижается..как по волшебству..

но поскольку в этой таблице были заказы- и она была связана с другими таблицами orders* , то в админке пропадают заказы...

дело в том-что это магазин семян- в нем бывает в заказе до 100 наименований.. то есть реально 1400 заказов к примеру- генерят 140 000 полей..

непонятно- с какого перепугу идет такое грузилово- если в админку не заходит админ..

может потому что даже простой юзер заходя в магазин- заставляет магазин запросами перебирать все 140 000 запросов? если бы не выд.сервер- это бы всё упало.. хотя и так нехило на 50% грузить сервер..

P.S. это версия 1.54 а у вас?  и у вас точно больше 100 000 полей в заказах?

[support 447]

Ну а почему 100% загрузка вы выясняли?!

На таблицу orders_products смотрели, индексы в таблицу добавляли.

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

100.000 полей или записей в таблице?!

Записей конечно больше.

[geval 3]

еще раз повторяю- у меня выделенный сервер!! мой полностью. сервер оптимизирован серьезным образом серьезным человеком ( у которого больше 100 положительных отзывов в таких случаях)

памяти 4 GB, сервер в целом очень мощный, магазинов и сайтов много.

вот сейчас программист проводил оптимизацию именно с этой таблицей ( по взаимодействию с ней) и нагрузка в итоге на весь сервер- упала в 10-20 раз.

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

orders_products 139,748

вот так оно выглядит в phpmyadmin

[geval 3]

кстати еще стали смотреть..выяснилось что идет примерно 1000 mysql запросов при заходе в товар, с учетом что это версия 1.54, а есть файлы от версии 1.56 чтобы можно было заменить именно для уменьшения числа запросов, ведь как я понял с 1.56 версии именно пошли улучшения.

[support 447]

Без доступов я всё равно ничего сказать не могу.

Никаких 1000 запросов по умолчанию в VaM Shop при заходе в товар никогда не было.

[geval 3]

так потому что версия 1.54, в ней было много изменений, поэтому и нужны файлы- которые решили вопрос проблемы обращения к категориям..

в ЛС отправил ссылки подтверждающие количество запросов.

[support 447]

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

Поставьте хотя бы бокс разделы текущий.

Файлы:

/templates/vamshop/boxes/box_categories.html

/templates/vamshop/source/inc/vam_show_catego.inc.php

/templates/vamshop/source/boxes/categories.php

[geval 3]

спасибо.

[ABerezin 0]

смотрю дальше- вижу еще таблицу orders_products где 140 000 записей!!!! чищу её и

в 50 раз нагрузка сервера снижается..как по волшебству..

но поскольку в этой таблице были заказы- и она была связана с другими таблицами orders* , то в админке пропадают заказы...

дело в том-что это магазин семян- в нем бывает в заказе до 100 наименований.. то есть реально 1400 заказов к примеру- генерят 140 000 полей..

непонятно- с какого перепугу идет такое грузилово- если в админку не заходит админ..

может потому что даже простой юзер заходя в магазин- заставляет магазин запросами перебирать все 140 000 запросов? если бы не выд.сервер- это бы всё упало.. хотя и так нехило на 50% грузить сервер..

1. Бокс download включен? Если он нужен, то стоит его слегка подкорректировать - прежде чем "перелопатить" 140 000 записей нужно проверить, а зарегистрирован ли пользователь.

Кстати, там проблема с зачисткой переменной $last_order в запросе:

$last_order = $_GET['order_id'];
...
AND o.orders_id = '" . $last_order . "' [/code]
Впрочем, Саша почему-то не считает такие дыры проблемой. :(
2. Попробуйте отключить Also Purchased на странице товара. Там "тяжёлый" запрос. Если отключение поможет, значит нужно поработать над запросом.
Чтобы проводить серьёзную оптимизацию - нужно ставить соответствующий инструментарий (профайлер), проводить обследования, собирать статистику, анализировать, ставить эксперименты. Результат - не только оптимизированные запросы, но и улучшается кеширование запросов на разных уровнях, начиная от сервера БД. Работа длительная, сложная, дорогая.

[HP 0]

Приветствую! Коды удалять и менять конечно хорошошо! вот сайт размещается на nic.ru, использование памяти 145 Мб при запросе, по тарифу положено 128 Мб предлагают  поставить NGINX, может не в тему,хотел услышать мнения, стоит это делать или нет?

[support 447]

Попробуйте, если есть возможность переключаться между веб-серверами, то если что - вернётесь на apache или какой там сейчас сервер.

[ABerezin 0]

nic.ru - мягко говоря не лучший выбор.

Если nginx в качестве прокси, то несомненно нужно ставить.

Если в качестве веб-сервера, то не стоит - как минимум там не будет работать .htaccess.

[maxvalen 0]

Наоптимизировался блин(хотя лучше подойдет другое слово), короче включил кэш базы данных в настройках логи, в админке вылетела вот такая фигня:Warning: error_log(/var/log/www/tep/page_parse_time.log) [function.error-log]: failed to open stream: No such file or directory in /home/virtwww/w_a-seven-ru_b0748f2d/http/inc/vam_db_query.inc.php on line 42

Теперь в админке не работает цсс меню с выпадающими списками и я не могу никуда зайти.Блин.

А в каталоге в верху страницы, вот такая:

Warning: error_log(/var/log/www/tep/page_parse_time.log) [function.error-log]: failed to open stream: No such file or directory in /home/virtwww/w_a-seven-ru_b0748f2d/http/inc/vam_db_query.inc.php on line 42

Что делать теперь?

[support 447]

Создайте например файл 1.log

и в Админке - Настройки - Логи укажите правильный путь к этому файлу.

Либо отключите запись логов.

[maxvalen 0]

В том то и дело, что не могу я в админке ничего сделать, подпункты не показываются, не работает ява и css. А 1.log куда кидать?

[support 447]

Куда угодно, например в корневую папку.

Если через админку не получается, то тогда наверное лезть в базу данных, в таблицу configuration и там менят значения, найдёте как раз по значению /var/log/www/tep/page_parse_time.log

Там видно будет, когда через phpMyAdmin смотреть будете.

[maxvalen 0]

Я честно признаться ничего не понимаю в phpAdmin, поэтому лезть туда боюсь.

[support 447]

Вообще Вы наверное что-то не то сделали, css ведь не может слететь из-за включения/отключения опции в админке.

[maxvalen 0]

Я вот в админке-настройки-логи, включил повключал все чекбоксы, и вылетели у меня эти сообщения до горизонтального меню и после, поэтому подпункты не показывались. Кинул я фаил 1.лог в корневую папку и через командную строку ввел название подкатегории в админке, прописал путь, и все стало на свои места. Спасибо за оперативный ответ.

[support 447]

Только Вы лучше отключите запись в лог, зачем Вам в рабочем магазине писать всё в лог?

[wcp 11]

кхм...

посетителей нет, магазин в процессе затачивания под себя, на главной:

Время генерации: 0.204, запросов: 183

Многовато запросов-то?

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

[support 447]

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