0001200: Добавить кэширование тайлов на уровне тайлохранилища

Notes
(0005799) vdemidov (manager) 04-03-2012 20:22	Это он лезет не для отображения, а для закачки. Поставь режим "Только кэш" и проверь.

(0005800) vdemidov (manager) 04-03-2012 22:30	В общем нужно просто вводить еще один уровень кэширования внутри тайлохранилищ. Что бы кэшировались в памяти не уже распакованные битмапки и векторы, а исходные бинарные тайлы и инфа о них. И ограничение в этих кэшах ставить не по штукам тайлов, а по объему используемой памяти.

(0005801) vasketsov (manager) 04-03-2012 23:22	Тогда скорость отображения тайлов ещё больше просядет.

(0005802) vdemidov (manager) 05-03-2012 04:40	С какого перепугу она просядет?

(0005803) zed (manager) 05-03-2012 06:30	>Поставь режим "Только кэш" и проверь. Да, в этом режиме лишних телодвижений нет.

(0005804) vasketsov (manager) 05-03-2012 07:46 edited on: 05-03-2012 07:47	Потому что: а) при показе их надо будет распаковывать, гуляя по закэшированному месту, много и много раз (добавь к этому наложенные слои). б) вычисление общего размера супротив просто количества - ещё одна дополнительная Interlocked-сущность под примитивом синхронизации.

(0005805) vdemidov (manager) 05-03-2012 07:50	>а) при показе их надо будет распаковывать, гуляя по закэшированному месту, много и много раз (добавь к этому наложенные слои). Это тут при чем? Я ж не предлагаю убирать старое кэширование готовых битмапок. Я предлагаю добавить (и добавлю рано или поздно) еще одно. >б) вычисление общего размера супротив просто количества - ещё одна дополнительная Interlocked-сущность под примитивом синхронизации. По сравнению со временем обращения к диску Interlocked операция бесплатна.

(0005806) vasketsov (manager) 05-03-2012 07:56	Хм. А как понимать >Что бы кэшировались в памяти не уже распакованные битмапки и векторы ? Будешь кэшировать один жпег с диска дважды (как файл и как распакованный битмап)? Так кэш ФС будет делать это в третий раз. Он тоже будет кэшировать этот файл как файл. То, что в файлмоне показано обращение за файлом, означает лишь то что запрос испустился в ядро. Там запрос может запросто просто вернуться прямо из диспетчера кэша сразу взад. Экономишь переключение в режим ядра созданием своего кэша в пользовательском режиме дополнительно к уже существующему в ядре?

(0005807) zed (manager) 05-03-2012 08:01	>Я предлагаю добавить (и добавлю рано или поздно) еще одно. А нельзя просто заюзать старое? Качалке ж как таковой тайл нафиг не нужен, ей достаточно знать "есть/нету".

(0005808) vdemidov (manager) 05-03-2012 08:17	>Хм. А как понимать Это нужно понимать как "В общем нужно просто вводить еще один уровень кэширования внутри тайлохранилищ." >Так кэш ФС будет делать это в третий раз. Он тоже будет кэшировать этот файл как >файл. То, что в файлмоне показано обращение за файлом, означает лишь то что >запрос испустился в ядро. Там запрос может запросто просто вернуться прямо из >диспетчера кэша сразу взад. Экономишь переключение в режим ядра созданием своего >кэша в пользовательском режиме дополнительно к уже существующему в ядре? Тога какие проблемы в проверке наличия тайла и получении его даты? Оно ж уже в кэше ФС закэешировалось. Тогда весь этот инцидент можно закрывать как ненужный.

(0005809) vasketsov (manager) 05-03-2012 08:45 edited on: 05-03-2012 08:48	>Тога какие проблемы в проверке наличия тайла и получении его даты? Наличие файла и даты "кэш" получает из "папкиных" метаданных. Которые тоже кэшируются. Так что тут тоже просто по обращению нельзя сказать, полез ли "кэш" на диск. >Оно ж уже в кэше ФС закэешировалось. Возможно. >инцидент можно закрывать как ненужный Не сказал бы. Что именно нужно качалке? Если Size и Date от файла - ну так тогда их и надо добавить в существующий кэш. Правда есть ещё один косячок. Кэш в памяти должен работать не по карте (строго один на карту), а по уникальным NameInCache (если 2 zmp настроены на одну папку - причин может быть куча, например разные урлы с разных "каналов" - должен быть один кэш). Но это сюда только косвенно относится (так как просто кэш в памяти дублируется). ---------------- ) Точнее даже не по NameInCache, а по уникальным парам "тип кэша" + "то что получается после совокупления BasePath из настроек кэшей и NameInCache".

