SmartCJ Support Forum

Posted: **Tue Aug 15, 2023 1:31 pm**

попробую на сл неделе уже добавить отдельно кеш для этого тага

Posted: **Sun Aug 27, 2023 12:27 pm**

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

Posted: **Thu Oct 26, 2023 9:20 am**

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

Сейчас <model_list> только на галереях (content_custom_flv, content_custom_pic, content_page).
И вот когда нагрузка на проц нормальная - и запросы эти отрабатывают быстро. Но как только нагрузка на проц подрастает - запросы висят по 3-4 минуты.
Я прекрасно понимаю, что нужно решать проблемы с загруженным процом, и они решаются. Но я всё же хочу понять, внести ясность так сказать.
1. Почему всё же нельзя кешировать "на вечно" принадлежность модели к галерее ? Это займёт много места в кеше ? А есликешировать только основное: model_id, model_slug, model_name , а уж остальное стягивать из мускуля, если нужно. Хотя да.... как понять, что нужно. Но всё же, я бы подумал в эту сторону.

2. Запросы эти реально странные. Давайте разберём конкретный пример.
Есть у меня галерея, с gallery_id=21593. У этой галереи две модели:

Code: Select all

select * from rot_gal2model where gallery_id=21593;
+------------+----------+
| gallery_id | model_id |
+------------+----------+
|      21593 |      777 |
|      21593 |     6895 |
+------------+----------+

Но когда я прогружаю эту страницу, запрос в мускуле выглядит так:

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 ('553','1791')  ORDER BY  model_name  ) 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  WHERE 1 = 1

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

Code: Select all

+-----------+----------+-----------+----------+---------+------+--------------+------------------------------------------------------------------------------------------------------+----------+
| Id        | User     | Host      | db       | Command | Time | State        | Info                                                                                                 | Progress |
+-----------+----------+-----------+----------+---------+------+--------------+------------------------------------------------------------------------------------------------------+----------+
| 147923767 | srv18039 | localhost | srv18039 | Query   |    0 | Init         | show processlist                                                                                     |    0.000 |
| 148048458 | srv18039 | localhost | srv18039 | Query   |   87 | Sending data | SELECT  md.*, m.model_id as model_id, m.model_slug, m.model_name,

87сек, и более, до 4 минут. Та даже при относительно свободном проце такой запрос выполняется (у меня) 3-4 секунды.

Если же запрашивать инфу только для просматриваемой галереи (/scj/tube/?gallery_id=21593):

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 ('777','6895')  ORDER BY  model_name  ) 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  WHERE 1 = 1

- такой запрос за секунду, даже при нагруженном проце.
Считаю это багом. Пофикстие плиз.

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

Posted: **Thu Oct 26, 2023 10:02 am**

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

Posted: **Thu Oct 26, 2023 11:45 am**

Отправил в PM

Posted: **Thu Nov 02, 2023 10:51 am**

наконец подняли важную тему!!! Ждем апдейта

SmartCJ Support Forum

Подсчёт кол-ва галер для модели

Re: Подсчёт кол-ва галер для модели

Re: Подсчёт кол-ва галер для модели

Re: Подсчёт кол-ва галер для модели

Re: Подсчёт кол-ва галер для модели

Re: Подсчёт кол-ва галер для модели

Re: Подсчёт кол-ва галер для модели