(del) ?–???‚?????µ ?‚?????????·?°

[Гром]

MOPO3, а чего молчишь

[MOPO3]

Гром, Да только приконектился, так на собрание вызвали А потом залазился я по инету в поисках инфы по моему вопросу А то никто не отвечает ничего, вот и ищу сам Уже ДДК поставил, теперь попытаюсь та понять что-нибудь  

[Гром]

MOPO3, какой вопрос то - задал бы здесь - что случилось?

[MOPO3]

Дык в драйверах есть топик   зачем флуд разводить и ещё и тут печатать    Да и не по теме сдесь  

[Гром]

MOPO3, ага внимание не обратил - счас посмотрю...

[Гром]

Причины найдены!!!

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

[Гром]

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

Может кто посоветует кк теперь быть и что ставить взамен, или как оптимизировать.

[MOPO3]

Гром, насколько я знаю, то форум использует функцию mysql_pconnect() . Поэтому, в принципе, не должно открываться несколько коннектов даже при нескольких открытых окнах, по крайней мере пока не слетит сессия.

[RXL]

mysql_pconnect() стоит рассматривать как пул открытых повторноиспользуемых соединений. Один копия (поток или процесс) запущенного скрипта использует одно соединение. Несколько потоков не могут использовать одно соединение одновременно. По какой логике они закрываются - не знаю, не проверял. Быстрее всего, их СУБД обрубает по таймауту.
Сам mysql_pconnect() не использую - не привычно. Предпочитаю надежный mysql_connect(). Как-то был случай: я поднял MySQL сервер и ограничил на 10 соединений, а товарищ мой написал скрипт на php с этими самыми pconnect-ами. Так они заняли все 10 возможных и не отключались - пришлось рестартнуть СУБД.

Сервер разрешает по их данным 62 коннекта одновременно,...

Для всех, а не только для нас...

[MOPO3]

RXL, я и сам не использую mysql_pconnect() . Один раз только помогло на большом проекте, а то админ ругался очень сильно  

[Гром]

MOPO3, RXL, проблема не в самом форуме а в том самом topic_anywhere!!!

ЗАпросы на новые наши сообщения идут не только с нашего сайта но и с http://rusdoc.ru

У них 3-4 тышшы уникальных юзеров и куча загрузок страниц...
Буду просить его убрать вызов кода со всех страниц...
Однако у них все равно тормозит БД например сейчас на их сайте!!!

[RXL]

За что боролись, на то и напоролись...

[Гром]

RXL, а по существу???
Я напишу их админу с просьбой убрать код с каждой страницы и оставить только на одной - и одну ссылку!

[RXL]

Гром, по существу - оптимизировать надо. Список последних сообщений не такая уж текучая вещь, чтобы выдавать ее на каждый запрос. Достаточно будет обновлять раз в минуту. Какая версия этого topic_anywhere стоит?

[Гром]

1.7 версия...
У него там такой хитрющий запрос, счас посмотрю - могу ли я сам написать - по тому же принципу...
А раз в минуту не получится - крон не дадут чаще1 раз в 10 минут поднимать!

Там явно не по делу запрос вот такой!!!


SELECT t.*, u.username, u.user_id, u2.username as user2, u2.user_id as id2, p.post_username, p2.post_username AS post_username2, p2.post_time, f.forum_name FROM phpbb_topics t, phpbb_users u, phpbb_posts p, phpbb_posts p2, phpbb_users u2, phpbb_forums f WHERE t.topic_poster = u.user_id AND t.forum_id in (6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 26, 33, 34, 35, 37, 39, 40, 41, 42, 43, 44, 45) AND p.post_id = t.topic_first_post_id AND p2.post_id = t.topic_last_post_id AND t.forum_id = f.forum_id AND u2.user_id = p2.poster_id AND t.topic_type <> 2 AND t.topic_type <> 1 AND t.topic_status <> 1 AND t.topic_status <> 2 ORDER BY t.topic_type DESC, t.topic_last_post_id DESC LIMIT 20;

[RXL]

