Ужасно тормозит сайт

[shurka023]

Исходные данные таковы, на сайте почти 170000 товаров, сайт расположен на облачном хостинге с такими данными процессор Intel(R) Xeon(R) CPU E5-2667 v3 @ 3.20GHz (4 cores)  2 гига оперативки. Сайт построен на шаблоне unishop, фильтр товаров OCFilter, плюс стоит поиск от автора SergeTkach стоит модуль MicrodataPro, а так же модуль Комплекты серий товаров - наборы товара который не работает и автор не отзывается))) Сайт очень долго грузится, какие могут быть варианты решения этой проблемы и кто может помочь? Ах да и сам сайт ylov.of.by

[splka]

del.
Послушаю.

Змінено 14 січня 2019 користувачем splka

[markimax]

Для 170k уже надо не кешируемый seo_pro - json_decode большого обьема данных жрет много ресурсов

[SiteMix]

39 минут назад, shurka023 сказал:

на сайте почти 170000 товаров, сайт расположен на облачном хостинге

Совсем недавно @Yoda писал о подобной ситуации. Ту тему сходу не нашёл, но он там писал, что на облачном хостинге из-за репликации между серверами возникают дополнительные задержки в работе сайта.

Возможно он сам заглянет и прокомментирует. А то я мог исказить суть.

[Yoda]

46 минут назад, SiteMix сказал:

Совсем недавно @Yoda писал о подобной ситуации. Ту тему сходу не нашёл, но он там писал, что на облачном хостинге из-за репликации между серверами возникают дополнительные задержки в работе сайта.

Возможно он сам заглянет и прокомментирует. А то я мог исказить суть.

Загляну.

1. От 100к товаров по хорошему нужен дедик. Так как ВПСы не справляются ни с io операциями диска, ни с быстрой обработкой  mysql-запросов, которая упирается и в io и в  скорость ядер. А тут даже не ВПС а опять же облако с непонятной системой виртуализации, с диким оверселингом с HyperThreadingом и так далее. Вобщем это первая печаль.

И не говорите мне, что нет трафика. БОТЫ ВЕЗДЕСУЩИ.

2. 2 гб памяти... Ну ок. Скорее всего там стоит 512мб а то и гиг на поток-php (ведь товары откуда то взялись, их парсили, а парсеры прожорливые до памяти). Даже если 512мб, куда то надо еще деть системные ресурсы. В итоге у нас есть ресурсов на 3 паралельных http-потока для клиентов. А от ботов запросов я думаю больше (см п.1)

3. Ладно, допустим, нет проблем с io, есть ресурс процессора, и есть в достатке память. Скорее всего есть большие категории, овер 10к товаров, в которых getProducts и getProductTotal выполняются 2-3-5 сек каждый. А если еще открыта пагинация для индексирования, то на крайних лимитах, на порядок дольше, так как чем больше лимит с сортировкой, тем больше базе приходится сканить данных из таблицы. 
И у нас уже даже не 3 потока в секунду может отработать система, а 1. Когда на web-сервер приходит очередь запросов, они в нее стали и выели все реусрсы процессора. А еще у нас же есть всякие update  в таблицу product.

Продолжать могу бесконечно...

 

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

 

 

 

 

 

 

[Soong]

6 минут назад, Yoda сказал:

Загляну.

1. От 100к товаров по хорошему нужен дедик. Так как ВПСы не справляются ни с io операциями диска, ни с быстрой обработкой  mysql-запросов, которая упирается и в io и в  скорость ядер. А тут даже не ВПС а опять же облако с непонятной системой виртуализации, с диким оверселингом с HyperThreadingом и так далее. Вобщем это первая печаль.

И не говорите мне, что нет трафика. БОТЫ ВЕЗДЕСУЩИ.

2. 2 гб памяти... Ну ок. Скорее всего там стоит 512мб а то и гиг на поток-php (ведь товары откуда то взялись, их парсили, а парсеры прожорливые до памяти). Даже если 512мб, куда то надо еще деть системные ресурсы. В итоге у нас есть ресурсов на 3 паралельных http-потока для клиентов. А от ботов запросов я думаю больше (см п.1)

3. Ладно, допустим, нет проблем с io, есть ресурс процессора, и есть в достатке память. Скорее всего есть большие категории, овер 10к товаров, в которых getProducts и getProductTotal выполняются 2-3-5 сек каждый. А если еще открыта пагинация для индексирования, то на крайних лимитах, на порядок дольше, так как чем больше лимит с сортировкой, тем больше базе приходится сканить данных из таблицы. 
И у нас уже даже не 3 потока в секунду может отработать система, а 1. Когда на web-сервер приходит очередь запросов, они в нее стали и выели все реусрсы процессора. А еще у нас же есть всякие update  в таблицу product.

Продолжать могу бесконечно...

 

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

 

 

 

 

 

 

home-plitka.ru
Летает 120к товаров. Без каких либо "шаманств"  мои знания в этой сфере на уровне junior.
Есть еще несколько похожих сайтов ) 

[Yoda]

Круто летает! Научите меня?