(0005810) zed (manager) 05-03-2012 08:48	Кэширование ФС вещь ненадёжная и непостоянная, и в разных версия винды и на разных типах носителей/источников кэша работает (или может работать) по-разному. К тому же, а как быть если кэш не в ФС, а в БД. Это ведь по-любому лишний запрос. Так что, лучше всё и вся, насколько это возможно, кэшировать самостоятельно.

(0005811) vasketsov (manager) 05-03-2012 09:03 edited on: 05-03-2012 09:04	>работает (или может работать) по-разному Очевидно да. >К тому же, а как быть если кэш не в ФС, а в БД Ну пока очевидно точно также. А вообще пример конечно "хороший", так как ни один клиент (в смысле клиентская либа API) "взрослых" СУБД очевидно не кэширует пользовательские данные на своей стороне, ибо с другого компа их могут в это время произвольно модифицировать. В кавычках "хороший" не потому что он нехороший, а потому что слово не смог подобрать, чтобы просто обратить внимание на это. Даже если и кэшировать данные, при запросе придётся проверять некий timestamp модификации в СУБД. В общем конечно погрязнуть там можно здорово, но пока не факт что этог можно или нельзя избежать. Но по крайне мере очевидно, то без запросов в СУБД актуальный локальный кэш над СУБД не удержать. В этом смысле 2 одновременно запущенных саса из одной папки будут получать согласованные значения GetFileAttributesEx() вот прямо сейчас и бесплатно, а два саса над СУБД - фигушки даже с локальным кэшем без дополнительных запросов к СУБД. А с СУБД кстати тоже ещё неизестно что дешевле выйдет. Размер кэша в памяти на сервере БД может быть и под кучу гигов. В этом смысле запрос по сетке будет быстрее, чем забацать умный локальный кэш, соваться в него (поднимая его из свопа), обламываться (ведь он же маленький по сравнению с кэшем в СУБД) и всё равно (пусть и не всегда) обращаться к СУБД. По крайней мере гигабитная сеть сравнима с винтами или даже быстрее их (по крайней мере с моими на ноуте или десктопе), так что тут ещё неизвестно как обернётся.

(0005877) vdemidov (manager) 06-03-2012 22:44 edited on: 06-03-2012 22:45	Походу придется мириться с проверками FileExists не только в качалке, но и при отрисовке тайлов. Или делать кэширование хотя бы инфы о наличии тайлов на уровне тайлохранилища. После добавления vasketsov версионности в кэш в памяти, карты с установленной версией и хранилищем не поддерживающим версионность (а такие все кроме GE) кэш в памяти просто перестает работать.

(0005883) vasketsov (manager) 07-03-2012 05:12 edited on: 07-03-2012 05:28	>кэш в памяти просто перестает работать Не понял почему перестаёт. Ведь коли карта без версии - считай там все тайлы под одной "пустой" версией. Просто частный случай. А "карты с установленной версией и хранилищем не поддерживающим версионность" вообще не понял. Пусть сверху скажем для гугла спустилось "дайте тайл версии 105" - кэш в памяти сказал "есть такое, получите" - в хранилище не полезли. Если кэш сказал "нету, валите читать с харда" - прочитали с установили версию в настройках карты 105 и вернули тайл как 105-й версии (который уже и сохранили в кэш в памяти). Где косяк-то? Если версия установлена, а хранилище ещё не поддерживает - там на выходе и на выходе должны быть только тайлы этой версии Static. Тоже частный случай, только немного другого порядка. А при смене версии в настройках надо очищать кэш в памяти (я б всегда чистил). >о наличии тайлов на уровне тайлохранилища А сейчас наличие тайла в кэше в памяти не означает неявное подразумевание его существования в кэше на харде? Я правда видимо не догоняю суть проблемы... Мне показалось что если в кэш в памяти добавить размер и дату оригинального файла, то при закачке тайла хранилище сможет отвечать ими на вопрос "есть ли у нас уже тайл", и потом заодно определять, надо ли его перекачивать.

