phpbb debug при отправке поста - есть ли возможность включить?

[Andex]

Столкнулся с долгой отправкой поста в ряд больших топиков (1000+ постов)

Решил глянуть, в каком именно место затык, но понял, что phpbbшный debug тут не поможет, т.к. при отправке POST-запроса на сервер, данные в бд инсертятся, после чего происходит редирект на страницу темы. Возможно ли как-то включить дебаг для данного случая, чтобы мне вывалились соотвествующие данные вместо редиректа?

[Татьяна5]

Т.е. более 100 страниц в теме? Даже на чистом phpBB действия с такими темами могут тормозить (если, конечно, форум не на мощном выделенном сервере)

[Sheer]

(1000+ постов)

Всему есть предел, здравому смыслу тоже (c)
Разделите тему не несколько.

[Andex]

Татьяна5, ну сервер выделенный конечно. страниц там например 50, т.к. побито по 20, собственно, это сути дела не меняет. Не мне ж вам рассказывать, что есть куча phpbb-форумов, которые живут и при тыщах страниц. Понятно дело, что там свои соотв. модификации в т.ч.

1000 постов это большая тема? та ну...

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

[Татьяна5]

1000 постов это большая тема? та ну...

Да, большая
Где темы больше - отказываются от всех модов/расширений и от некоторых стандартных "плюшек" (вроде допполей в теме и подписей) чтобы оно вообще приемлемо работало. (Встречались такие форумы)

как отдебажить сей момент

Отключением расширений, определением что именно тормозит (если это они), а дальше лезть в код

[Andex]

Татьяна5, Дело не в расширениях (тем более, что они все кроме одного писаны мной самим и я понимаю, что там происходит)

Вы уводите вопрос не в ту сторону, я лишь спросил, можно ли как-то вывалить дебажную информацию (вот эти вот EXPLAIN запросов в частности) после POST-запроса (posting.php?mode=reply), чтобы меня не редиректнуло, а отдало страницу с этими данными вместо редиректа. Т.е. меня интересует именно информация во время выполнения posting.php при добавлении поста, а не последующая страница темы, на которую редиректит.
Мне подумалось, что раз уж разработчики сделали возможность дебага, то может быть есть какая-то возможность (о которой я не знаю), получить эти данные и в нужном мне случае (ведь время отправки поста это не менее важная информация, чем время генерирования страницы).

Лезть в код - понятное дело. Но:
В данном случае я практически уверен, что затыки в sql (mysql в частности), а не в php
Да, я конечно могу включить полные sql-логи и т.д. и попробовать поискать там
Но вы должны понимать, что это происходит на продакшеновом сервере, и для того, чтобы повторить эту ситуацию, мне нужно это все анализировать там же, в то же время, когда параллельно на форуме висят 500 пользователей и тыкают БД, поскольку локально, или если форум закрыть - то все зашуршит намного быстрее и будет непоказательным. И если SELECTы я еще смогу проверить на время их выполнения, то с инсертами/апдейтами такой фокус не пройдет, т.к. это нарушит целостность БД. Соответственно, думал как-то получить в реальном времени эти EXPLAIN.


Что касается больших форумов, вы недооцениваете phpbb Вот вам пара форумов (правда 3.0), с более чем базовой функциональностью (может где-то что-то и откл. конечно, но основные фичи работают) Дада, конечно, они перепилены вдоль и поперек, но это не относится к моему вопросу о том, как получить стандартными средствами phphbb дебажную инфу вместо редиректа
http://forum.finance.ua/topic74.html (66 тыс. постов в теме, как вам?)
https://forums.overclockers.ru/viewtopi ... 3&t=519805 (45 тыс.)

[Anvar]

Если временно проверить, то идём в posting.php

И закомментируем:

Код: Выделить всё

meta_refresh(10, $redirect_url);

Код: Выделить всё

redirect($redirect_url)

[Andex]

Anvar, Да эт само собой

В общем, получил то, что хотел. Решение оказалось максимально простым - в форме отправки поста просто в action дописываем &explain=1 и получаем на выходе нужную страницу с инфой.

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

[Anvar]

Пробежался я по своему старому форуму, темы с 1500 сообщений куча, есть и по 3к+. Тормозов нету, хотя раньше на обычном хостинге жалобы были частые, ну сейчас ещё посещалка пришла на нет, что тоже идёт в зачёт производительности.

[Andex]

FYI проблема заключалась вот в этом запросе в /phpbb/notification/type/post.php:

Код: Выделить всё

SELECT 
	n.* 
FROM 
	phpbb3_notifications n, 
	phpbb3_notification_types nt 
WHERE 
	n.notification_type_id = 5 
	AND n.item_parent_id = 5 
	AND n.notification_read = 0 
	AND nt.notification_type_id = n.notification_type_id 
	AND nt.notification_type_enabled = 1

phpbb3_notifications объемом метров в 400, около 300 тыс. записей
Индексов, например на item_parent_id нет, в итоге запрос выполняется в районе 5-6 секунд
Добавление индекса решает проблему, запрос выполняется мене 0,1 сек