Очень долго открывается первая страница блогов

[malik]

У меня отдельный сервер, форум летает, галереи тоже приемлимо работают, а вот блоги...

 

При открытии первой страницы блогов (ссылка - /index.php?automodule=blog) ждать отображения страницы приходится субъективно около минуты. Вне зависимости от загрузки сервера и количества пользователей в онлайн.

Не сталкивался ли кто с такой же проблемой и не находил ли её решения?

 

Блог версии 1.4.0.

2067 локальных блогов.

45887 опубликованных записей и 2693 черновиков.

336117 комментов.

 

Внутри отдельных блогов работает всё шустро.

Спасибо.

[Sannis]

ждать отображения страницы приходится субъективно около минуты

А что говорит время генерации внизу страницы? А что говорит количество запросов и время их выполнения?

[malik]

ждать отображения страницы приходится субъективно около минуты

А что говорит время генерации внизу страницы? А что говорит количество запросов и время их выполнения?

Спасибо, не догадался включить отладку )

Субъективность, как обычно, далека от объективности - "35.9518 сек. -- 13 запросов GZIP включен".

35 секунд, конечно, не минута, но тоже слишком много.

Проблема эта появилась сразу после обновления блогов с 1.3 на 1.4, вместе с изменением оформления первой страницы блогов.

[Sannis]

А что насчёт времени выполнения запросов? (включите 3й уровень и нажмите на ссылку с количеством запросов)

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

[malik]

Сорри, что поднимаю тему, но проблема осталась. Однако появилось интересное уточнение: под гостем список блогов открывается очень быстро, а из-под пользователя жутко медленно.

Очевидно, движок делает какие-то проверки для юзеров, может отмечает прочитанные, новые записи или комментарии.

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

Есть у кого-либо такой опыт?

Спасибо.

[Sannis]

Сорри, что поднимаю тему, но проблема осталась. Однако появилось интересное уточнение: под гостем список блогов открывается очень быстро, а из-под пользователя жутко медленно.

Очевидно, движок делает какие-то проверки для юзеров, может отмечает прочитанные, новые записи или комментарии.

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

Есть у кого-либо такой опыт?

Спасибо.

Сначала ответьте на вопросы, которые я вам задал

[malik]

Сорри, что поднимаю тему, но проблема осталась. Однако появилось интересное уточнение: под гостем список блогов открывается очень быстро, а из-под пользователя жутко медленно.

Очевидно, движок делает какие-то проверки для юзеров, может отмечает прочитанные, новые записи или комментарии.

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

Есть у кого-либо такой опыт?

Спасибо.

Сначала ответьте на вопросы, которые я вам задал

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

А при просмотре из-под гостя нет никакой ссылки Прочее (

[malik]

Эти блоги меня убивают (

Поиски через Гугл приводили и к другим схожим жалобам, даже на сайте Инвижна, там поступили просто - сказали, что в новой версии блогов проблема решена. Обновлять блоги (а с ними и всё остальное) не предлагать - боюсь сервер не потянет 3-ю версию форума.

 

 

Нашёл запрос, время выполнения которого стремится к бесконечности, вот пример:

SELECT b.blog_id, b.member_id, b.blog_name, b.blog_desc, b.blog_type,
b.blog_exturl, b.blog_num_exthits, bl.blog_num_entries, bl.blog_num_drafts,
b.blog_num_views, bl.blog_last_entry,
bl.blog_last_entryname, bl.blog_last_date, bl.blog_num_comments,
bl.blog_last_comment,
bl.blog_last_comment_date,
bl.blog_last_comment_entry, bl.blog_last_comment_entryname,
bl.blog_last_comment_name, bl.blog_last_comment_mid,
b.blog_private, b.blog_pinned,
b.blog_disabled, b.blog_rating_total, b.blog_rating_count,
b.blog_friendly_url, b.blog_allowguests,
case when b.blog_rating_count>1 then
(b.blog_rating_total/b.blog_rating_count) else 0 end as blog_rating,
CASE WHEN b.blog_id
IN(4,9,102,19) THEN 2 ELSE b.blog_pinned END as base_ordering,
m.members_display_name,
br.last_read, bl.blog_last_update, bl.blog_last_entry_excerpt, pp.*
FROM ibf_blog_blogs b
INNER JOIN ibf_members m ON b.member_id=m.id
LEFT JOIN ibf_profile_portal pp ON
b.member_id=pp.pp_member_id
LEFT JOIN ibf_blog_read br ON b.blog_id=br.blog_id AND
br.member_id=5
LEFT JOIN ibf_blog_lastinfo bl ON b.blog_id=bl.blog_id
AND ((bl.cat_level = 'private' AND bl.blog_id=1705) or
(bl.cat_level = 'privateclub' AND bl.blog_id in(9,51))
or (bl.cat_level = 'public' AND bl.blog_id not
in(9,51,1705)))
WHERE (b.blog_private=0 or b.blog_id
in(9,51,1705))
ORDER BY base_ordering DESC,
blog_last_date desc
LIMIT 0, 20

 

Он вызывается из скрипта sources/components_public/blog/list.php вот в этом блоке:

if ( is_array($this->ipsclass->member['g_blog_authed_blogs']) && count($this->ipsclass->member['g_blog_authed_blogs'])>=1 )
{
       $authblogs = implode(",", $this->ipsclass->member['g_blog_authed_blogs']);
       $levelwhere[] = "(bl.cat_level = 'privateclub' AND bl.blog_id in(".$authblogs."))";
       $levelwhere[] = "(bl.cat_level = 'public' AND bl.blog_id not in(".$authblogs.($this->ipsclass->member['_cache']['my_blog']?",".$this->ipsclass->member['_cache']['my_blog']:"")."))"; // QQ (мой комментарий)
}

Моих знаний хватило только на эксперименты с сокращением запроса, в результате серии проверок, пришёл к выводу, что виновата последнаяя часть запроса перед WHERE, в примере это "bl.blog_id not in(9,51,1705)". Я сократил строчку, которую я отметил комментарием QQ, до вот такого вида:

        $levelwhere[] = "(bl.cat_level = 'public')";

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

 

 

 

Может кто-то может посоветовать как бы упростить этот большой запрос или отсеять дубли из списка блогов отдельным запросом?

Спасибо.

[Arhar]

если прикрепленные блоги запрашиваются из базы раньше остальных отдельным запросом, можно сформировать массив их ид

после чего убрать bl.blog_id not in, а вырезать дубли через continue в цикле обработки

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

[malik]

Может кто-нибудь за деньги поправить эту ситуацию - изменить код, так чтобы избежать применение такого тяжёлого запроса?

Я готов заплатить разумные деньги за это.

Потому, что мои знания ПХП не позволяют мне исправить проблему, а она просто убивает мой ресурс - пара таких запросов и всё встаёт колом, прям хоть удаляй нафиг эти блоги.

[Ritsuka]

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

 

Кстати, в данный момент Matt аналогично доводит до ума галерею

Изменено 23 Сентября 2010 пользователем Ritsuka

[malik]

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

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

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