SmartCJ Support Forum

Posted: **Tue Jun 13, 2023 8:11 am**

Незнал как назвать топик но все же
Интересует как сделать в плане произвоительности лучше
задача, дернуть к примеру 38 моделей из базы один раз и разбить их по странице
условно так

<models order=ctr num=1-38 gallery_count_min=1 first_letter=GET_first_letter model_has_photos=true adjust_num_to_page=true>
<article class="ths-alt">
<a class="ths-preview-link" href="/model//">
<figure class="vertical">
<amp-img src="<model_photos num=1></model_photos>" alt="" width="400" height="605" layout="responsive"></amp-img>
</figure>
<h3></h3>
</a>
</article>
</models>

дальше вывод по странице
<models 1-2>
if models 1 true <article class="native"></article>
<models 3-10>
if models 5 true <article class="native"></article>
........

где в примере выводим моделей 1-2 и дальше провеярем есть ли на странице модель 1 тогда показываем рекламу

даллее выводим моделей 3-10 и после этого проверяем была ли на странице выведена модель 5 и тогда показываем рекламу

про рекламу можно через цсс конечно делать но тогда у брокера будет дергание кода и показ по которому цпм будет хуже

Posted: **Tue Jun 13, 2023 1:02 pm**

вариант в лоб это условно

$var1 = '<models 1-2>';
$var2 = '<models 3-10>';

и потом уже делать

if ($var1) {
echo $var1;

}

if ($var2) {
echo $var2;

}

Posted: **Tue Jun 13, 2023 4:26 pm**

ну все равно будет куча запросов к бд, подумай на досуге как сделать лучше

Posted: **Tue Jun 13, 2023 8:26 pm**

почему куча? и что именно тормозит?

Posted: **Wed Jun 14, 2023 1:06 pm**

можно вынести
$var1 = '<models 1-2>';
$var2 = '<models 3-10>';
$varN

но это все равно N запросов (как я понял каждый макрос живет сам по себе и сам запрашивает данные. Если не так, то ссорян)

Потому и вопрос - а как можно дернуть всех за 1 раз, а потом распихать эту выдачу по странице.

<models 1-2> декларативный же. Может пусть <models 10-30> выберет 30 и внутри сделать возможность задавать подмакросы для выборки частей из этой выборки (а может такое уже есть). Лишь бы внутренние if также работали.

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

А тормозит из-за запроса. Лог долгих запросов показал что там есть запросы вида

Code: Select all

SELECT  md.*, m.model_id as model_id, m.model_slug, m.model_name,
        gi.url, gi.gallery_id, 
        rt.thumb_id, rt.height, rt.width, rt.thumb_url, rt.extra_thumb, rt.extra_thumb2, rt.extra_thumb3,
        m.model_total_galleries, md.model_average_ctr 
        
FROM rot_models as m

 JOIN rot_models_data as md ON m.model_id = md.model_id and site_id = '1'
 LEFT JOIN rot_gallery_info as gi on gi.url = m.model_id AND gi.gallery_type = 2 and gi.source_url = '1'
 LEFT JOIN rot_thumbs AS rt ON rt.gallery_id = gi.gallery_id  
 
WHERE 1 = 1  
    AND m.model_id IN (SELECT CAST(url as UNSIGNED)  FROM rot_gallery_info WHERE gallery_type = 5)  
    AND m.model_total_galleries >= 1 
    
ORDER BY  md.model_average_ctr DESC  
LIMIT 1000, 6

И вот такой выполняется аж 8 секунд. И если каждый $varN по 8 секунд....

Как я понимаю тут проблема ORDER BY ... OFFSET ... Чем больше смещение,тем больше тормозит. Предельное время - 14 секунд на запрос ибо данные просто заканчиваются.

В общем то даже если сделать возможность выбрать 1 раз, то все равно долго. Я погуглил варианты оптимизации и по примеру https://habr.com/ru/articles/217521/ попробовал переписать так (если ничего не напутал - с SQL дело имею крайне редко)

Code: Select all

SELECT md.*, m.model_id as model_id, m.model_slug, m.model_name,
        gi.url, gi.gallery_id, 
        rt.thumb_id, rt.height, rt.width, rt.thumb_url, rt.extra_thumb, rt.extra_thumb2, rt.extra_thumb3,
        m.model_total_galleries, md.model_average_ctr 
        
FROM rot_models as m

  JOIN (SELECT m2.model_id AS mod_id
			FROM rot_models AS m2
			JOIN rot_models_data as md2 ON m2.model_id = md2.model_id and site_id = '1'
			WHERE 1 = 1  
			    AND m2.model_id IN (SELECT CAST(url as UNSIGNED)  FROM rot_gallery_info WHERE gallery_type = 5)  
			    AND m2.model_total_galleries >= 1 
			    
			ORDER BY  md2.model_average_ctr DESC  
			LIMIT 1000, 6) AS b ON b.mod_id = m.model_id
			
 JOIN rot_models_data as md ON m.model_id = md.model_id and site_id = '1'
 LEFT JOIN rot_gallery_info as gi on gi.url = m.model_id AND gi.gallery_type = 2 and gi.source_url = '1'
 LEFT JOIN rot_thumbs AS rt ON rt.gallery_id = gi.gallery_id

И этот запрос выполняется за 0,062 сек

Правда получился не совсем эквивалент в выдаче. В оригинальном запросе смещение идет для результата JOIN (который имеет больше строк за счет LEFT JOIN rot_thumbs, которых может быть больше 1), но логически же результат валиден по идее. Ну может выдать больше 6 из-за 2+ gallery_id для одного model_id

Такое же наверное и с запросами для first_letter='A'

Posted: **Wed Jun 14, 2023 1:24 pm**

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

SmartCJ Support Forum

Правильный вывод страницы

Правильный вывод страницы

Re: Правильный вывод страницы

Re: Правильный вывод страницы

Re: Правильный вывод страницы

Re: Правильный вывод страницы

Re: Правильный вывод страницы