Направляющие - завершающие теги по сравнению с кэшированием страницы (кэш файла)
Этот ответ имеет хороший обзор того, как работают файлы WAV:
Просто сэмплируйте сигнал с фиксированными интервалами и запишите амплитуду с каждым интервалом в ваш файл.
[ 118] Это то, что делают BW.Write звонки. T представляет время.
Для воспроизведения звука эти данные идут после секции Hdr, которая является просто правильным заголовком для стандартного файла .wav. 0X46464952 означает «RIFF», а 0X45564157 - «WAVE». Игрок должен знать, с какой частотой была взята волна. В данном случае это 44100, что является общим стандартом.
3 ответа
Они действительно комплиментарны. Etags / fresh_when и т. Д. Помогут вам хорошо поиграть с нижележащими кешами (такими как ваши собственные экземпляры Varnish / Squid или Rack :: Cache, или кеш браузера, или прокси-серверы ISP…)
Кэширование страниц полностью избавляет вас от попадания в стек рельсов, потому что Apache / ваш веб-сервер обслуживает файл, поэтому поиск в БД не выполняется. Но вы должны иметь дело с истечением срока действия кеша, чтобы поддерживать его в актуальном состоянии.
Используя etags / conditional get, вы не экономите много времени на обработку, поскольку вам все равно нужно получить все записи, используемые на странице:
def show
@article = Article.find(params[:id])
@feature = Feature.current
fresh_when :etag => [@article, @feature]
end
в в случае, если у пользователя есть текущая страница, это сэкономит вам некоторое время на рендеринг и полосу пропускания, необходимую для отправки страницы вниз.
One thing that comes to mind is that fresh_when will still save you some rendering even if you cleared the entire page cache. Here you'd be using both in tandem.
I'm curious about other answers as well.
Another use that occurred to me was that you could still process some information before letting Rails hand out the "304 Not Modified" header. Like if you want to record hits to a page.