(0005892) vdemidov (manager) 07-03-2012 06:02	>Если кэш сказал "нету, валите читать с харда" - прочитали Но вернули пустую версию, так как в хранилище нет версионности. Сохранили в кэш с пустой версией. При следующей попытке чтения того же тайла все начинается сначала. Из кэша результата никогда не будет.

(0005893) vasketsov (manager) 07-03-2012 06:07	>Но вернули пустую версию Не пустую, а указанную в настройках. Ровно ту же, которая, была запрошена. В код сейчас я не глядел, но там версия как var должна передаваться, а не как out. Соответственно на входе Static, а если хранилище не поддерживает разные версии - оно её трогать вообще не должно - она же будет и на выходе из процы. Никто ж кроме хранилища не знает, поддерживает оно вот прямо сейчас версии или нет.

(0005894) vdemidov (manager) 07-03-2012 06:11	>Не пустую, а указанную в настройках. Ровно ту же, которая, была запрошена. Это будет неправильно. Например в берклидб информация о версии хранится, но не используется при поиске тайла. Так что ж ее просто терять вообще?

(0005895) vdemidov (manager) 07-03-2012 06:14	Поэтому нужно делать так: 1. Запрос к тайлохранилищу о тайле. 2. Оно возрващает инфу о тайле в том числе реальную версию. 3. Если такой тайл вообще есть в хранилище, ищем в кэше готовых битмапок битмапку для тайла такой версии. 4. Если не нашли, то создаем и помещаем в кэш.

(0005896) vdemidov (manager) 07-03-2012 06:15	Тоесть, нужно что бы тайлохранилище кэшировало в памяти инфу о тайлах. Скорее всего в этом кэше нужно ставить время жизни максимум пару минут, а еще лучше настраиваемое.

(0005897) vasketsov (manager) 07-03-2012 06:41	>Например в берклидб Ну как бы на то и пишутся _разные_ хранилища, чтобы само хранилище понимало, как версию парсить и что с ней делать. >но не используется при поиске тайла Может это какая-то другая версия, если её нельзя использовать в качестве версии при поиске тайла? >Поэтому нужно делать так Именно так и будет происходить, если хранилище, не поддерживающее версии (в смысле версий в настройках карты, а не в смысле каких-то других версий), не будет трогать переданную версию Static. Просто коли нет версий в хранилище, понятие "реальная версия" становится переопределимым как угодно. Можно с равным успехом считать в этом случае "реальной" как пустую версию (при этом будет ненужная процедура перехода от указанной версии к пустой версии), так и версию Static (которая, замечу, использовалась или будет использоваться при скачке тайла).

(0005898) vdemidov (manager) 07-03-2012 07:17	Тайлохранилище не должно врать о версии тайла. И если не знает, должно возращать пустую версию.

(0005899) vasketsov (manager) 07-03-2012 07:40	>И если не знает, должно возращать пустую версию Возвращать оно должно ровно то, что туда положено, в том числе ту же версию. Если при закладке тайла была версия V - он и должен вернуться с ТОЙ ЖЕ версией. Покуда в реальности у хранилища нет СВОЕЙ версии тайла - считай что хранилище доверило хранить версию самой карте и обещало её во всем слушаться.

(0005900) vdemidov (manager) 07-03-2012 08:10	Это неправильно. Это ведет к потере информации.

(0005902) vasketsov (manager) 07-03-2012 09:06	>Это ведет к потере информации ? Невозможно потерять то, чего нет.

(0005903) vdemidov (manager) 07-03-2012 09:43	Можно. Качаем в кэш берклидб, он сохраняет инфу о версии, но не ищет по ней. Экспортируем в любой кэш с поддержкой версии и вместо версии для тайлов получаем текущую выставленную версию.

(0005904) vasketsov (manager) 07-03-2012 09:55	>он сохраняет инфу о версии О какой версии? Откуда от её берёт и почему не ищет по ней? >Экспортируем в любой кэш с поддержкой версии Выше вроде обсуждалась ситуация, что кэш без версий?