[Yoda]

33 минуты назад, Soong сказал:

home-plitka.ru
Летает 120к товаров. Без каких либо "шаманств"  мои знания в этой сфере на уровне junior.
Есть еще несколько похожих сайтов ) 

 

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

Вы показываете не реальную работу магазина, а скорость отдачи сервером готовых html-страниц. 
Если у вас дай бог, когда нибудь появится 20-30 посетитилей онлайн, у вас все ляжет, так как скорость генерации страниц без кеша у вас далеко не фонтан.

Сколько ресурсов вы тратите на прогрев, и есть ли у вас возможность оперативно актуализировать каталог - это тоже открытый вопрос, о котором вы умалчиваете. 

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

Ну и с такой мелкой сегментацией, ваш магазин ни чем не отличается от магазина на 3000 товаров.

 

[markimax]

Ну заддосить магазин много ума не надо. Дать пул по поиску и "ложим" любой, учитывая еще и ресайз новых изображений.
Я замечу что на одном логине работало 120k и 70k на обычном шареде и на холодную  у товара в районе 0.4-0.9 и без шаманства (если без ресайза). На категориях, смотря сколько в категориях товаров но не более 1.5 при нормальном сценарии посещений, а в среднем до секунды. На обычном шареде с фильтром. Просто не надо захламлять свои магазины.

100 уников одновременно

https://loaddy.com/result/307817473/
 

[SooR]

@shurka023 , уберите ссылку на панель управления.

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

Если не поможет - обращайтесь за $$$ к специалистам.

Профайлер можете попробовать мой.

 

 

ocfilter.querylog.2.3.ocmod.xml

ocfilter.querylog.2.1.ocmod.xml

[Yoda]

Вооот. А я говорил. Сейчас будет рекламная акция волшебной мази.

Как обычно сплошное введение в заблуждение. 

 

Попробую на пальцах открыть фокусы фокуснкиков:

2-3-4к товаров в категории - это не нагрузка, так как все запросы в таблицы товаров сегментированы по id категории и представляют из себя небольшой набор. Тем более у @SooR для версии  2.3 отличный фильтр который отлично переваривает за счет использования сводных таблиц подобные задачи.

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

 

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

 

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

 

И самое потрясающее передергивание - это рассказывать про то что летает на "шареде". Как известно у beget под базы данных как раз на шареде стоят отдельные оооооочень мощные сервера, судя по всему с огромным количеством памяти. Это позволяет показывать одномоментные очень быстрые результаты. Но шаред он и в африке шаред. И балансировщики ресурсов не спят. Поэтому ни на одном шареде невозможно построить стабильную быструю нагруженную систему.

 

Вобщем друзья мои, не все то золото, что блестит.

 

[Soong]

17 минут назад, Yoda сказал:

Вооот. А я говорил. Сейчас будет рекламная акция волшебной мази.

Как обычно сплошное введение в заблуждение. 

 

Попробую на пальцах открыть фокусы фокуснкиков:

2-3-4к товаров в категории - это не нагрузка, так как все запросы в таблицы товаров сегментированы по id категории и представляют из себя небольшой набор. Тем более у @SooR для версии  2.3 отличный фильтр который отлично переваривает за счет использования сводных таблиц подобные задачи.

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

 

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

 

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

 

И самое потрясающее передергивание - это рассказывать про то что летает на "шареде". Как известно у beget под базы данных как раз на шареде стоят отдельные оооооочень мощные сервера, судя по всему с огромным количеством памяти. Это позволяет показывать одномоментные очень быстрые результаты. Но шаред он и в африке шаред. И балансировщики ресурсов не спят. Поэтому ни на одном шареде невозможно построить стабильную быструю нагруженную систему.

 

Вобщем друзья мои, не все то золото, что блестит.

 

Дружище. Я не профи и спорить с тобой не буду. Но могу скзаать одно, что при минимальных вложениях ( столько стоит "мазь" ) сайт начал "летать" и продает, что еще нужно? Я привел пример для того , что бы показать , что "мазь" работает, Марки вкурсе все сайты с его модулем летают.
Еще хочу сказать, что я даже не думаю сомневаться в твоей мощи. Видно ты "заряженный" , я не такой и 50к на ускорение каждого из 10 магазинов у меня нет. А судя по твоему общению 50к это для старта )) 

Змінено 14 січня 2019 користувачем Soong

[Soong]

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

[Yoda]

10 минут назад, Soong сказал:

Дружище. Я не профи и спорить с тобой не буду. Но могу скзаать одно, что при минимальных вложениях ( столько стоит "мазь" ) сайт начал "летать" и продает, что еще нужно? Я привел пример для того , что бы показать , что "мазь" работает, Марки вкурсе все сайты с его модулем летают.
Еще хочу сказать, что я даже не думаю сомневаться в твоей мощи. Видно ты "заряженный" , я не такой и 50к на ускорение каждого из 10 магазинов у меня нет. А судя по твоему общению 50к это для старта )) 

Вы меня извините. Но дружища, у вас в подьезде...

В таком тоне - говорите с ними.

 

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

