Для ускорения работы хупса надо поставить его на быстрый сервак

UNREGISTRED пишет:
с компрессией тока хуже будет, сам подумай, сервак итак еле дышит, а ты его ещё архивировать заставляешь

Vlad пишет:
согласен. от скуки старый топ поднял :)

shperk пишет:
Quote:

Vlad пишет:
согласен. от скуки старый топ поднял :)

А если от скуки, то как сообщество относится к следующим советам с сайта постнюки:
0. Оптимизация Базы Данных.

Цель : заставить базу данных (и запросы к ней) работать так быстро, насколько это возможно.

Если Вы имеете большой сайт и/или много посетителей, Вы возможно захотите добавить следующее индексы к вашим .71x таблицам : (в синтаксисе MySQL)

alter table nuke_comments add index idx_pid (pn_pid);
alter table nuke_comments add index idx_sid (pn_sid);
alter table nuke_group_membership add index idx_ug (pn_uid,pn_gid);
alter table nuke_message add index idx_exp (pn_active,pn_expire);
alter table nuke_modules add index idx_name (pn_name);
alter table nuke_poll_data add index idx_pollid (pn_pollid);
alter table nuke_pollcomments add index idx_pollid (pn_pollid);
alter table nuke_referer add index idx_url (pn_url);
alter table nuke_stats_date add index idx_date (pn_date);
alter table nuke_session_info add index idx_last (pn_lastused);
alter table nuke_stories add index idx_catid (pn_catid);
alter table nuke_stories add index idx_topic (pn_topic);
alter table nuke_user_data add index idx_uid (pn_uda_uid);
alter table nuke_userblocks add index idx_ub (pn_uid,pn_bid);
alter table nuke_users add index idx_uname (pn_uname);

и возможно немного дополнительных, в зависимости от используемых Вами модулей.

Настройка производительности Вашей СУБД и регулярная ее оптимизация (напр. регулярное выполнение команды 'OPTIMIZE TABLE ...' для больших таблиц в MySQL), также может улучшить время выполнения запросов.

Тесты с большим сайтом на PostNuke .713 на небольшом сервере показали, что самое узкое место - формирование запросов к базе данных; добавление всего одного индекса к большой таблице уменьшает время выдачи страницы на 22% для анонимных посетителей (с 1315 мс до 1025 мс), и на 59% для зарегистрированных пользователей (с 2750 мс до 1135 мс).

1. Кэширование запросов
Цель: Избежание необязательных дополнительных запросов базе данных для выдачи одних и тех же данных

Уровень абстракции БД PNADODB используеммый в PostNuke может быть сконфигурирован для кеширования некоторых результатов запросов, во избежание повторного их выполнения.

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

Добавлление нескольких переменных в нужном месте кода дают дополнительное ускорение времени выполнении около 34% (с 1025 мс до 676 мс) для той же страницы, а на уровне БД этот показатель достигает 49%. (Несколько упоминавшихся изменений уже включены в код PostNuke, так что это может быть использовано за отправную точку при оценке других методов оптимизации.)

Перед тем, как опробовать любой приведенный далее метод оптимизации, убедитесь, что узким местом производительности Вашего сайта не является всего лишь несколько больших таблиц в вашей базе данных.

2. Оптимизация и кэширование кода
Цель : Убедитться, что выполнение кода происходит так быстро, насколько это возможно и избегается его повторная компиляциия.

