Чем плохи GET запросы с параметрами?

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

Выход вижу только один - для каждого запроса хранить набор данных который был использован при его первой генерации и проверять данные по этому списку. Но это означает, что к API взаимодействия с базой надо прикручивать функцию которая будет составлять список использованных блоков (так же как было для файлов), да еще и хранить для каждого объекта дату модификации. Как-то много телодвижений...

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

Отнюдь.

1. Далеко не все объекты системы являются контейнерами, отображение которых зависит от состояния других объектов.

2. В случае контейнера подходить нужно с другой стороны. Не при его выдаче опрашивать, от чего он зависит, а в модели указать список используемых им классов объектов и при модификациях любых объектов проверять отдельную таблицу связей, в которой расписано, кто от них зависит. И уже дёргать статус их обновления. Получается относительно сложно, но весьма эффективно. Можно, вообще, использовать статический кеш объектов, в том числе контейнеров, храня прямо html-файлы на диске. И этот кеш будет сам чиститься/обновляться при обновлении субэлементов контейнера.

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

Описанный же механизм связей используется именно в статическом кешировании. То есть, например, страница с профилем пользователя лежит статически на диске, но для неё в таблице зависимостей указано, что она зависит от объекта «пользователь Вася», так что когда этот «пользователь Вася» будет изменён, то кеш его профиля будет прибит. Отсюда один шаг и до механизма, работающего с IMS, но пока не требовалось :)

Так тут бутылочное горлышко не отдача страницы, а её генерация :)

Смотря какую задачу мы решаем. Несколькими постами выше человек плачет, что ЛОР грузится у него часами, кеш не работает и все такое. Это улучшит его ситуацию + снизит трафик. Повышение отдачи сервера - это другой вопрос.

А вот не понимаю: даже с жестким кэшированием (когда статика выдается только из кэша) яваскрипты почему-то все равно грузятся. На просторах интернета я не нашел, как это починить.

URLы должны быть читаемыми. А зачем?

Было недавно. Тут. И даже отдельно опрос создавался.

Можно, вообще, использовать статический кеш объектов, в том числе контейнеров, храня прямо html-файлы на диске

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

я не стал городить систему связей

Угу, велосипед выйдет знатный. Вывод результата напрямую из ORM - это упрощенный частный случай. А что если, например, данные возвращаются через хранимую процедуру? Или вообще берутся из другого сервиса? Или проходят адскую пост-обработку в бизнес-логике? Как с системой связей закешировать аггрегированую выборку из БД, на которой даже ключей-то нет? Плюс сюда нужно добавить зависимости от состояния сессии и входных параметров.

Основное бутылочное горлышко - это не генерация html'а, а обращения к БД / бизнес логике. Если обращения к БД сделать максимально независимым от количества обращений к сайту, то это решит вопрос на 90%. Добавить сюда стандартное кеширование выходного потока с интервалом 1-30сек, доступное из коробки и жизнь наладится.

.net + mvc предоставляет неплохие возможности для кеширования и умеренного велосипедостроительства в этом направлении.

А вот не понимаю: даже с жестким кэшированием (когда статика выдается только из кэша) яваскрипты почему-то все равно грузятся

Ну если у файла расширение js, не значит что это статичный контент. Может автор не хочет, чтобы ты его кешировал и шлет соответствующие заголовки. А может хочет чтоб кешировался, но либо руки не доходят, либо не обладает достаточными знаниями.

Память нынче дешевая.

Но не на сотни гигабайт :)

Кроме того, тот же nginx не умеет отдавать сразу данные от redis. Так что, как ни крути, нужен бэкенд. А значит — потеря производительности.

Вывод результата напрямую из ORM - это упрощенный частный случай. А что если, например, данные возвращаются через хранимую процедуру?

А какая разница? Главное, чтобы у объекта возвращался корректный modify_time.

Или проходят адскую пост-обработку в бизнес-логике?

Если обработка зависит только от этого объекта, то важен только его modify_time. Если параметры зависят ещё от других объектов, то нужно просто прописать зависимости. И при изменении тех объектов дёргать modify_time этого. Точнее, тут нужно говорить уже об update_time, так как modify_time самого объекта должен отражать только изменение его собственных данных.

Основное бутылочное горлышко - это не генерация html'а, а обращения к БД / бизнес логике.

Вот потому статическое кеширование и рулит :)

Redis сервер подходит гораздо лучше, чем файлы.

Обращение к файлам примерно в трое быстрее чем к хранилищу Redis. Это уже тестировано, перетестировано. Да первое обращение к файлу примерно такое же как к редиске, но когда файл попал в кэш, быстрее не работает ничто. Просто как раз, в качестве базы здесь мы используем Redis, хотя и пришлось переписать биндинг к Tcl, ибо тот, что есть не совсем рабочий... Вот только руки не доходят патч к пакету закоммитить...

Если обработка зависит только от этого объекта, то важен только его modify_time. Если параметры зависят ещё от других объектов, то нужно просто прописать зависимости. И при изменении тех объектов дёргать modify_time этого. Точнее, тут нужно говорить уже об update_time, так как modify_time самого объекта должен отражать только изменение его собственных данных.

Можно хранить контекст. Я Сохраняю все значения массивов типа SESSION, SESSIONDATA, REQUEST, USER (я думаю из названий ясно что в них) и использую их как идентификатор запроса.

Но не на сотни гигабайт :)

И на сотни тоже. Серверные 128ГБ стоят меньше $5k. Для задач, где нужны такие объемы - это копейки.

Так что, как ни крути, нужен бэкенд. А значит — потеря производительности.

Да это все фигня и экономия на спичках. Нет там потери. Особенно если включить кеш ответа сервера с устарением через пару сек.

какая разница? Главное, чтобы у объекта возвращался корректный modify_time.

Тогда нужно каждый объект заворачивать в обвертку, которая будет обеспечивать добычу этого time. А во view - разворачивать, чтоб отрисовать. Т.е. работа с кешем фактически перестает быть прозрачной.

Вот потому статическое кеширование и рулит :)

Ага, только еще с учетом состояния сессии, переменных, эти сотни гигабайт превратятся в террабайты кеша. Представляю - изменили немного хтмл и перестройка всего кеша на пол дня. Печалька. ИМХО - кеширование данных более профитно, чем хтмл. Кеш хтмл - это крайность :)
Хотя вариант тоже интересный.

Обращение к файлам примерно в трое быстрее чем к хранилищу Redis.

Я не знаю как у вас обращение к хешу медленнее чем к файлу. Ну да ладно :)

Примерно так:

 tclsh8.5 /home/alex/test.tcl
Чтение из redis: 88.898 microseconds per iteration
Чтение из файла: 17.785 microseconds per iteration

И это учитывая что я файл каждый раз открываю закрываю, а подключение к редиске держу открытым.

redis-benchmark -c 1 -d 20 -k 1
GET: <= 2ms

Кстати, redis через unix socket или tcp/ip? Через сокет должно быть быстрее.

И думаю когда в папке будет 10000+ файлов, результаты изменятся кардинально. Причем это будет зависеть от выбранной FS. А скорость редиса не изменится.

Через сокет конечно. На самом деле там достаточно серьёзные проблемы в биндинге. Он же тоже на тикле и там немного все понаварочено... Есть лишние операции - автор избегал coding by exception, хотя я думаю это не то место...

Я возьмусь как-нибудь запилить что-нибудь побыстрее, но для этого надо серию тестов пакета доделать, а это ж лениво.

Плюс там постоянное изменение кодировки - это добавил я так, как до этого пакет вообще не мог работать ни с какой кодировкой кроме ASCII.