Вы не зашли.
Ну ты посмотри в исходном коде страницы какой URL сформировался и доступен ли файл по этой ссылке.
Честно сказать я не понял ни что ты хочешь, ни что ты сделал, так как DLE не пользуюсь. Что делает JS код во write.tpl и как он теперь связан с pm я тоже не понял
vitaly, супер. А что за софт, которым запросы делал?
Должен помочь стандартный /engine/upgrade.php
Естественно с предварительным бэкапом.
На 0.9.2 работает только версия 0.04 вроде.
Ну во первых таких событий всего 7. То есть тормоза появляются относительно редко. Файл удали пока, чтобы заново отсчет пошел.
Затыка всего три.
Первый это:
0.025 0.008 Template engine is activated
5.833 5.808 DB connection established
5 секунд подключение к БД?
Второй:
19.032 Config file is loaded
19 секунд загрузка config файла?
17.988 Config file is loaded
18 секунд загрузка config файла?
И третий:
0.075 exec showNews // similar
11.394 call showNews() for [ 11.3389 ] sec
0.079 0.000 exec showNews // similar
10.613 10.533 call showNews() for [ 10.5561 ] sec
Что он тут делает 10 секунд при первом вызове showNews тоже непонятно?
Подождем коммента Виталия
1. Версия движка.
2. Версия плагина комментариев.
3. Помогает ли вкл/выкл плагина комментариев.
Спорить с техподдержкой Сколько выполняется этот запрос? Он же копеечный.
Как на счет того , что ты скинуться по 20 у.е человек так 10 и заплатить толковуму програмисту , который создаст нам програму .
Мне нравится вариант 10 человек по 20 у.е.
P.S. То что ты предлагаешь невозможно. В плане создания конвертора модулей.
В логах будут всё, что обрабатывалось больше 10 секунд.
56 секунд жесть, все логи, которые ты сюда сбрасываешь показывают, что выполнение сайта хоть и велико, бывает и 3 секунды, но это все не то, championat.com у меня тоже грузится по две-три секунды, а ведь там работает целая команда
Меня смущает самый первый лог в первом сообщении
43.852 0.000 Config file is loaded
43.887 0.035 Core files are included
То есть даже до момента работы всех плагинов, на загрузку config файла уже потратилось 43 секунды, потом все плагины за 1 секунду отработали. Все это происходит еще до момента соединения с БД.
Можно начать мониторить такие события.
Открой /engine/includes/classes/timer.class.php
Найди
class microTimer {
Замени на
class microTimer {
private $flag = false;
Найди
// REGISTER measurment
function registerEvent($eventName, $eventParams = ''){
$current_time = $this->stop(4);
$delta = $current_time - $this->last_event;
if ($delta < 0) $delta = 0;
array_push($this->events, array( $current_time, sprintf('%7.3f', $delta), $eventName, $eventParams ));
$this->last_event = $current_time;
}
замени на
// REGISTER measurment
function registerEvent($eventName, $eventParams = ''){
$current_time = $this->stop(4);
if($current_time > 10) $this->flag = true;
$delta = $current_time - $this->last_event;
if ($delta < 0) $delta = 0;
array_push($this->events, array( $current_time, sprintf('%7.3f', $delta), $eventName, $eventParams ));
$this->last_event = $current_time;
}
Найди
// Print events
function printEvents($html = 0){
$out = ($html)?"<table class='timeProfiler'>\n<tr><td><b>Time</b></td><td><b>Delta</b></td><td><b>Event</b></td><td><b>Desc</b></td></tr>\n":'';
foreach ($this->events as $v) {
$out .= ($html)?('<tr><td>'.sprintf('%7.3f', $v[0]).'</td><td>'.$v[1].'</td><td>'.$v[2].'</td><td>'.$v[3]."</td></tr>\n"):$v[0]."\t".$v[1]."\t".$v[2]."\t".$v[3]."\n";
}
$out .= (($html)?"</table>":'')."\n";
return $out;
}
Замени на
// Print events
function printEvents($html = 0){
$out = ($html)?"<table class='timeProfiler'>\n<tr><td><b>Time</b></td><td><b>Delta</b></td><td><b>Event</b></td><td><b>Desc</b></td></tr>\n":'';
foreach ($this->events as $v) {
$out .= ($html)?('<tr><td>'.sprintf('%7.3f', $v[0]).'</td><td>'.$v[1].'</td><td>'.$v[2].'</td><td>'.$v[3]."</td></tr>\n"):$v[0]."\t".$v[1]."\t".$v[2]."\t".$v[3]."\n";
}
$out .= (($html)?"</table>":'')."\n";
if($this->flag) file_put_contents('log.txt', $out, FILE_APPEND);
return $out;
}
Позже надо будет посмотреть содержимое файла log.txt в корне и увидим как часто это происходит. Потом надо будет смотреть на какие операции тратилось 40 секунд.
showTablesMain это от football_stats
По поводу подхода
а причем тут сервак если проблема на сайте?
Логично что рано или поздно ресурсы сервера придется увеличивать. Можно подебажить его на предмет кто сколько отжирает, но там все ОК. Можешь пока отключить его и посмотреть насколько улучшится работа, но там все закешировано по максимуму. Но возможно, что файловый кеш уже не справляется, на обращение к диску уходит много времени и стоит memcached попробовать.
Да уже все выяснили Запросы на главной, не в новости.
ну а что с этого, я немогу без него сайт использовать
С того, что узнаем действительно ли он так грузит БД и мешает нормальной работе. Тут пальцем в небо нельзя тыкать
Надо смотреть как ты его используешь и почему он приводит к такому количеству запросов, я просто новые версии не смотрел, как там реализована работа с картинка не знаю. Можно Виталию это переадресовать Тормозить-то перестало?
Из тех, что в списке я даже не знаю кто может делать столько запросов к 2z_images на первый взгляд. Отключай-ка их последовательно и смотри, когда пропадут эти запросы. Начни с xfields
legenda, ну вот, сразу все стало на места.
вот с выключеним similar на главной 43 запроса из низ 38 !! select * from 2z_images where id in (101754) Это что? Откуда это? Что за кривой плагин? Нельзя делать 38 запросов вместо одного. Надо разбираться. Уже снизится в разы нагрузка! Думаю это и есть корень проблемы.
вот с включеним similar он работает в новостях, толку от лога на главной нет.
еще вот на новостних тут все ОК, 6 запросов, similar отрабатывает мгновенно 0.0004
отключаю кеш и интеграцию
SQL запитів: 92, Генерація сторінки: 2.73 сек
включаю кеш, интеграцию отключена
SQL запитів: 43, Генерація сторінки: 0.39 сек
Выключи интеграцию и забудь про нее. Буду делать xfields с родной поддержкой. В два раза увеличение запросов ненужных.
Дебаг на сайте. Интеграция может сильно все портить, надо было раньше ее убрать
А может у тебя в top_news включена интеграция с новостными плагинами? Или в lastnews? Потому что отключенный similar ну никак не может давать снижение запросов с 19 до 6. Интеграция может давать такой прирост в силу ее кривости (выполнение одинаковых запросов несколько раз), в новой версии я ее уберу вообще!
Покажи лог всех запросов на страниц с включенным и выключенным similar. И лог всех запросов на страниц с включенным и выключенным top_news.
legenda, ну отключи similar пока и посмотри на работу сайта с посетителями. Надо определить главный источник и от него плясать. Каково время выполнения запроса этого плагина? Выглядит как-то так
select n.id, n.catid, n.alt_name, n.postdate, si.id as si_id, si.dimension as si_dimension, si.newsID as si_newsID, si.refNewsID as si_refNewsID, si.refNewsQuantaty as si_refNewsQuantaty, si.refNewsTitle as si_refNewsTitle, si.refNewsDate as si_refNewsDate from 2z_similar_index si left join 2z_news n on n.id = si.refNewsID where si.newsID = '168' and (dimension = 0) order by si.refNewsQuantaty desc
legenda, так сколько уходит на выполнение запросов и сколько на отработку движка? Мы чего-то топчемся на одном месте, с начала что ли идти опять? Если все отключить, кроме базовых плагинов, то проблема исчезает или нет? Процессор ты старый вернул?
пару ошибок на оффсайте исправил, но на просьбу немного расширить доступ для исправления остальных - тишина... абыдна, да?
Кому должно быть обидно? Я не знаю к кому ты обращался просто. Доступ не проблема.
Обрабатывать когда? До внесения в БД или после извлечения перед отображением?
Точнее он может и не знать это, его право Недавно знакомый устраивался верстальщиком, JS обязателен, все интерфейсы на нем, можно вопить, ну не получишь работу тогда А можно подтянуть знания и зарабатывать больше.
Шаблонизатор тут не причем Скобки для читаемости. У тебя же вместо переменной значение не подставлялось, а ее название было тем значением, которое искалось, так как было заключено в одинарные кавычки, внутри которых не происходит подстановка переменных.