Как это реализовать? Кешировать файл с 10-ого запроса?

@moskvano Мне надо кешировать дохуя всего, а дисковое пространство ограничено. Нужно чтобы то, что запрашивается по 100 раз на дню, не удалялось из кеша.

@komar А не все ли кеширующие прокси так работают?

@qnikst Хуй знает, никогда не пользовался. Они ведут отдельную базу со статистикой?

@komar Ну есть срок хранения файла в кеше, этого вроде достаточно. Если он не запрашивается количество времени свыше данного срока, он удаляется. Сквид же все может вроде как.

@komar Держат список по частоте использования поднимая в нем файлы при повторном использовании например, если лимит пространства исчерпывается удаляют с конца. Вообще аспектов тут много, но основная идея кешей (и прокси в т.ч.) это именно твой юзкейс.

@moskvano Да хули мне с твоего срока хранения?

@qnikst О’кей, тогда воткну сквид и посмотрю.

@komar Экономит дисковое пространство.

@moskvano Съеби уже.

@komar Ты ебучка русская.

варнишъ

node.js

@qnikst # TAG: cache_replacement_policy # The cache replacement policy parameter determines which # objects are evicted (replaced) when disk space is needed. # # lru : Squid's original list based LRU policy # heap GDSF : Greedy-Dual Size Frequency # heap LFUDA: Least Frequently Used with Dynamic Aging # heap LRU : LRU policy implemented using a heap # # Applies to any cache_dir lines listed below this. # # The LRU policies keeps recently referenced objects. # # The heap GDSF policy optimizes object hit rate by keeping smaller # popular objects in cache so it has a better chance of getting a # hit. It achieves a lower byte hit rate than LFUDA though since # it evicts larger (possibly popular) objects. # # The heap LFUDA policy keeps popular objects in cache regardless of # their size and thus optimizes byte hit rate at the expense of # hit rate since one large, popular object will prevent many # smaller, slightly less popular objects from being cached. # # Both policies utilize a dynamic aging mechanism that prevents # cache pollution that can otherwise occur with frequency-based # replacement policies. # # NOTE: if using the LFUDA replacement policy you should increase # the value of maximum_object_size above its default of 4096 KB to # to maximize the potential byte hit rate improvement of LFUDA. # # For more information about the GDSF and LFUDA cache replacement # policies see http://www.hpl.hp.com/techreports/1999/HPL-1999-69.html # and http://fog.hpl.external.hp.com/techreports/98/HPL-98-173.html. #Default: # cache_replacement_policy lru

варнишъ поставь, ёпта. всё почти из коробки

@qnikst как сложно жить когда считаешь всех разработчиков мудаками, например

@mugiseyebrows > The LRU policies keeps recently referenced objects. > Default: cache_replacement_policy lru

@mugiseyebrows как сложно жить, когда общаешься намеками, например // я не сумел понять идею комментария и вижу слишком много разных интерпретаций

@qnikst Комар подразумевает что [все|многие] прокси работают неоптимально (не по уму) и спрашивает какие из них можно настроить на оптимальность // в этот раз он прав // [а я соснул]

@mugiseyebrows ясно, lru - один из банальных вариантов реализации /0, бывают неудачные варианты где оно будет тупить // или я чего-то тут не понимаю.

@qnikst Неудачный вариант — кеширование тайлов карт. Все пользователи смотрят обычно одно и то же, но один особо любопытный, пролистав всю планету в окошечке карты, сотрет мне к хуям весь кеш.

@komar а потом скинет всем ссылку и они туда ломанутся, но в кеше это не окажется т.к. алгоритм умный? LRU отвечает требованиям если памяти достаточно, т.к. те страницы, которые используются часто будут рядом с верхом.

@qnikst В кеше этого не окажется, и это хорошо.

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

@qnikst Она пропустит пять хитов и уйдет в кеш. LRU же запорет кеш для старой ссылки. Ну и информация к размышлению: полный кеш занимает терабайты.

@komar ок, тут видимо не самый понятный мне юзкейс, поэтому я лучше ретируюсь из данного обсуждения

@qnikst На, епт: http://waypoint.in/routes

@komar (посмотрел маршрут которым ходил), не, тут мне все равно не стало ничего ясно, т.к. имхо тут не совсем правильная постановка задачи, но т.к. мне не известна архитектура решения, то моё мнение не важно.

@qnikst Блядь, да что вы все такие непонятливые. Прочитай #DPWOYC. Вот это — проблема. Если меня отключат за неуплоту, то у меня сайт будет состоять из пустых прямоугольничков. С кешем, где хранится частоиспользуемое, у меня проблемы возникнут только тогда, когда юзер будет сильно листать карту в сторону.

@komar ты можешь по данным запроса понимать относится ли кусок карты к интересующей тебя части? Если да - фигачишь для каждой карты соотв. рамку, все запросы идут через мидлвару умеющую в это, если запрос попадает в нужный промежуток - посылаешь через любой кеш, иначе генеришь картинку сам. (Это если ты подходящее кеш решение не найдёшь) вообще в боюсь это в любом случае не очень работать будет.

@qnikst Да пошел ты нахуй со своим анальным цирком.

@komar y.w.