Быстрый лёгкий надёжный форумный движок
Вы не вошли.
Страницы 1
Тема закрыта
Кто-то занимался таким делом (применительно к PunBB). А то хостер жалуется, что мы сильно грузим MySQL-сервер. Я посмотрел запросы, которые выполняются при index.php:
Time (s) Query
0.10027 SELECT u.*, g.*, o.logged, o.idle FROM users AS u INNER JOIN groups AS g ON u.group_id=g.g_id LEFT JOIN online AS o ON o.user_id=u.id WHERE u.id=2
0.00100 UPDATE online SET logged=1193133016 WHERE user_id=2
0.00060 SELECT * FROM online WHERE logged<1193132716
0.00038 SELECT COUNT(id) FROM reports WHERE zapped IS NULL
0.00029 SELECT COUNT(id) FROM messages WHERE showed=0 AND owner=2
0.00050 SELECT c.id AS cid, c.cat_name, f.id AS fid, f.forum_name, f.forum_desc, f.redirect_url, f.moderators, f.num_topics, f.num_posts, f.last_post, f.last_post_id, f.last_poster FROM categories AS c INNER JOIN forums AS f ON c.id=f.cat_id LEFT JOIN forum_perms AS fp ON (fp.forum_id=f.id AND fp.group_id=1) WHERE fp.read_forum IS NULL OR fp.read_forum=1 ORDER BY c.disp_position, c.id, f.disp_position
0.00044 SELECT COUNT(id)-1 FROM users
0.00033 SELECT id, username FROM users ORDER BY registered DESC LIMIT 1
0.00034 SELECT SUM(num_topics), SUM(num_posts) FROM forums
0.00034 SELECT COUNT(id) FROM polls
0.00064 SELECT * FROM smilies
0.09964 SELECT u.id, u.group_id, u.num_posts_chatbox, m.id AS m_id, m.poster_id, m.poster, m.poster_ip, m.poster_email, m.message, m.posted, g.g_id, g.g_title_chatbox FROM chatbox_msg AS m INNER JOIN users AS u ON u.id=m.poster_id INNER JOIN groups AS g ON g.g_id=u.group_id ORDER BY m.posted DESC LIMIT 30
0.00039 SELECT search_for, replace_with FROM censoring
0.00076 SELECT user_id, ident FROM online WHERE idle=0 ORDER BY ident
0.00033 SELECT username, id, last_visit from users WHERE last_visit >= '1193086800' ORDER by last_visit DESC
0.00248 SELECT username, id from users WHERE DAYOFMONTH(birthday)='23' AND MONTH(birthday)='10' ORDER by username ASC
Total query time: 0.20873 s
Судя по всему - первый запрос выполняется по времени столько же, как и все остальные.
Что-то можно тут сделать ?
менять хостера
не такой это чудовищный запрос чтобы нормальный сервер вспотел. главное оптимизировать здесь нечего
на самом деле пятый с конца запрос с chatbox почти такой же по времени и здесь есть уже простор для экспериментов. можно попробовать разбить сложный запрос на два простых и замерить скорость.
еще можно и нужно дорабатывать мод PBB ChatBox. мне кажется можно отказаться от поля message TEXT в пользу VARCHAR — будет экономия по времени обработки.
далее - используется фраза ORDER BY m.posted DESC, индекса по posted там вродебы нет, зато есть автоинкрементное поле id - оно растет одновременно с posted !!! делайте ORDER BY m.id DESC — это быстрее, если запрос будет простой. тогда mysql использует индекс.
последний запрос по users делает полный перебор таблицы, это не есть хорошо. можно оптимизировать, создав индексируемое поле месяц_день, я уже предлагал это в соответствующей теме.
менять хостера
Дык вот поменяли Кстати, у нового хостера http и mysql расположены на физически разных серверах. И получается время выполнения то 1 сек (когда сервер БД не загружен) , то до 20 сек (при пиковой загрузке).
У меня на форуме одновременно находится около 70-80 человек (в пике может до 100, но это очень редко)
я уже предлагал это в соответствующей теме.
Ткни меня носом, плиз !
Добавлено спустя 1 минуту 15 секунд:
Теперешний хостер мне нравится - все делают оперативно и поддержка нормальная. (да и недорого). Так что менять не хотелось бы . Да вот с нагрузкой такая засада случилась
оптимизация дней рождения: Elektra Profile with Labels
artoodetoo
Спасибо - буду "курить"
Добавлено спустя 1 минуту :
А с запросом по чату - что можно сделать ?
Просто я в MySQL не силен !
про чат я уже написал, писать подробнее — значит сделать все самому, недождетесь
я тоже в MySQL не силен, думаю действуют универсальные правила для всех БД:
все join, order by и group by желательно делать по индексированным полям. например условие WHERE field1 < N будет читать и анализировать все записи таблицы, если нет индекса по field1 или только нужное количество записей, если есть индекс
сложные запросы со множеством JOIN могут сбить ядро бд с толку, поэтому иногда эффективнее выполнить два простых запроса вместо одного навороченного. это уже экспериментами решается.
blob-поля (типа TEXT, MEDIUMTEXT и т.д.) обрабатываются медленнее, чем поля фиксированной длинны. индекс по строковому полю занимает больше места и обрабатывается медленнее, чем индекс по целочисленному полю. blob-поля вообще невозможно проиндексировать.
условие LIKE или оператор OR внутри WHERE приводят к полному перебору
и наконец никогда не помещайте вызов SELECT внутрь цикла
artoodetoo
Спасибо. буду пытаться что-то сделать
сложные запросы со множеством JOIN могут сбить ядро бд с толку, поэтому иногда эффективнее выполнить два простых запроса вместо одного навороченного. это уже экспериментами решается.
Во-во, сталкивался с этим сам.
Но введение лишнего массива не тормознет ли PHP-сервер? Что выгоднее в данном случае?
Редактировался Ivan the Knight (2007-11-19 11:57:23)
Страницы 1
Тема закрыта