ZendOptimizer - бесплатный add-on к PHP от Zend (http://www.zend.com), который пытается оптимизировать Ваши PHP-скрипты после компиляции для ускорения их выполнения. Тесты с тем же большим сайтом PostNuke .713 показали среднее уменьшение времени отклика около 7% (с 676 мс до 626 мс) для страницы сайта. Возможно, страницы Вашего сайта покажут даже лучшие результаты оптимизации.

ZendAccelerator - платный add-on к PHP от Zend, который не только пытается оптимизировать скомпилированный код но также и кешировать его в памяти во избежание его перекомпиляции при каждом страничном запросе. Тесты на все той же странице сайта давали среднее уменьшение времени отклика около 30% (с 676 мс до 469 мс). Графический интерфейс ZendAccelerator'а показывал так называемый показатель прироста скорости, равный 4.52 для 90% файлов, и 15.81 для 75% файлов, но, как Вы можете видеть, фактический средний прирост выполнения для всей страницы отнюдь не так высок...

APC Cache (http://apc.communityconnect.com/) - бесплатный аналог ZendAccelerator'а. Тесты производительности показали, что его эффективность не так высока, как у его платного конкурента, но тем не менее он дает некоторое повышение производительности при исполнении кода (особенно, если у Вас мало памяти).

PHP Accelerator (http://www.php-accelerator.co.uk/), также freeware (однако его исходники все же закрыты) и дает улучшение времени отклика на 31% (с 676 мс до 466 мс), по сравнению с тем же ZendAccelerator'ом.

afterBURNER*Cache (http://afterburner.bware.it/cache.htm) - еще один подобный free-продукт. Исходный код доступен.

Некоторые системы подобного рода, например, Smarty и некоторые другие системы шаблонов позволяют "компилировать" ваши шаблоны в код PHP, что также ускоряет их обработку. Вы можете объединить их с вышеуказанными продуктами, для достижения большего эффекта.

3. Кэширование блочного ввода/вывода
Цель : Избежание перегенерации блока в случае, если его содержимое не изменилось

Некоторые системы шаблонов позволяют кешировать HTML-вывод конкретных шаблонов (напр. блоков). Этот же прием может быть применен и к коду PostNuke, перед или после templating - подробнее см "Стратегия Кэшировани".

Кэширование блоков (а также кэширование страниц), дает гораздо больший эффект, нежели любой другой метод оптимизации: 55% для нашей злополучной страницы сайта (с 676 мс до 300 мс).

4. Кэширование страниц
Цель : Избежание перегенерации страницы в случае, если ее содержимое не изменилось

Есть немсколько удобных PHP-классов, позволяющих кэшировать на вашем сайте выводимые страницы. PEAR Cache/Output.php и jpcache - два таких примера. Тем не менее, "PostNuke-ориентированная" система кеширования может работать по-разному у различных пользователей и с различными модулями. Для выбора лучшего метода и для понимания того, что должно/может быть кешировано - см."Стратегию Кэширования"

Страничное кэширование давало 59%-ное улучшение для той же страницы (с 676 мс до 279 мс). Когда Вы для уменьшения "фиксированной стоимости" выполнения PostNuke объедините этот метод оптимизации с кодовой оптимизацией/кэшированием, прирост скорости выполнения скрипта становится уже действительно интересным - 84%-ное ускорение выдачи страницы (с 676 мс до 110 мс) при использовании ZendAccelerator, или 82%-ное ускорение (с 676 мс до 120 мс) при использовании фриварного PHP Accelerator'а.

Начиная с этого момента, дальнейшее увеличение производительности может быть достигнуто дополнительной оптимизацией БД на предмет уменьшения среднего времени отклика (в нашем случае - около 50 мс) при кешировании страниц, и пересмотром Вашей Стратегии Кэширования, для увеличения коэффициента кэширования (в нашем случае - до 90% и даже более).

На крайний случай, Вы всегда можете сгенерировать статические HTML-страницы для наиболее частопосещаемых страниц сайта, в этом случае локальное время отклика может составить до 1.4 мс, что является увеличением производительности на 99.8% по сравнению с Вашим исходным сайтом.

5. Компрессия вывода
Цель: уменьшение передаваемого по сети трафика

Не имеющая отношения непосредственно к PostNuke, но тем не менее важная для увеличения общей производительности сайта, и замечаемая в первую очередь Вашими посетителями возможность - сжатие выхода HTML перед его пересылкой браузеру.

PHP сам по себе обеспечивает сжатие посредством ob_start("ob_gzhandler"), Apache также поддерживает компрессию при использовании mod_gzip. Если Вы хотите включить ваше собственное сжатие, потребуется дополнительное обеспечение корректности компрессии выходных данных, хотя использованием классов PEAR Cache/OutputCompression.php и jpcache для кэширование страниц с лихвой удовлетворит этому условию.

6. 304 Не Модифицированный заголовок
Цель: Избежание выдачи целой страницы если она не изменилась

Финальным (окончательным?) аккордом ускорения работы сайта является возможность не делать запросы тех страниц, которые не изменились с момента последнего просмотра их пользователями. Для этого нужно позаботиться о посылке PHP-функцией header() требуемых заголовков HTTP и проверять запросы браузеров на предмет заголовков If-Modified-Since. В этом случае Вы можете избежать обработки запросов в БД, ограничиваясь возвратом HTTP-заголовка "304 Not Modified header".

Это заставит браузер искать страницу в своем кеше (и в любом другом промежуточном кэше), а Ваш сервер тем временем может сконцентрироваться на генерации нового контента, а не дергаться снова и снова для перегенерации одного и того же.

Классы, позволяющие кэшировать страницы уже частично используются в PostNuke, а поддержку HTTP-заголовка "304 Not Modified header" намечается включить в будущих версиях системы.

7. Другие методы улучшения производительности
- избегйте установки ненужных модулей и блоков, а еще лучше удалите их совсем из каталога /html/модулей/
- удалите необязательные определения из Autolinks или отключите их вообще
- постарайтесь, чтобы все блоки RSS (если у Вас их несколько) обновлялись одновременно, а также установите тайм-аут для этой процедуры