https://github.com/budgetneon/v2pagecache, то мне откровенно вас жалко. К сожалению вот из-за таких фанатов сказок как вы, которые некомпетентно хвалят бесполезные решения, многие и многие владельцы магазинов гробят свой бизнес.

 

И если вы не профи, к чему эти "советы", это как гемморой огурцом лечить посоветовать. Тоже ведь кому-то помогает. 
И все таки я просил показать хотя бы 20 000 товаров в категории с фильтром - не увидел. На данный момент у нас есть проект в котором 570 000 товаров в одной категории с фильтром с 20 параметрами, с временем генерации без кеша менее полутора секунд. 
Как вы считаете, я тоже не профи? 

 

 

 

 

[shurka023]

Из всего выше сказанного я понял что необходимо менять хостинг с облачного на выделенный сервер для начала, тогда встает вопрос какие у него должны быть параметры для стабильной работы. И да забыл сказать что это домен тестовый для разработки а вернее переделки сайта. Если перенести сейчас на основной рабочий домен то там посещаемость 200 человек в сутки. А вот следующим этапом должно быть настройка сервера и уже потом чистка кода сайта для поднятия его уровня в пэйджспид. Это мое видение из того что вы выше тут наговорили. А мое мнение по поводу всех модулей ускорения, это на подобии виртуального хостинга, он вроде и хостинг но только для побаловаться. Советуйте параметры сервера тогда под такой проект.

[markimax]

1 час назад, shurka023 сказал:

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

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

[shurka023]

 

27 минут назад, markimax сказал:

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

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

[chukcha]

3 минуты назад, shurka023 сказал:

вот и спрашиваю какие параметры будут оптимальными

 

Цитата

— Воркута.
— Почему Воркута?
— А я там сидел.
— Ну хорошо. А ты, значит, на «а».
— Джамбул…
— А причём тут Джамбул?
— Потому что там тепло. Там мой дом, там моя мама.

 

 

34 минуты назад, markimax сказал:

Все должно быть сделано системно.

 

[uncle]

В 15.01.2019 в 00:01, SiteMix сказал:

Совсем недавно @Yoda писал о подобной ситуации. Ту тему сходу не нашёл, но он там писал, что на облачном хостинге из-за репликации между серверами возникают дополнительные задержки в работе сайта.

Возможно он сам заглянет и прокомментирует. А то я мог исказить суть.

Вот оно как.... У меня вот ситуация такая - взял самый дешевый облачный хостинг за 4 бакса с абсолютным пониманием, что по мере роста придется апгрейдиться. Думал, пока установлю (опыта очень мало с опенкартом), разберусь пусть самый простенький побудет. В общем, установил версия 2.3.0.2.3. Решил посмотреть сразу скорость загрузки, и немного опечалился. Скорость от 2 до 4 секунд, смотря из какой страны проверялось. Да, я понимаю - много ожидать от дешового облака глупо. Но ведь и сайт еще на голом движке, а уже такие показатели. :(

То получается лучше сразу на VPS переезжать? Облако для опенкарт боль?

Специфика у сайта такая, что если в день будет 1000 посетителей, то это будет ошеломляющий успех. Ну и товаров будет 2-3 тысчи. Понятное дело дедик брать ну совсем не разумно в данном случае.

[Triffids]

22 часа назад, uncle сказал:

Вот оно как.... У меня вот ситуация такая - взял самый дешевый облачный хостинг за 4 бакса с абсолютным пониманием, что по мере роста придется апгрейдиться. Думал, пока установлю (опыта очень мало с опенкартом), разберусь пусть самый простенький побудет. В общем, установил версия 2.3.0.2.3. Решил посмотреть сразу скорость загрузки, и немного опечалился. Скорость от 2 до 4 секунд, смотря из какой страны проверялось. Да, я понимаю - много ожидать от дешового облака глупо. Но ведь и сайт еще на голом движке, а уже такие показатели.

То получается лучше сразу на VPS переезжать? Облако для опенкарт боль?

Специфика у сайта такая, что если в день будет 1000 посетителей, то это будет ошеломляющий успех. Ну и товаров будет 2-3 тысчи. Понятное дело дедик брать ну совсем не разумно в данном случае.

у меня гуглоклауд, причем попробовал и на google SQL gen 1 базу поставить. тоже от 2 секунд страница, при этом ресурсы практически не заняты. там все плохо в архитектуре опенкарт 2.3. вместо одного запроса в цикле долбит базу миллионом запросов, запросы откровенно кривые - bind переменных не используется, бедный mysql вынужден парсить весь миллион запросов каждый раз.

[chukcha]

3 минуты назад, Triffids сказал:

там все плохо в архитектуре опенкарт 2.3. вместо одного запроса в цикле долбит базу миллионом запросов, запросы откровенно кривые -

Что это?

1. откуда миллион
2. причем здесь бинд?
 

[chukcha]

5 минут назад, Triffids сказал:

запросы откровенно кривые

Сделайте Неоткровенно прямыми.. Кто вам мешает? Вы, видимо, знаете как.