Грузовик Vivvoo v3.5
Обратился давече ко мне один знакомый, попросил посмотреть ему движок... У него информационно новостной портал и уж очень медленно работает, хотя двухголовый сервак полностью в его распоряжении...
Глянул нагрузку на серваке и действительно - при 15 тысячах новостюх, загрузку даёт на базу серьезную (MySQL).
Первое что обнаружил в таблице
tblArticles - поле
created не проиндексированно. Т.е., при большом числе статей мускулу приходилось просматривать всю таблицу, из-за чего тормоза... Включение индексации для этого поля дала сразу 50% рост производительности.
Но вся проблема не в этом... Как оказалось, движок регистрирует просмотры в той же таблице
tblArticles и сохраняет дату и время в поле
last_read. К чему это приводит? Каждый просмотр страницы приводит к сбросу в MySQL кеширования для всех запросов к этой (основной!) таблице. Т.е., оптимизация запросов в БД для Vivvoo v3.5 не работает ВООБЩЕ! У меня сложилось впечатление, что те, кто делал двиг в некотором смысле лузеры. Нельзя часто изменяемые поля и часто читаемые хранить в одной таблице...
Помог своему знакомому так:
папка Class, файл Article.class.php
Дальше коментируються следующие обращения к БД в соответствующих функциях.
PHP:
// Method which update time of reading.Each time call in ShowArticle method.
function UpdateReadings()
{
$this->ResetReadings();
if (empty($this->Id)) return false;
$id=$this->Id;
$time=date("Y-m-d H:i:s");
// $query="UPDATE tblArticles SET
// times_read=times_read+1,
// today_read=today_read+1,
// last_read='$time'
// WHERE id=$id";
// $result=mysql_query($query) or sql_error($query, "Bad query update readings");
}
function ResetReadings()
{
$date=date("Y-m-d");
// $query="UPDATE tblArticles SET
// today_read=0
// WHERE last_read<'$date' and today_read>0";
// $result=mysql_query($query) or sql_error($query, "Bad query reset readings");
}
После этого скорость генерации страницы с 3,5 секунд упала до 0,14 сек.
Так что если у вас такие же проблемы - можете воспользоватся этим решением.