(0005906) vdemidov (manager) 07-03-2012 10:31	>О какой версии? Откуда от её берёт и почему не ищет по ней? О той которая была установлена при закачке. Она сохраняется при сохранении в кэш скачанных файлов. А не ищет по ней, потому что версия не входит в ключ, по которому идет поиск. Потому что так устроена текущая реализация кэша при помощи БерклиДб. >Выше вроде обсуждалась ситуация, что кэш без версий? Ну кэш в Беркли промежуточный вариант. И потом, ситуация же будет меняться.

(0005907) vasketsov (manager) 07-03-2012 10:33 edited on: 07-03-2012 10:34	>версия не входит в ключ, по которому идет поиск ну так значит надо сделать чтобы входила в ключ, во всех отношениях это будет правильнее, нельзя быть немножко версионным

(0005908) vdemidov (manager) 07-03-2012 10:54 edited on: 07-03-2012 10:54	Зачем? Может мне просто нужно иметь инфу о версии тайла, но не нужно хранить все версии. Хватит последней скачанной. Неправильно, это терять инфу в тех местах, где ее можно легко сохранить.

(0005916) vasketsov (manager) 07-03-2012 12:25	>Может мне просто нужно иметь инфу о версии тайла, но не нужно хранить все версии Тогда это не версионное хранилище, а обычное неверсионное, которое зачем-то сохраняет в качестве непонятного бонуса текущее значение параметра скачки, никакого отношения к _хранилищу_ не имеющего. >Неправильно, это терять инфу Неправильно обсуждать реализацию недоверсионного хранилища на языке версионного, а также вносить изменения в логику версионных и неверсионных хранилищ исходя из недоделанного недоверсионного. Версионное умеет выдавать разные тайлы на запросы разных версий - это основная суть версионности хранилища. Если в неверсионное хранилище надо сохранить некий бонус - так пусть это и называется "некий бонус", а не "версия тайла в хранилище".

(0006191) vasketsov (manager) 18-03-2012 19:18	>Из кэша результата никогда не будет Нечто похожее сейчас реализуется для GE и GC. Покуда версию в настройках карты можно указать как 2011:11:11[History], а возвращаться будут тайлы с версией скажем 2011:11:11\88[History] - кэш в памяти фактически не работает для таких тайлов. А если указать в настройках карты полный формат 2011:11:11\88[History] - работает.

(0006192) vdemidov (manager) 18-03-2012 21:07	Именно поэтому я и говорю, что к тайлохранилищу обязательно должно быть обращение как минимум за информацией о версии тайла актуальной для текущей настройки. А уже потом поиск распакованной картинки в кэше битмапок по конкретной версии. А уже тайлохранилище должно кэшировать такие вещи у себя.

(0006196) vasketsov (manager) 18-03-2012 21:35 edited on: 18-03-2012 21:46	>к тайлохранилищу обязательно должно быть обращение как минимум за информацией о версии тайла актуальной для текущей настройки По времени это будет просто убийство. Коли из хранилища вернулась инфа о версии тайла - так сразу и тайл доступен считай, версия всегда рядом лежит, а если ещё и искать надо по хранилищу.... Так что всё намного хитрее должно быть. Вообще пора бы определиться, кэш в памяти кэширует запрошенную версию или отвеченную. Настоятельно предлагаю кэшировано запрошенную, это решит ровно все проблемы, кроме одной, которая называется "сменили версию в настройках карты - надо сбросить кэш" и это самая редкая проблема и наиболее просто решаемая просто очисткой кэша в памяти. Иначе придётся создавать кэш для ответов как функцию (x,y,z,v1) -> v2. Впрочем будет ещё проблема. Если к одной карте будут ходить с 2-мя разными версиями (одна для отображения, другая для параллельной скачки или экспорта), но до этого совсем далеко. А так конечно можно вообще всё кэшировать, и обе версии (запрос и ответ), и tne и дату и размер).

(0006422) zed (manager) 12-04-2012 19:53	О блин, ещё одну жесть увидел: - кэш чистый - включены карта и слой - режим "интернет + кэш" - при запуске SAS начинает загружать тайлы (всего в итоге загружено 95 тайлов) - функция TileStorage.LoadTile вызвалась 7 тыс.(!) раз для карты и 11 тыс. (!) раз для слоя. Это просто феерическое безобразие. Наблюдать его можно в обновлённом окошке DebugInfo. Ноги растут из одного места или заводить новый баг?

