Роботов можно выдирать из apache лога. Если они нужны в общей статистике, то можно раз в сутки парсить лог и вставлять в CNStats. Впрочем это не должно быть критично и к кэшу отношение имеет лишь косвенное.
Согласны с таким решением, единственно что инклудить тоже наверное можно не каждый раз - тут надо бы AI легкий добавить, такой же как к кэшу например. И от архивации для хранения в таком варианте надо отказываться, потому что интерпретатор архив не поймет конечно.
Deni,
От двойного кэширования отказывайтесь. При кэшировании вырезать пробелы и комменты - хорошо, но зажимать в архив - особенно если потом каждый раз приходится пережимать - плохая идея. Место экономится, но процессор кушается неплохо.
Про CNStats, не очень помним эту систему, но мы бы вставляли её html кодом, а не include. Кажется там есть такой вариант, если нет - надо его дописать. Заодно будет очень хороший бонус, что грузящая статистика не будет "мешать" работе основного скрипта.
По поводу инклудов - можно попробовать использовать ssi для инклудов. Будет все-таки меньше кода обрабатываться php интерпретатором, а это время и нагрузка.
По поводу указания "что кэшировать" комментариями и кэширования. Не совсем поняли как можно в "сайте" комментировать подгрузку "динамических частей". В коде сайта? Или как? Можно вот этот момент пояснить?
Но тем не менее по поводу кэширования. Надо просто бить страницу на блоки и указывать какие когда надо кэшировать. Допустим событие редактирование новости - пусть стирает кэш всех "связанных новостей" и сам кэш новости. Можно указывать в комментарии "тип триггера" обновления кэша: мы например используем 3 варианта - по времени (истекло - обновили), по событию редактирования (глобальный обработчик как правило можно привязать к имени исполняемого модуля и POST запросу), по вероятности (допустим с вероятностью 1/100 обновляется кэш).
То что заголовки страниц определяются в 50% случаев - надо проверить правильно ли удаляются пробелы и комментарии.
То что страница из кэша отдается медленнее чем страница из БД это немного грустно, но надо учесть что
а) Более высокое время генерации страницы не означает более высокую нагрузку
б) Возможно БД шустрее ФС (например если БД на отдельном сервере мощном, а ФС на перегруженном слабом)
в) Файл это не некий "сферический конь в вакууме". Обращение к файлу занимает время. И если допустим идет 4 инклуда файлов кэша плюс все равно идет пара запросов в БД, то это может реально оказаться дольше по времени, чем 6 запросов в БД. Наличие кэширования хорошо, но настройка кэширования не менее важно.
г) "Паразитное сжатие" на время генерации влияет.
Да мы согласны.
А вот по поводу "школьный хостинг". Э, собственно "школьники" нередко берут сервера подальше от "органов", на западе, где ДЦ не имеют таких проблем ни с перегревом ни с обменом траффика между операторами. Так что вопрос сложный, впрочем не для этого топика.
В ДЦ несколько более другая пропорция потребляемой мощности (количества выделяемого тепла) на кв.м..
P.S.: Это не оправдание мастерхосту конечно, это объяснение почему в ДЦ все сложнее.
Если vbulletin тут стандартный, то зная пароль сменить e-mail не проблема. И подтверждение нового мыла уходит на новый e-mail.
Даниил (2), Ваш стиль призывов к справедливости не направлен на возбуждение желания помочь Вам.
Так ведь задача клоакинга не стоит, так что разницы нет.
Кривой или нет, а vbulletin и некоторые другие не мелкие скрипты его используют и никто не ворчит:)
А в чём Вы кривость видите? Это же определение бота, а не администратора и вполне с легальными целями.
Тема конечно старенькая, но тем не менее.
1) По поводу "поисковики VS вобла"
includes/init.php
$show['search_engine'] = ($vbulletin->superglobal_size['_COOKIE'] == 0 AND preg_match("#(google|msnbot|yahoo! slurp)#si", $_SERVER['HTTP_USER_AGENT']));
добавьте сюда нужное количество поисковиком по аналогии. Не уверены влияет ли это на сессии, но должно.
Ходят слухи что в совсем последних версиях воблы в конфиге ещё поисковики прописываются - честно говоря не проверяли.
1.1) В вобле 3.0-1.х версий был файл includes/sessions.php - там было нечто аналогичное по поводу поисковиков и как раз зависела активация сессий от этого.
2) По поводу карты сайта:
Есть определённый смысл закрыть от индексации все кроме "архива"
Там все чисто, аккуратно.
3) И всяко в robots.txt надо закрывать профили пользователей, создание новых тем и т.д.
Лениво тестить, да и думаем не только нам.
Можете накатать коротенькое сравнение с cpanel по функционалу?
Что есть там и нет у Вас и наоборот.
Может и заинтересовались бы.
Не пропал. Виден. Залогинены.
