Уважаемые дамы и господа, не сочтите за рекламу, но нужна помощь с оптимизацией скриптов форума собственного написания. Итак, у нас с товарищем есть форум, который мы сами написали - http://chatman.ru. Очень долго генерируются странички. Вот например, я недавно добавил http://chatman.ru/1 тут (ссылка с единичкой на конце) новую вещь. А именно: юзеры, отпостовавшие последними мессагу и дату мессаги. Страничка стала ещё больше грузиться. Заходим просто на chatman.ru:

Далее идём на модифицированную вещь http://chatman.ru/1 :

Теперь идём смотреть категорию, скажем новости http://chatman.ru/1/index.php?show=messages&id=6 :

И далее идём смотреть какую-нибудь тему: http://chatman.ru/index.php?show=message&a...941&page=76 :

Ну одна секунда это, конечно, не так много, как было в других случаях, но всё-таки много.

Я так понял, что время генерации скрипта зависит от того, сколько и каких запросов идёт к базе MySQL.
Вот, например, раньше http://chatman.ru/index.php грузился ещё медленнее. Но теперь всё ответы на темы я начал записывать в базу и считывать их оттуда, а на главное странице, где категории, там мы складываем все значение из тем, что, конечно, тоже не совсем правильно (я так понимаю, что в категориях тоже надо писать количество созданных тем и ответов)

Скажите, можно ли как-нибудь оптимизировать работу скриптов, не записывая количество чего-либо в базу, а всё также (как сейчас) посчитывая mysql_numrows();? Расскажите поподробнее, пожалуйста. 

Все можно, но подходить надо лифференцировано. Дело даже зачастую не в количестве запросов, а в не грамотной обработке. 

Mal Hack,  ну, вот например, как я уже говорил на http://chatman.ru/1 я создал фичу, где отображается, кто последний ответил на тему. Вот кусок кода, который это обрабатывает:

 

OverClocker, исскуство отладки и оптимизации целая наука, тут надо рассматривать всю систему в целом и т.п.
Есть,  конечно, такое правило, что первым делом, программа должна иметь оптимальный алгоритм, потом минимальное использование ОП для реализации алгоритма, третье - фичи оптимизации.

Примеров много, где-то они тут уже обсуждались.
  

Это сообщение отредактировал(а) Mal Hack - 22.4.2006, 20:43

Покажи  Replace_Critical.  Может  ее  заменить  на  пару  стандартных  и  регэкспов?
И  почему  бы  тебе  не  делать  обработку  ткста  мессаги  непосредственно  при  ее  публикации? 

Это сообщение отредактировал(а) comnimh - 25.4.2006, 12:16

OverClocker, попробуй поставить себе APD или на худой конец PEAR::Benchmark
(APD конечно конечно лучше намного)
на глаз очень трудно прикинуть, какие именно участки кода тянут на себя слишком много ресурсов
а с помощью APD - 10 минут анализа трейса - и все узкие места перед тобой как на ладони

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

например случай с последним сообщением в теме:
я бы забил на нормализацию БД и хранил эту инфу вместе с информацией о теме
тогда одна строчка с списке тем форума будет формироваться из одного запроса

 

Не вопрос!





Можно! Там ещё и смайлики реплейсятся. Ну это другая история...
Мне кажется, что скорей всего всё из-за того, что много запросов к базе идёт...




Классно, классно! Я хочу это посмотреть! А где?



Да, если хранить всё в базе, будет попроще. Хочу сделать, но лень. Но если это действительно оптимизирует работу - сделаю. 

APD - http://pecl.php.net/package/apd 

ZlojEzh, Благодарствую   

Да, ребят, спасибо всем за ответы!  

P.S.: ZlojEzh, мне стыдно это спрашивать... Но всё-таки, как ставить APD на шелле? И как запускать потом...    

Это сообщение отредактировал(а) OverClocker - 26.4.2006, 18:11

У тебя в базе индексы используются? Потому что без СУБД очень сильно грузит систему. 

OverClocker, на шелле не получится
надо, как минимум, доступ к php.ini и к папке, где хранятся .so'шки

в таком случае вариант - PEAR::Benchmark
им, конечно, не так удобно пользоваться - приходится вручную задавать все точки для замера времени
но хоть что-то...

по-поводу твоего скрипта:
строка 13:

имхо, select * здесь не надо - ты используешь только два поля
выбирать все записи из темы тоже не надо - делаем limit 1
строка 2 - аналогично:

нужна ведь только одна запись (насколько я понял) - делаем limit 1

вообщем смысл таков - из БД выбираем только те данные, которые используем

и еще - в mysql_fetch_array ставь второй параметр MYSQL_ASSOC
повышение производительности это вряд ли даст )), но если понадобится на экран выводить (или еще чего) - удобней будет

если есть возможность - в mysql включаем лог медленных запросов
через день анализируем и проверяем соответствующие скрипты на предмет возможной оптимизации (или же, как уже сказал madFobos, создаем соответствующие индексы в таблицах (здесь главное не переусердствовать) )

Replace_Critical, имхо, стоит использовать при записи данных в БД, а не при выводе
(аналогично: проверка длины логина)

split заменяем на explode - в твоем случае реги не нужны (на форуме об этом уже писалось не один раз)


вообщем пройдись по всем скриптам обращая внимание на такие моменты
имхо, получишь неслабое ускорение работы сайта

Добавлено @ 10:04 
да, кстати - если получится проинсталить apd:
читаем здесь
http://apd.communityconnect.com/faq.html
http://ua2.php.net/manual/en/ref.apd.php

и стоит посмотреть вывод phpinfo()
может apd уже включен
 

ZlojEzh, спасибо тебе! Очень содержательно! Буду пробовать! Очень рад, что настолько подробно, не поленился, и ответил! Спасибо!

Кстати, а где скачать PEAR::Benchmark и как его установить?..    


Хм... Индексы? А как создать их через PhpMyadmin? И что они из себя вообще представляют? 

Это сообщение отредактировал(а) OverClocker - 28.4.2006, 08:09

Это должно быть на pear.php.net



В phpMyAdmin точно не знаю, т.к. редко им пользуюсь, но по идее там в структуре таблицы это все должно быть. Индексы представляют собой указатели на нужную тебе информацию. Скажем твоя таблица содержит 1.000 записей и если в ней искать строку по id = 5, то базе необходимо будет полностью считать весь файл таблицы и путем "пробега" по нему найти твое id = 5. При наличии же индекса на колонку создается нечто вроде отдельного файла (хотя в каждой базе своя реализация), где хранятся только значения непосредственно твоего id и адреса строк (указатели) в основной таблице. Т.к. файл индекса меньше по объему и представляет собой обычно бинарное дерево, то поиск ведется очень быстро, процессор грузится на несколько порядков меньше, соответственно и время обработки значительно быстрее. Это вкратце   
 

OverClocker, как совет по оптимизации РНР кода, могу посоветовать для начала заменить все split на explode, а множественные str_replace объеденить в один:



А вообще, лучше всего сходить на курсы по РНР, только на хорошие, а то иногда попадаются места где незнают что такое file_get_contents и прочее... еще есть много хороших книжек (советую купить хотя бы одну, подробнее ищи на форуме).  

или просто хорошенько почитать мануалы по php и БД которую используешь.