ПХП с фалйма TXT | ускорение процесса

file_get_contents()

кроме того, подсмотрено в codeigniter`e . В начало файла писать таймстамп. когда читается время через файловую систему, то это всё же нагрузка на неё.

$cache = @fopen($file, "r"); 
$bt = fread($cache, filesize($file)); 
fclose($cache); 

заменить на

$cache = file_get_contents($file);

но значительного прироста это не даст

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

и еще надо избавиться от двух обращений к фс за датой:

if ((filemtime($file)) && (filemtime($file)>$times)) { 

что-то в этом роде

if (filemtime($file)>$times) { 

Спасбо, сдела как вы посоветовали, но прироста не ощютил. Может есть еще какие способы?

если тормозит - то сам принцип надо пересматривать. нет смысла оптимизировать сам код дальше - много не выжмешь

Сайт, который в подписи? Если он, то довольно терпимо работаем, по крайней мере, в данный момент.

Может у вас проблемы на пути от вас до сайта?

Я бы предложил такой вариант (который к сожалению подходит только для страниц без интерактивности):

При условии что кеш проверяется в первую очередь, а если его нет, выполняется 5+ запросов к БД, то можно воспользоваться вспомогательной таблицей например

cached_pages

{

id int

url smalltext

content text

timed bigint (сравнение быстрее чем tinytext)

}

и кеш выдавать примерно следующим образом:

$r=mysql_query("
SELECT SQL_CACHE 
`content` FROM `cached_pages`
WHERE `url`='".$_SERVER['REQUEST_URI']."'" AND `timed`>'".(time()-3600)."'");
if ($page=mysql_fetch_assoc($r))
  die($page['content']);
//формирование страницы и занесение её в базу путем UPDATE, и выдача клиенту

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

А если у вас MySQL 5, то лучше всего из этого запроса сделать VIEW, причем SQL_CACHE прописать и во VIEW, и в selectе в самом скрипте.

Тогда как только первый пользователь увидит страницу скажем путем 20 запросов, всем следующим хватит 1-го. Запрос в базу незначительно медленнее чтения файла, а если учесть кеширование запросов, то на больших объемах оно даже быстрее.

Два минуса : большой объем базы на крупных сайтах, и необходимость принудительного обновления кеша из админки, если скажем вы сделали что-то, что потребует новых ссылок на старых страницах.

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

P.S.Если речь идет про сайт в подписи - то на самом деле работает живенько, но вот у сервера время отклика че то великовато. Можт конечно это только у меня.

Нет сайт news45.ru пытаюсь уменьшить время генерации страницы по максимуму. Блоки новости выводят по тематикам, каждый из них кешируются отдельно. Щас попробую ваши варианты, позже отпишусь.

Да он у вас просто летает!!! Серьезно... Очень шустрый сайт. Даже я бы сказал - один из самых быстрых сайтов, которые я когда-либо видел....

Респект!

PG.t : 0.32 | DB.q : 7 | DB.t : 0.11

Я так понимаю что первое - это время генерации страницы, а не Postgress =)

Для страницы в 80 килобайт - очень неплохой показатель. Можно еще над запросами поколдовать наверное

было бы оригинально 0.32 запроса к БД :)

По-моему, тут случай, когда можно пока что ничего не делать. А когда возникнут проблемы, то искать узкое место.

Экранировать всё же стоит :)

И я думаю от греха подальше лучше хранить md5-хэш, а не request_uri, а на столбец положить индекс на первые 5-8 символов.