все можно кешировать, даже там где идет подсчет, можно сначала складывать данные в MEMORY MySQL таблицы, а потом синхронизировать, можно просто складывать в ОЗУ, а через N-ное время сбрасывать в базу и т.п.

может кешировать, к примеру содержимое $_COOKIE (т.е. ту же сессию пользователя) можно дописать в паттерне обращения к memcached'у, следовательно nginx будет забирать для каждого пользователя страничку индивидуально из кеша :D

вообще ненормально порождать "долгоиграющие" скрипты, так как 1 процесс Апач с тем же mod_php выжирает приличное количество ОЗУ, что в случае большого количества "форков" полностью забьет все ОЗУ и пойдет в своппинг

прааальна, но:
1) количество коннектов можно четко регулировать еще на уровне файрвола
2) количество обращений от фронтэнда к бэкэнду, можно строго залимитировать допустим на уровне 150 конкурентных запросов, т.е. при большем количестве выдавать тот же 504, 502... но при этом не "ложить" сервер в глубокий своп...

все можно реализовать...

кончено, надо кешировать по возможности все на уровне скрипта, и постараться ускорить генерацию скрипта до минимального значения по времени, также надо постараться сократить обращения к io ... т.е. все кеши хранить в ОЗУ, аналогично надо постараться сократить MySQL запросы до минимума, при этом не порождать сложные объединенные запросы ... лучше сделать 10-20 простых запросов к базе и потом закешировать результат в ОЗУ, чем 10-20 запросов объединить в один сложный запрос...

а вообще все эти рассуждения пространственные, т.е. без реальной практики нет смысла рассуждать о нагрузке, т.е. это все достаточно индивидуально для каждого конкретного сайта :D

то что регулярками $_SERVER['REQUEST_URI'] расчщеплять это ясно. а как лучше вызывать физический файл, если file_get_contents не подходит. Не редиректом же!:) посоветуйте поконкретнее пожалуйста!

подходит file_get_contents, просто не надо делать http://.../, а дергать именно сам файл с диска :D

Зелёная морда смущает. Это прикол?

Кстати а при такой констукции post запросы вообще пройдут?

это не прикол

POST запросы пройдут, и GET и HEAD и ... все пройдет :D

Использовать http:// в file_get_contents стоит разве что если файл находитсяч на другом сервере, а если он на том-же сервере что и скрипт в котором написана указаная инструкция, то читать напрямую с диска будет значительно быстрее. ведт запросив файл через http:// вы заставите Тотже апач или нгинкс прочитать файл с диска и отправить его через сетевую

ага, всё ясно, спасибо. Значит буду пробовать:)

PS я не могу уже неделю создать новую тему на данном форуме, просто всегда пишет что-то про "неверный маркер безопасности..." написал о проблеме админу - изменения не произошли :(

К теме не относится, но если можно в таком случае спрошу здесь... О файле robots.txt
У меня на сайте есть в разных дирректория как и у многих файлик printversion.php - как вы понимаете печатная версия определённой странички.. Как прописать в robots.txt полный запрет на индексацию этих файлов? Если просто /printversion.php - всё равно сканирует всякие printversion.php?id=456 и т.д.... неприятно что в поисковых запросах вываливаются такие печатные версии, а не оригиналы... подскажите как прописать команду на устранение этой нечести..

И ещё вопрос про ЧПУ, опять про метод форстайп.. как я говорил выше, у меня физический путь к файлам будет таким: site.ru/folder/news/news.php?id=5 а ЧПУ по форстайпу, это уже файл без расширения просто site.ru/news
Вопрос перекрёстный с прошлым - а в robots.txt нужно будет прописать запрет на /folder? Или это всё уничтожит? Ведь я хочу чтобы сканировались поисковиками не физические пути к сайту, а ЧПУ, следовательно не смертельно запретить все дирректории на сайте с физическими путями к нему, оставив только файлы в корне для ЧПУ???

User-agent: Yandex
Disallow: /printversion.php

а вообще вам сюда: как яндекс robots.txt понимает

такие странички лучше запрещать к индексации не через robots.txt, а через соответствующий метатег :)

Manfred, Да. Вы правильно поняли. Можете запретить индексацию физических папок, к которым у вас будет доступ через ЧПУ с другими адресами.