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

Содержимое текстового файла как-то обрабатывается или просто выводится?

kil просто выдается всё содержимое целиком, тоесть php+mysql генерирует некий готовый блок

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

А вы уверены что чтение из файлов быстрее, чем запрос к базе, тем более на таблице с индексом и кешем в пул сервера?

ну ещё нужно учитывать время подключения и величину базы...

да безусловно быстрей, необходимо создать кеш не нуждающийся в мускуле. Так как мускул на серваке нежный :) сервак слабенький VDS. Приходится оптимизировать на будуещее по максимуму.

KosoyRoman, не забывайте, что файловый кеш тоже создаёт нагрузку, на файловую систему, особенно, когда этих файлов будет много.

сейчас думаю вот над чем.. есть ли смысл или вообще есть ли какая разница если сделать функцию и вызываьт её несколько раз чем просто вбивать один код с разным id раздела несколько раз?

Подключаться то вам все равно подключаться =) Неужели у вас система каким то хитрым образом определяет какой файл нужно выдать, не сверяясь с базой? Ну допустим если ссылки - ЧПУ "не очень" (C), то можно по id сразу файл брать. Но все таки, а вдруг вам захочется службу статистики написать, или авторизации. В общем к базе то рано или поздно придется подключаться by default, имхо. А величина базы в общем то, если она не выходит за границы логического носителя, при наличии грамотно составленного индекса роли особенно не сыграет.

Так, небольшое лирическое отступление: индексы в mysql представляют собой B-деревья с хэш-ключами. В B-дереве время поиска составляет log(N, XN/(N+1)), где N порядок дерева, а X число элементов. Или по-другому log(N, X-X/(N+1)). Можно было бы тут позаниматься численными иследованиями, но суть давно известна - зависимость логарифмическая с основанием N, т.е. грубо говоря, при увеличении числа записей в таблице индексов в N раз, поиск в худшем случае замедляется на один шаг. Т.е. при порядке дерева в 30 (я не знаю сколько точно использует муська, наверное в зависимости от размера записи индекса), увеличение числа страниц с 2700 до 81000 замедлит время поиска в среднем всего на 25%

И все бы хорошо, ведь для чтения файла не надо никаких индексов, он читается по прямой ссылке. Но маленький момент - если на сервер достаточно существенная нагрузка (ну хотя бы 5-10 хитов в секунду), и запрашивают достаточно много разных страниц, то дисковый кеш истощит свои бонусы очень быстро, по сравнению с пулом СУБД, и тут конечно хранение кешированных (и еще бы сжатых) страниц в отдельной табличке с грамотным индексом сильно помогает...

neolord добавил 02.06.2008 в 16:06

Да поможет тебе XCache... 🚬

А об обновлении БД-шного кеша вы думали? Обновление индексов при update или insert тоже не самая медленная процедура при большой базе.

Это не значит, что я против одного или другого способа, просто нужно смотреть по факту что будет подтормаживать систему, а затем исправлять этот участок. Пока что трудно о чём-то говорить ибо сайт вроде бы работает оперативно. И не факт, что оптимизацией будет внесены лишние ненужные факторы, которые приведут к не совсем желаемому результату...

Да, вот только update и insert бывают гораздо реже, чем select как правило :)