Гром, cron и не нужен. Принцип более простой: фиксируется время последнего обновления и при привышении генерится новая информация, иначе используется старая. Т.е. сложный и медленный запрос выполняется редко, а большинство запросов получают кешированную информацию.
Тонкость реализации тут в том, чтобы несколько потоков не взялись сразу за генерацию новой информации. Я думаю, что тут нужно две таблицы: одна для кешированной информации (можно и в файле хранить, но в таблице лучше) и одна для хранения даты обновления. Вот вторую таблицу нужно блокировать:
BLOCK TABLES table WRITE;
SELECT dt FROM table;
UPDATE table SET dt=NOW() WHERE dt<'минуту назад';
UNLOCK TABLES;
Сработает это быстро.

[RXL]

Вот анализ "штатного" запроса к базе:

Код:

+-------+--------+-------------------+---------+---------+-----------------------+------+---------------------------------------------+
| table | type   | possible_keys     | key     | key_len | ref                   | rows | Extra                                       |
+-------+--------+-------------------+---------+---------+-----------------------+------+---------------------------------------------+

| t     | ALL    | forum_id          | NULL    |    NULL | NULL                  |    7 | where used; Using temporary; Using filesort |
| u     | ALL    | PRIMARY           | NULL    |    NULL | NULL                  |    4 | where used                                  |
| p     | eq_ref | PRIMARY           | PRIMARY |       3 | t.topic_first_post_id |    1 |                                             |
| p2    | eq_ref | PRIMARY,poster_id | PRIMARY |       3 | t.topic_last_post_id  |    1 |                                             |
| u2    | eq_ref | PRIMARY           | PRIMARY |       3 | p2.poster_id          |    1 |                                             |
| f     | eq_ref | PRIMARY           | PRIMARY |       2 | t.forum_id            |    1 |                                             |
+-------+--------+-------------------+---------+---------+-----------------------+------+---------------------------------------------+

Столбец "rows" здесь ни чего интересного не показывает - база у меня почти пустая.
За то видно, что крупная таблица phpbb_topics (здесь под псевдонимом t) читается и сортируется целиком. Чем больше она становится, тем медленне работает.

Попробовал заменить на LEFT JOIN:

Код:

SELECT t.*, u.username, u.user_id, u2.username as user2, u2.user_id as id2, p.post_username, p2.post_username AS post_username2, p2.post_time, f.forum_name
 FROM phpbb_topics t
  LEFT JOIN phpbb_users u ON t.topic_poster = u.user_id
  LEFT JOIN phpbb_posts p ON p.post_id = t.topic_first_post_id
  LEFT JOIN phpbb_posts p2 ON p2.post_id = t.topic_last_post_id
  LEFT JOIN phpbb_users u2 ON u2.user_id = p2.poster_id
  LEFT JOIN phpbb_forums f ON t.forum_id = f.forum_id
 WHERE
  t.forum_id in )6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 26, 33, 34, 35, 37, 39, 40, 41, 42, 43, 44, 45:
  AND t.topic_type <> 2
  AND t.topic_type <> 1
  AND t.topic_status <> 1
  AND t.topic_status <> 2
 ORDER BY t.topic_type DESC, t.topic_last_post_id DESC 
 LIMIT 20;

Получилась некоторая оптимизация:

Код:

+-------+--------+---------------+---------+---------+-----------------------+------+----------------------------+
| table | type   | possible_keys | key     | key_len | ref                   | rows | Extra                      |
+-------+--------+---------------+---------+---------+-----------------------+------+----------------------------+
| t     | ALL    | forum_id      | NULL    |    NULL | NULL                  |    7 | where used; Using filesort |
| u     | eq_ref | PRIMARY       | PRIMARY |       3 | t.topic_poster        |    1 |                            |
| p     | eq_ref | PRIMARY       | PRIMARY |       3 | t.topic_first_post_id |    1 |                            |
| p2    | eq_ref | PRIMARY       | PRIMARY |       3 | t.topic_last_post_id  |    1 |                            |
| u2    | eq_ref | PRIMARY       | PRIMARY |       3 | p2.poster_id          |    1 |                            |
| f     | eq_ref | PRIMARY       | PRIMARY |       2 | t.forum_id            |    1 |                            |
+-------+--------+---------------+---------+---------+-----------------------+------+----------------------------+

Проверить бы на большой базе -  у меня в тестовой всего 4 пользователя, 4 форума, 7 тем и 15 постов.

[Гром]

RXL, какой тебя доступ нужен пиши - дам проверить на реальной базе форума....
admin@shelek.com