|
Notes |
|
|
|
|
Это он лезет не для отображения, а для закачки. Поставь режим "Только кэш" и проверь. |
|
|
|
|
|
В общем нужно просто вводить еще один уровень кэширования внутри тайлохранилищ. Что бы кэшировались в памяти не уже распакованные битмапки и векторы, а исходные бинарные тайлы и инфа о них. И ограничение в этих кэшах ставить не по штукам тайлов, а по объему используемой памяти. |
|
|
|
|
|
Тогда скорость отображения тайлов ещё больше просядет. |
|
|
|
|
|
С какого перепугу она просядет? |
|
|
|
(0005803)
|
|
zed
|
|
05-03-2012 06:30
|
|
>Поставь режим "Только кэш" и проверь.
Да, в этом режиме лишних телодвижений нет. |
|
|
|
(0005804)
|
|
vasketsov
|
05-03-2012 07:46
(edited on: 05-03-2012 07:47) |
|
Потому что:
а) при показе их надо будет распаковывать, гуляя по закэшированному месту, много и много раз (добавь к этому наложенные слои).
б) вычисление общего размера супротив просто количества - ещё одна дополнительная Interlocked-сущность под примитивом синхронизации.
|
|
|
|
|
>а) при показе их надо будет распаковывать, гуляя по закэшированному месту, много и много раз (добавь к этому наложенные слои).
Это тут при чем? Я ж не предлагаю убирать старое кэширование готовых битмапок.
Я предлагаю добавить (и добавлю рано или поздно) еще одно.
>б) вычисление общего размера супротив просто количества - ещё одна дополнительная Interlocked-сущность под примитивом синхронизации.
По сравнению со временем обращения к диску Interlocked операция бесплатна. |
|
|
|
|
Хм. А как понимать
>Что бы кэшировались в памяти не уже распакованные битмапки и векторы
?
Будешь кэшировать один жпег с диска дважды (как файл и как распакованный битмап)?
Так кэш ФС будет делать это в третий раз. Он тоже будет кэшировать этот файл как файл. То, что в файлмоне показано обращение за файлом, означает лишь то что запрос испустился в ядро. Там запрос может запросто просто вернуться прямо из диспетчера кэша сразу взад. Экономишь переключение в режим ядра созданием своего кэша в пользовательском режиме дополнительно к уже существующему в ядре? |
|
|
|
(0005807)
|
|
zed
|
|
05-03-2012 08:01
|
|
>Я предлагаю добавить (и добавлю рано или поздно) еще одно.
А нельзя просто заюзать старое? Качалке ж как таковой тайл нафиг не нужен, ей достаточно знать "есть/нету". |
|
|
|
|
>Хм. А как понимать
Это нужно понимать как "В общем нужно просто вводить еще один уровень кэширования внутри тайлохранилищ."
>Так кэш ФС будет делать это в третий раз. Он тоже будет кэшировать этот файл как >файл. То, что в файлмоне показано обращение за файлом, означает лишь то что >запрос испустился в ядро. Там запрос может запросто просто вернуться прямо из >диспетчера кэша сразу взад. Экономишь переключение в режим ядра созданием своего >кэша в пользовательском режиме дополнительно к уже существующему в ядре?
Тога какие проблемы в проверке наличия тайла и получении его даты? Оно ж уже в кэше ФС закэешировалось. Тогда весь этот инцидент можно закрывать как ненужный. |
|
|
|
(0005809)
|
|
vasketsov
|
05-03-2012 08:45
(edited on: 05-03-2012 08:48) |
|
>Тога какие проблемы в проверке наличия тайла и получении его даты?
Наличие файла и даты "кэш" получает из "папкиных" метаданных. Которые тоже кэшируются. Так что тут тоже просто по обращению нельзя сказать, полез ли "кэш" на диск.
>Оно ж уже в кэше ФС закэешировалось.
Возможно.
>инцидент можно закрывать как ненужный
Не сказал бы. Что именно нужно качалке? Если Size и Date от файла - ну так тогда их и надо добавить в существующий кэш.
Правда есть ещё один косячок. Кэш в памяти должен работать не по карте (строго один на карту), а по уникальным NameInCache (если 2 zmp настроены на одну папку - причин может быть куча, например разные урлы с разных "каналов" - должен быть один кэш)*. Но это сюда только косвенно относится (так как просто кэш в памяти дублируется).
----------------
*) Точнее даже не по NameInCache, а по уникальным парам "тип кэша" + "то что получается после совокупления BasePath из настроек кэшей и NameInCache".
|
|
|
|
(0005810)
|
|
zed
|
|
05-03-2012 08:48
|
|
Кэширование ФС вещь ненадёжная и непостоянная, и в разных версия винды и на разных типах носителей/источников кэша работает (или может работать) по-разному. К тому же, а как быть если кэш не в ФС, а в БД. Это ведь по-любому лишний запрос.
Так что, лучше всё и вся, насколько это возможно, кэшировать самостоятельно. |
|
|
|
(0005811)
|
|
vasketsov
|
05-03-2012 09:03
(edited on: 05-03-2012 09:04) |
|
>работает (или может работать) по-разному
Очевидно да.
>К тому же, а как быть если кэш не в ФС, а в БД
Ну пока очевидно точно также.
А вообще пример конечно "хороший", так как ни один клиент (в смысле клиентская либа API) "взрослых" СУБД очевидно не кэширует пользовательские данные на своей стороне, ибо с другого компа их могут в это время произвольно модифицировать.
В кавычках "хороший" не потому что он нехороший, а потому что слово не смог подобрать, чтобы просто обратить внимание на это. Даже если и кэшировать данные, при запросе придётся проверять некий timestamp модификации в СУБД. В общем конечно погрязнуть там можно здорово, но пока не факт что этог можно или нельзя избежать. Но по крайне мере очевидно, то без запросов в СУБД актуальный локальный кэш над СУБД не удержать. В этом смысле 2 одновременно запущенных саса из одной папки будут получать согласованные значения GetFileAttributesEx() вот прямо сейчас и бесплатно, а два саса над СУБД - фигушки даже с локальным кэшем без дополнительных запросов к СУБД.
А с СУБД кстати тоже ещё неизестно что дешевле выйдет. Размер кэша в памяти на сервере БД может быть и под кучу гигов. В этом смысле запрос по сетке будет быстрее, чем забацать умный локальный кэш, соваться в него (поднимая его из свопа), обламываться (ведь он же маленький по сравнению с кэшем в СУБД) и всё равно (пусть и не всегда) обращаться к СУБД. По крайней мере гигабитная сеть сравнима с винтами или даже быстрее их (по крайней мере с моими на ноуте или десктопе), так что тут ещё неизвестно как обернётся.
|
|
|
|
(0005877)
|
|
vdemidov
|
06-03-2012 22:44
(edited on: 06-03-2012 22:45) |
|
Походу придется мириться с проверками FileExists не только в качалке, но и при отрисовке тайлов. Или делать кэширование хотя бы инфы о наличии тайлов на уровне тайлохранилища.
После добавления vasketsov версионности в кэш в памяти, карты с установленной версией и хранилищем не поддерживающим версионность (а такие все кроме GE) кэш в памяти просто перестает работать.
|
|
|
|
(0005883)
|
|
vasketsov
|
07-03-2012 05:12
(edited on: 07-03-2012 05:28) |
|
>кэш в памяти просто перестает работать
Не понял почему перестаёт. Ведь коли карта без версии - считай там все тайлы под одной "пустой" версией. Просто частный случай. А "карты с установленной версией и хранилищем не поддерживающим версионность" вообще не понял.
Пусть сверху скажем для гугла спустилось "дайте тайл версии 105" - кэш в памяти сказал "есть такое, получите" - в хранилище не полезли. Если кэш сказал "нету, валите читать с харда" - прочитали с установили версию в настройках карты 105 и вернули тайл как 105-й версии (который уже и сохранили в кэш в памяти). Где косяк-то? Если версия установлена, а хранилище ещё не поддерживает - там на выходе и на выходе должны быть только тайлы этой версии Static. Тоже частный случай, только немного другого порядка. А при смене версии в настройках надо очищать кэш в памяти (я б всегда чистил).
>о наличии тайлов на уровне тайлохранилища
А сейчас наличие тайла в кэше в памяти не означает неявное подразумевание его существования в кэше на харде? Я правда видимо не догоняю суть проблемы... Мне показалось что если в кэш в памяти добавить размер и дату оригинального файла, то при закачке тайла хранилище сможет отвечать ими на вопрос "есть ли у нас уже тайл", и потом заодно определять, надо ли его перекачивать.
|
|
|
|
|
>Если кэш сказал "нету, валите читать с харда" - прочитали
Но вернули пустую версию, так как в хранилище нет версионности. Сохранили в кэш с пустой версией. При следующей попытке чтения того же тайла все начинается сначала.
Из кэша результата никогда не будет. |
|
|
|
|
>Но вернули пустую версию
Не пустую, а указанную в настройках. Ровно ту же, которая, была запрошена.
В код сейчас я не глядел, но там версия как var должна передаваться, а не как out. Соответственно на входе Static, а если хранилище не поддерживает разные версии - оно её трогать вообще не должно - она же будет и на выходе из процы. Никто ж кроме хранилища не знает, поддерживает оно вот прямо сейчас версии или нет. |
|
|
|
|
>Не пустую, а указанную в настройках. Ровно ту же, которая, была запрошена.
Это будет неправильно. Например в берклидб информация о версии хранится, но не используется при поиске тайла. Так что ж ее просто терять вообще? |
|
|
|
|
Поэтому нужно делать так:
1. Запрос к тайлохранилищу о тайле.
2. Оно возрващает инфу о тайле в том числе реальную версию.
3. Если такой тайл вообще есть в хранилище, ищем в кэше готовых битмапок битмапку для тайла такой версии.
4. Если не нашли, то создаем и помещаем в кэш. |
|
|
|
|
|
Тоесть, нужно что бы тайлохранилище кэшировало в памяти инфу о тайлах. Скорее всего в этом кэше нужно ставить время жизни максимум пару минут, а еще лучше настраиваемое. |
|
|
|
|
>Например в берклидб
Ну как бы на то и пишутся _разные_ хранилища, чтобы само хранилище понимало, как версию парсить и что с ней делать.
>но не используется при поиске тайла
Может это какая-то другая версия, если её нельзя использовать в качестве версии при поиске тайла?
>Поэтому нужно делать так
Именно так и будет происходить, если хранилище, не поддерживающее версии (в смысле версий в настройках карты, а не в смысле каких-то других версий), не будет трогать переданную версию Static. Просто коли нет версий в хранилище, понятие "реальная версия" становится переопределимым как угодно. Можно с равным успехом считать в этом случае "реальной" как пустую версию (при этом будет ненужная процедура перехода от указанной версии к пустой версии), так и версию Static (которая, замечу, использовалась или будет использоваться при скачке тайла). |
|
|
|
|
|
Тайлохранилище не должно врать о версии тайла. И если не знает, должно возращать пустую версию. |
|
|
|
|
>И если не знает, должно возращать пустую версию
Возвращать оно должно ровно то, что туда положено, в том числе ту же версию.
Если при закладке тайла была версия V - он и должен вернуться с ТОЙ ЖЕ версией. Покуда в реальности у хранилища нет СВОЕЙ версии тайла - считай что хранилище доверило хранить версию самой карте и обещало её во всем слушаться. |
|
|
|
|
|
Это неправильно. Это ведет к потере информации. |
|
|
|
|
>Это ведет к потере информации
?
Невозможно потерять то, чего нет. |
|
|
|
|
|
Можно. Качаем в кэш берклидб, он сохраняет инфу о версии, но не ищет по ней. Экспортируем в любой кэш с поддержкой версии и вместо версии для тайлов получаем текущую выставленную версию. |
|
|
|
|
>он сохраняет инфу о версии
О какой версии? Откуда от её берёт и почему не ищет по ней?
>Экспортируем в любой кэш с поддержкой версии
Выше вроде обсуждалась ситуация, что кэш без версий? |
|
|
|
|
>О какой версии? Откуда от её берёт и почему не ищет по ней?
О той которая была установлена при закачке. Она сохраняется при сохранении в кэш скачанных файлов.
А не ищет по ней, потому что версия не входит в ключ, по которому идет поиск. Потому что так устроена текущая реализация кэша при помощи БерклиДб.
>Выше вроде обсуждалась ситуация, что кэш без версий?
Ну кэш в Беркли промежуточный вариант. И потом, ситуация же будет меняться. |
|
|
|
(0005907)
|
|
vasketsov
|
07-03-2012 10:33
(edited on: 07-03-2012 10:34) |
|
>версия не входит в ключ, по которому идет поиск
ну так значит надо сделать чтобы входила в ключ, во всех отношениях это будет правильнее, нельзя быть немножко версионным
|
|
|
|
|
Зачем? Может мне просто нужно иметь инфу о версии тайла, но не нужно хранить все версии. Хватит последней скачанной.
Неправильно, это терять инфу в тех местах, где ее можно легко сохранить.
|
|
|
|
|
>Может мне просто нужно иметь инфу о версии тайла, но не нужно хранить все версии
Тогда это не версионное хранилище, а обычное неверсионное, которое зачем-то сохраняет в качестве непонятного бонуса текущее значение параметра скачки, никакого отношения к _хранилищу_ не имеющего.
>Неправильно, это терять инфу
Неправильно обсуждать реализацию недоверсионного хранилища на языке версионного, а также вносить изменения в логику версионных и неверсионных хранилищ исходя из недоделанного недоверсионного. Версионное умеет выдавать разные тайлы на запросы разных версий - это основная суть версионности хранилища. Если в неверсионное хранилище надо сохранить некий бонус - так пусть это и называется "некий бонус", а не "версия тайла в хранилище". |
|
|
|
|
>Из кэша результата никогда не будет
Нечто похожее сейчас реализуется для GE и GC.
Покуда версию в настройках карты можно указать как 2011:11:11[History], а возвращаться будут тайлы с версией скажем 2011:11:11\88[History] - кэш в памяти фактически не работает для таких тайлов. А если указать в настройках карты полный формат 2011:11:11\88[History] - работает. |
|
|
|
|
|
Именно поэтому я и говорю, что к тайлохранилищу обязательно должно быть обращение как минимум за информацией о версии тайла актуальной для текущей настройки. А уже потом поиск распакованной картинки в кэше битмапок по конкретной версии. А уже тайлохранилище должно кэшировать такие вещи у себя. |
|
|
|
(0006196)
|
|
vasketsov
|
18-03-2012 21:35
(edited on: 18-03-2012 21:46) |
|
>к тайлохранилищу обязательно должно быть обращение как минимум за информацией о версии тайла актуальной для текущей настройки
По времени это будет просто убийство. Коли из хранилища вернулась инфа о версии тайла - так сразу и тайл доступен считай, версия всегда рядом лежит, а если ещё и искать надо по хранилищу....
Так что всё намного хитрее должно быть.
Вообще пора бы определиться, кэш в памяти кэширует запрошенную версию или отвеченную. Настоятельно предлагаю кэшировано запрошенную, это решит ровно все проблемы, кроме одной, которая называется "сменили версию в настройках карты - надо сбросить кэш" и это самая редкая проблема и наиболее просто решаемая просто очисткой кэша в памяти. Иначе придётся создавать кэш для ответов как функцию (x,y,z,v1) -> v2. Впрочем будет ещё проблема. Если к одной карте будут ходить с 2-мя разными версиями (одна для отображения, другая для параллельной скачки или экспорта), но до этого совсем далеко.
А так конечно можно вообще всё кэшировать, и обе версии (запрос и ответ), и tne и дату и размер).
|
|
|
|
(0006422)
|
|
zed
|
|
12-04-2012 19:53
|
|
О блин, ещё одну жесть увидел:
- кэш чистый
- включены карта и слой
- режим "интернет + кэш"
- при запуске SAS начинает загружать тайлы (всего в итоге загружено 95 тайлов)
- функция TileStorage.LoadTile вызвалась 7 тыс.(!) раз для карты и 11 тыс. (!) раз для слоя.
Это просто феерическое безобразие. Наблюдать его можно в обновлённом окошке DebugInfo.
Ноги растут из одного места или заводить новый баг? |
|
|
|
|
Ну вполне логично особенно если процессор быстрый, а инет медленный. Тайлов нет. Соответственно 95 раз в пустую. Плюс перед закачкой каждого тайла одна проверка на его наличие +95. И максимум полсе загрузки каждого тайла при старом способе рисования он пытается загрузить все 95. Итого 95*95+2*95=9215. Так что все правильно. Попробуй с новым основным слоем.
В секции [View]
UseNewMainLayer=1 |
|
|
|
(0006424)
|
|
zed
|
|
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 |
|
|
|
|
|
А. Ну да. Я забыл что еще не успел добавить выборочное обновление при изменении тайла. Но в любом случае кэширование на уровне тайлохранилища необходимо. |
|
|
|
(0007304)
|
|
zed
|
|
03-06-2012 19:27
|
|
Сделал кэширование запросов GetTileInfo (см. https://bitbucket.org/azya/sasplanet/changeset/86f6fcc4e35c ).
По-идее, если тайл в кэше найден, то его инфу можно и не кэшировать (на уровне хранилища), поскольку эти запросы нагрузку особо создавать не должны. Основная нагрузка идёт от запросов на отсутствующий тайл, т.е. можно кэшировать только их, что в общем-то говоря, сильно уменьшит потребление памяти для дополнительного кэширования. |
|
|
|
|
Простите, может вопрос и глупый, но разве после New(VTile) не надо память освобождать в .Add?
И размер кэша ограничивается временем жизни, которое почти 50 дней?! Т.е. память он может отъедать будь здоров ...
И ещё, GetTickCount переполнится через 50 дней и проверка на TTL будет выдавать неправильный результат, ничего вроде бы страшного, но кэш будет затирать не старые ячейки, а произвольные. (Упс, у меня та же ошибка...)
А вообще здорово! Вот бы ещё такое же кэширование прикрутить к остальным хранилищам (и начать с u_TileStorageFileSystem.pas) ... |
|
|
|
(0007307)
|
|
zed
|
|
03-06-2012 20:57
|
|
>после New(VTile) не надо память освобождать в .Add
Не надо. Память освобождается при удалении записи или очистке кэша.
>почти 50 дней?!
Неа - 30 секунд всего. |
|
|
|
|
|
Извиняюсь, вопрос глупый, увидел. И про размер и про 30с. |
|
|
|
|
|
Попробуй сейчас с новым слоем. Я сейчас, наконец, сделал частичное обновление экрана по изменению тайла. Так что если поменялся один тайл, то только один будет и обновляться, максимум 2 при изменении проекции. |
|
Filemon.LOG (7,424) 04-03-2012 19:23