(0006423) vdemidov (manager) 12-04-2012 20:14	Ну вполне логично особенно если процессор быстрый, а инет медленный. Тайлов нет. Соответственно 95 раз в пустую. Плюс перед закачкой каждого тайла одна проверка на его наличие +95. И максимум полсе загрузки каждого тайла при старом способе рисования он пытается загрузить все 95. Итого 9595+295=9215. Так что все правильно. Попробуй с новым основным слоем. В секции [View] UseNewMainLayer=1

(0006424) zed (manager) 12-04-2012 20:44	>Попробуй с новым основным слоем. Один фиг: /MapType/Hike Bike/FileSystem/LoadTile 14553 0,00002879 00:00.419 /MapType/Hike Bike/FileSystem/SaveTile 86 0,00144456 00:00.124

(0006425) vdemidov (manager) 12-04-2012 21:03	А. Ну да. Я забыл что еще не успел добавить выборочное обновление при изменении тайла. Но в любом случае кэширование на уровне тайлохранилища необходимо.

(0007304) zed (manager) 03-06-2012 19:27	Сделал кэширование запросов GetTileInfo (см. https://bitbucket.org/azya/sasplanet/changeset/86f6fcc4e35c ). По-идее, если тайл в кэше найден, то его инфу можно и не кэшировать (на уровне хранилища), поскольку эти запросы нагрузку особо создавать не должны. Основная нагрузка идёт от запросов на отсутствующий тайл, т.е. можно кэшировать только их, что в общем-то говоря, сильно уменьшит потребление памяти для дополнительного кэширования.

(0007306) Dima2000 (developer) 03-06-2012 20:54	Простите, может вопрос и глупый, но разве после New(VTile) не надо память освобождать в .Add? И размер кэша ограничивается временем жизни, которое почти 50 дней?! Т.е. память он может отъедать будь здоров ... И ещё, GetTickCount переполнится через 50 дней и проверка на TTL будет выдавать неправильный результат, ничего вроде бы страшного, но кэш будет затирать не старые ячейки, а произвольные. (Упс, у меня та же ошибка...) А вообще здорово! Вот бы ещё такое же кэширование прикрутить к остальным хранилищам (и начать с u_TileStorageFileSystem.pas) ...

(0007307) zed (manager) 03-06-2012 20:57	>после New(VTile) не надо память освобождать в .Add Не надо. Память освобождается при удалении записи или очистке кэша. >почти 50 дней?! Неа - 30 секунд всего.

(0007308) Dima2000 (developer) 03-06-2012 22:24	Извиняюсь, вопрос глупый, увидел. И про размер и про 30с.

(0007749) vdemidov (manager) 03-07-2012 05:13	Попробуй сейчас с новым слоем. Я сейчас, наконец, сделал частичное обновление экрана по изменению тайла. Так что если поменялся один тайл, то только один будет и обновляться, максимум 2 при изменении проекции.

Users who viewed this issue
User List	Anonymous (4469x), reindjer (1x), zed (1x), vdemidov (1x)
Total Views	4472
Last View	22-11-2024 02:20

Issue History
Date Modified	Username	Field	Change
04-03-2012 19:23	zed	New Issue
04-03-2012 19:23	zed	File Added: Filemon.LOG
04-03-2012 19:24	zed	Relationship added	related to 0001168
04-03-2012 20:22	vdemidov	Note Added: 0005799
04-03-2012 22:30	vdemidov	Note Added: 0005800
04-03-2012 23:22	vasketsov	Note Added: 0005801
05-03-2012 04:40	vdemidov	Note Added: 0005802
05-03-2012 06:30	zed	Note Added: 0005803
05-03-2012 07:46	vasketsov	Note Added: 0005804
05-03-2012 07:47	vasketsov	Note Edited: 0005804	View Revisions
05-03-2012 07:50	vdemidov	Note Added: 0005805
05-03-2012 07:56	vasketsov	Note Added: 0005806
05-03-2012 08:01	zed	Note Added: 0005807
05-03-2012 08:17	vdemidov	Note Added: 0005808
05-03-2012 08:45	vasketsov	Note Added: 0005809
05-03-2012 08:48	zed	Note Added: 0005810
05-03-2012 08:48	vasketsov	Note Edited: 0005809	View Revisions
05-03-2012 09:03	vasketsov	Note Added: 0005811
05-03-2012 09:04	vasketsov	Note Edited: 0005811	View Revisions
06-03-2012 22:44	vdemidov	Note Added: 0005877
06-03-2012 22:45	vdemidov	Note Edited: 0005877	View Revisions
07-03-2012 05:12	vasketsov	Note Added: 0005883
07-03-2012 05:28	vasketsov	Note Edited: 0005883	View Revisions
07-03-2012 06:02	vdemidov	Note Added: 0005892
07-03-2012 06:07	vasketsov	Note Added: 0005893
07-03-2012 06:11	vdemidov	Note Added: 0005894
07-03-2012 06:14	vdemidov	Note Added: 0005895
07-03-2012 06:15	vdemidov	Note Added: 0005896
07-03-2012 06:19	vdemidov	Assigned To	=> vdemidov
07-03-2012 06:19	vdemidov	Status	new => confirmed
07-03-2012 06:20	vdemidov	Product Version	.Nightly => 110418
07-03-2012 06:20	vdemidov	Target Version	=> 120808
07-03-2012 06:41	vasketsov	Note Added: 0005897
07-03-2012 07:17	vdemidov	Note Added: 0005898
07-03-2012 07:40	vasketsov	Note Added: 0005899
07-03-2012 08:10	vdemidov	Note Added: 0005900
07-03-2012 09:06	vasketsov	Note Added: 0005902
07-03-2012 09:43	vdemidov	Note Added: 0005903
07-03-2012 09:55	vasketsov	Note Added: 0005904
07-03-2012 10:31	vdemidov	Note Added: 0005906
07-03-2012 10:33	vasketsov	Note Added: 0005907
07-03-2012 10:34	vasketsov	Note Edited: 0005907	View Revisions
07-03-2012 10:54	vdemidov	Note Added: 0005908
07-03-2012 10:54	vdemidov	Note Edited: 0005908	View Revisions
07-03-2012 12:25	vasketsov	Note Added: 0005916
18-03-2012 19:18	vasketsov	Note Added: 0006191
18-03-2012 21:07	vdemidov	Note Added: 0006192
18-03-2012 21:35	vasketsov	Note Added: 0006196
18-03-2012 21:40	vasketsov	Note Edited: 0006196	View Revisions
18-03-2012 21:46	vasketsov	Note Edited: 0006196	View Revisions
12-04-2012 19:53	zed	Note Added: 0006422
12-04-2012 20:14	vdemidov	Note Added: 0006423
12-04-2012 20:44	zed	Note Added: 0006424
12-04-2012 21:03	vdemidov	Note Added: 0006425
03-06-2012 19:27	zed	Note Added: 0007304
03-06-2012 20:54	Dima2000	Note Added: 0007306
03-06-2012 20:57	zed	Note Added: 0007307
03-06-2012 22:24	Dima2000	Note Added: 0007308
19-06-2012 05:17	vdemidov	Assigned To	vdemidov =>
19-06-2012 05:17	vdemidov	Summary	Лишняя проверка FileExists при отображении тайлов из кэша => Добавить кэширование тайлов на уровне тайлохранилища
19-06-2012 05:17	vdemidov	Description Updated	View Revisions
19-06-2012 05:17	vdemidov	Steps to Reproduce Updated	View Revisions
03-07-2012 05:13	vdemidov	Note Added: 0007749
07-08-2012 14:59	vdemidov	Target Version	120808 => 121010
10-10-2012 10:25	vdemidov	Target Version	121010 => 131111
07-05-2013 13:36	vdemidov	Target Version	131111 => 24xxxx
13-02-2014 16:54	zed	Relationship added	child of 0001255
17-02-2015 09:52	zed	Status	confirmed => resolved
17-02-2015 09:52	zed	Fixed in Version	=> 150915
17-02-2015 09:52	zed	Resolution	open => fixed
17-02-2015 09:52	zed	Assigned To	=> zed
17-02-2015 09:53	zed	Target Version	24xxxx => 150915
31-07-2015 10:18	vdemidov	Relationship added	related to 0002708

SASGIS