Cache и другая оптимизация!

Привет, чем отличается memcache от file cache?
Хочу как то оптимизировать ЛС, использовать кэш.

И еще, как можно включить gzip сжатие для страниц сайта?

Какие виды оптимизации вы знаете и как их можно применить?

Требуется оптимизация SQL запроса

Решил добавить для форумов своих удобную штуку как список всех комментариев, но столкнулся с проблемой (кеш у меня выключен, но дело не в этом). У меня на форуме 3.233.031 комментариев и запрос как в comment.mapper.class.php в функции GetCommentsAll капитально тормозит машину
Читать дальше →

Первая рабочая группа - Оптимизация голосования за топики и комментарии

Здесь собирается рабочая группа, которая оптимизирует код, который будет обрабатывать голосование.
Пожелания, предложения со стороны разработчиков приветствуются! Лоре что-то не нравилось, может у неё есть готовая идея )?

Это будет первый пилотный проект по созданию рабочей группы. Да поможет нам сервер всевышний )

Клиентская оптимизация

Возможно вопрос уже поднимался, скажите если так. Считаю, что нужно подумать над клиентской оптимизацией движка — сократить количество запросов к серверу, объединить статические CSS, JS файлы, сжать их, подумать над оптимизацией графики,…
http://webo.in/urls/livestreet.ru/ — тут можно посмотреть анализ сайта.

Если заинтересует моё предложение — обращайтесь, подскажу как сделать, скажу что почитать.

P.S. Хочется чтобы отличный продукт стал ещё лучше :) Спасибо за Ваш движок.

Тормоз при запросах к БД

Для теста производительности движка импортировал базу данных [4092 юзера, 4113 блогов (включая личные), 4845 топиков, 27231 комментириев] с работающего сайта из другого движка.
По данным du -hc /каталог/базы данных, размер базы, включая индексы, составляет 53 МБайта в бинарном виде.

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

Факт, что узким местом являются запросы к базе подтверждается и блоком статистики внизу страницы и менеджером процессов top (ОС Debian Linux 4.0).

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

При беглом анализе структуры таблицы топиков, видна ее частичная неоптимальность, как например хранение текста топика в 3х экземплярах (тизер, полный текст и оригинал до обработки парсером-типографом).

Есть у уважаемого сообщества какие-либо идеи по поводу узкого места в работе с БД и/или предложения по нейтрализации сего узного места?

Отдельно хочу поинтересоваться у автора о причинах такого неоптимального хранения текста топиков?