короче есть сайт новостной движёк phpnuke. сайту лет 10 и за ето время набролось столько много сообщений(новостей). сайт грузится медленно. 31 секунду идет формирование страницы. Файл не хочется делить. Что делать???
возможно есть какоето решение. кстати траффика ест 2-3 гига в месяц.

Перевести старые новости на html не выход?

Хм. а как ето реализовать?? и главное сайт любят поисковики. Они могут днями в нем копаться .и долго ли будет преобразовывать ето в хтмл??в ручную ето почти не возможно. каждый пост новый файл?? жесть

Если phpnuke "родная", то модуль новостей там создает достаточно много запросов к базе, плюс блоки могут тоже баловаться этим. Мы бы советовали оптимизировать скрипты и/или сменить phpnuke на какой-нибудь из оптимизированных клонов, может помочь. Правда учитывая 31 секунду - можем предположить что причина в чём-то другом, всё-таки многовато.
P.S.: Адрес сайта не покажите? Можно в личку если не хотите публично.

gazet.net.ru
да phpnuke "родная"
все дополнительные модули отключены. уже давно. но безтолку

у вас БД в порядке ?
"30/10/2007 Тендер по ОМС встряхнул рейтинг, выведя «МАКС-М» в число лидеров по сборам
"
или это машина времени ?

пасибо исправлю , мой глюк с датой. Но не в етом суть. он заколебал так долго грузиться. Пока 1 статью опубликуешь весь мат вспомнишь

Действительно долго Открытие страницы: 12.3 секунды
А не в этом причина?
nserver: ns1.valuehost.ru.
nserver: ns2.valuehost.ru.
nserver: ns3.valuehost.ru.

В смысле??
А не в этом причина?
nserver: ns1.valuehost.ru.
nserver: ns2.valuehost.ru.
nserver: ns3.valuehost.ru.
Думаете хостер виноват???

Время которое по умолчанию показывается в нюке это время генерации страницы. К Вам на сайт у нас tracert с несколькими * идет, что кажется может сказываться на скорости загрузки страницы, но не на скорости её генерации... за исключением ситуации, если Вы по ходу загрузки страницы что-то тянете по http откуда-то и тянете долго, то это может на генерации страницы сказаться ес-но. По поводу ВХ - у него не самые шустрые базы, на другом хостере могли бы быть и другие показатели, однако это не значит что Вы не можете улучшить результаты не меняя хостера.

Элементарно - делаете wget на сайт, ставите на старых страницах редиект на html
Вобщем изучайте матчасть

Целыми днями они в нём копаются, потому что ждут, когда же он отреагирует.

да мат. часть хромает. но есть стремление знать больше. Опыт приходит с годами. что мне все старые статьи в ручную переводить в хтмл???Я тогда года 3 на форуме не появлюсь.

Можно сделать кеширование на текстовых файлах, алгоритм очень простой - проверяется REQUEST_URI и если на основе него не создано кеш-файла, он создается, а в следующий раз уже возвращается его содержимое, вместо того что бы делать запросы к MySQL и выполнять другие ресурсоемкие операции. Ежесуточное обновление кеша так же реализуется очень просто.
Фактически эффект будет тот же, что и от простого перевода в HTML, только процесс этот полностью автоматизирован и сделать это ИМХО намного проще.

Так приведите за одно пример конфига для mod_rewrite а я потом wget под это дело попробую подкрутить

вообще-то такие крупные сайты держать на phpnuke нету смысла. Например есть альтернатива - клон slaed, которіе делает в разф меньше запросов и имеет такую же страктуру. Не плохой вариант - dle, которій разработан, как новостной движок и думаю будет шустро работать с такой базой. В принципе должен быть конвектор phpnuke в вду и в slaed.

Не проверял, но примерно так

Таким образом, после первого выполнения и динамической сборки скрипта, все следующие вызовы скрипт будет просто отдавать содержимое текстового файла.
Идея не моя, вариантов реализации море..

Только надо учесть, что вот в этом месте может быть die или аналог. У *-nuke в footer.php как раз die присутствует, а иногда и в теме, поэтому если будете кэшировать всю страницу - учтите.

cd cache
wget -m -np http://site.com/article

Будет создано html зеркало сайта директорие article, которую и отдавать.

хм теперь ето надо осознать. и сделать выводы интересно у меня получится. Будь проклят день когда я залез в интернет

<?
$ch='./cache/'.md5($_SERVER['REQUEST_URI']);
if(is_file($ch)){//если есть кеш-файл
echo file_get_contents($ch);//просто отдаем его
}else(//иначе
ob_start();//включае
//отрабатываем скрипт со всеми запросами и прочим.
/*--------любой код----------*/
$out=ob_get_contents();//получаем результат в переменную $out
$f=fopen($ch,"w+");//создаем кеш-файл
fwrite($f,$out);//записываем в него содержимое страницы
fclose($f);
echo $out;//выводим содержимое страницы
ob_end_clean();
}
?>
итак я крашенный бландин я не врубаюсь куда етот Кусок пхп кода засунуть

У меня личный форум есть там около 200 000 постов, посты все в одной таблице естественно (форум IPB) генерится 0.07С , сейчас генерится за 0.3-0.5 ибо mysql сервер на другой площадке стоит до него по оптике tcp пинг 1.5мс

Так что без потерь можно работать с большими объемами.

Так что предлагаю всетаки зрить в корень пробелмы

1. Настройки\ мощность сервера
2. Оптимизация БД (структуры) и Запросов

Если используется НЮК, то думаю последние версии всетаки более адаптирвоаны к современному софту и более развиты в плане кода, перейдите на них. если с версиями все OK, попробуйте другой хостинг.

Не-а, местами даже хуже стало.

Какой движок используется в работе с Таблицей новостей?
Возможно стоит попробовать конвертацию в InnoDB?
С 70000 проблем вроде как не должно быть.
Вообще перевод новостей в файлы - верное решение. Можно попробовать написать php скрипт с просмотром num_rows минус 100 допустим (сто новостей в SQL), а остальные проверять на наличие файла на сервере и создавать если нет и открывать.

70000 записей для mysql считается много?

смотря какие запросы делать

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

К сожелению большое количество файлов в одной папке это не выход.
Если только разбивать в разные папки.