SASGIS - SAS.Планета |
| View Issue Details |
|
| ID | Project | Category | View Status | Date Submitted | Last Update |
| 0003624 | SAS.Планета | [All Projects] Баг | public | 08-03-2020 18:25 | 01-06-2020 16:44 |
|
| Reporter | suregoodru | |
| Assigned To | zed | |
| Priority | normal | Severity | major | Reproducibility | always |
| Status | resolved | Resolution | fixed | |
| Platform | PC | OS | Windows | OS Version | 10 |
| Product Version | 191221 | |
| Target Version | 200606 | Fixed in Version | 200606 | |
|
| Summary | 0003624: Баг при зуме живых векторных слоёв, приводящий к росту потребления трафика и нагрузке на сервер, либо дублированию точек |
| Description | Если включена опция ""Брать векторные слои из меньших масштабов"", то в живом слое при зуме векторных слоёв, объекты размножаются делением. И старые объекты не пропадают с экрана. Из-за этого приходится ждать, пока объект переместится, чтобы понять, где актуальная позиция объекта. То есть, при истечении TTL векторные объекты взятые из других уровней зума остаются на экране
Если опцию "Брать векторные слои из меньших масштабов" выключить, то происходят лишние запросы к серверу, из-за чего очень сильно растёт трафик у клиента и нагрузка на сервер.
Живой слой у нас - это электрички и самолёты, эту информацию мы используем при проведении спасательных работ по поиску пропавших людей. Чрезвычайно полезная информация для нас, когда человек заблудился в лесу, но у него есть телефон. В эти моменты каждая секунда имеет значение, потому что у людей садится батарея, а с помощью этой информации мы можем примерно понять район, где человек находится |
| Steps To Reproduce | 0. Добавить слой, в Maps/sas.maps
1. В меню "Вид" включить опцию "Брать векторные слои из меньших масштабов"
2. Включить отображение слоя, у которого в params.txt указан ttl (слой во вложении)
3. Найти на карте точку слоя (например электричку), приблизить
4. Подождать, пока точка переместится (увидеть, что предыдущая точка не пропала)
Если опцию "Брать векторные слои из меньших масштабов" выключить, то будут происходить лишние запросы, расти потребление трафика у клиента и лишняя нагрузка на сервер, генерирующий слой |
| Additional Information | Скриншот демонстрации бага - https://drive.google.com/file/d/1yssqYubfSUsgrX5toMNCZLERWqWTgPCE/view?usp=sharing
Слой - во вложении |
| Tags | No tags attached. |
| Relationships | |
| Attached Files |  Extremum.zip (11,979) 08-03-2020 18:25
https://bugtracker.sasgis.org/file_download.php?file_id=2423&type=bug |
|
| Issue History |
| Date Modified | Username | Field | Change |
| 08-03-2020 18:25 | suregoodru | New Issue | |
| 08-03-2020 18:25 | suregoodru | File Added: Extremum.zip | |
| 08-03-2020 19:04 | zed | Status | new => confirmed |
| 08-03-2020 19:04 | zed | Product Version | .Nightly => 191221 |
| 08-03-2020 19:04 | zed | Target Version | => 211230 |
| 10-03-2020 08:28 | Belkin | Note Added: 0019678 | |
| 10-03-2020 08:34 | Belkin | Note Edited: 0019678 | bug_revision_view_page.php?bugnote_id=19678#r7625 |
| 10-03-2020 08:39 | borisovnick | Note Added: 0019680 | |
| 10-03-2020 08:49 | Antey | Note Added: 0019682 | |
| 10-03-2020 09:09 | zed | Note Added: 0019683 | |
| 10-03-2020 10:23 | Belkin | Note Added: 0019684 | |
| 10-03-2020 10:24 | Belkin | Note Edited: 0019684 | bug_revision_view_page.php?bugnote_id=19684#r7627 |
| 10-03-2020 10:24 | Belkin | Note Edited: 0019684 | bug_revision_view_page.php?bugnote_id=19684#r7628 |
| 10-03-2020 10:32 | zed | Note Added: 0019685 | |
| 10-03-2020 15:54 | zed | Note Added: 0019686 | |
| 10-03-2020 18:47 | zed | Note Added: 0019687 | |
| 11-03-2020 06:41 | omen98 | Note Added: 0019688 | |
| 11-03-2020 07:27 | zed | Note Added: 0019690 | |
| 11-03-2020 09:35 | omen98 | Note Added: 0019694 | |
| 11-03-2020 20:12 | Belkin | Note Added: 0019697 | |
| 11-03-2020 20:21 | Belkin | Note Edited: 0019697 | bug_revision_view_page.php?bugnote_id=19697#r7634 |
| 11-03-2020 20:23 | Belkin | Note Edited: 0019697 | bug_revision_view_page.php?bugnote_id=19697#r7635 |
| 12-03-2020 07:30 | zed | Note Added: 0019698 | |
| 16-03-2020 14:25 | suregoodru | Note Added: 0019712 | |
| 17-03-2020 06:54 | zed | Status | confirmed => resolved |
| 17-03-2020 06:54 | zed | Fixed in Version | => 211230 |
| 17-03-2020 06:54 | zed | Resolution | open => fixed |
| 17-03-2020 06:54 | zed | Assigned To | => zed |
| 01-06-2020 16:44 | zed | Target Version | 211230 => 200606 |
| 01-06-2020 16:44 | zed | Fixed in Version | 211230 => 200606 |
|
Notes |
|
|
(0019678)
|
|
Belkin
|
10-03-2020 08:28
(edited on: 10-03-2020 08:34) |
|
Версия 2012хх это же конец года, правильно?
Боюсь, что баг исправленный до конца апреля (т.е. до начала завала с поисково-спасательными работами) исчезнет для руководителей работ в этом году, а исправленный позже отразиться на поисковых буднях лишь с 2021 года
|
|
|
|
|
|
Да, пожалуй, пока это имеет место быть, я б не рискнул локализовать потерявшегося по движущимся объектам, не будучи уверенным, что он находится именно в этом месте, а не застрял в кэше. Так можно промахнуться на десяток километров. В итоге идея красивая и нужная, а из-за этого фантомного нюанса - пока получается нерабочая. |
|
|
|
(0019682)
|
|
Antey
|
|
10-03-2020 08:49
|
|
|
Поддерживаю, до начала сезона поисков бы сделать |
|
|
|
(0019683)
|
|
zed
|
|
10-03-2020 09:09
|
|
|
А на сколько больше происходит запросов к серверу, при отключённой функции "Брать векторные слои из меньших масштабов"? Вы делали реальные замеры? Просто, у вас и так каждые 7 секунд автоматически перезагружаются тайлы для видимой области, что само по себе приличная нагрузка. |
|
|
|
(0019684)
|
|
Belkin
|
10-03-2020 10:23
(edited on: 10-03-2020 10:24) |
|
Нагрузка от постоянного перезапроса живых слоёв на самом деле крайне смешная. По процессору 0,3-0,5% на каждом из серверов и трафик не заметен даже при условии, что одновременно происходит несколько спасработ в разных регионах. Даже если повключать все слои со всеми сервисами геолокации пострадавших, всеми трекерами, электричками там и прочим. Всё же они не для широкого использования. А вот прочие векторные слои на самом излёте сезона создавали по 100Гб трафика в месяц с довольно высокой нагрузкой по процессору. Плюс, люди отключившие кэш получают перезапросы и по Викимапии.
Есть ещё нюанс, тогда отрядов в одновременной работе было типично три, а SAS Планету сейчас внедряют несколько десятков (60 человек вот прям сейчас учатся из разных регионов). Сложно сказать сколько мы сэкономим на нагрузке, но думаю очень значительно, даже если всего лишь в три раза будет очень хорошо. Ну и все постоянно перестанут спрашивать почему у них в SAS Планете куча объектов появляется, часть из которых дублируется и не двигается — уже будет большой прогресс. Признаться, мне уже надоело отвечать что это баг такой в SAS Планете. И если я правильно понял, представители какого отряда написали баг, то они тоже спрашивали. Коллеги, спасибо что занялись, мне не разорваться!
|
|
|
|
(0019685)
|
|
zed
|
|
10-03-2020 10:32
|
|
|
Баг, безусловно надо фиксить, а вот то, что вы о нём давно знали и не сообщили - это зря. |
|
|
|
(0019686)
|
|
zed
|
|
10-03-2020 15:54
|
|
|
Да уж, загадка. Думал что это из-за того, что не приходят нотификации об изменениях в RAM кэше при TTL или переполнении кэша. Переделал нотификации, чтобы приходили, но метки всё-равно двоятся. |
|
|
|
(0019687)
|
|
zed
|
|
10-03-2020 18:47
|
|
Добавил ещё фикс в mem-кэше и кажется я понял из-за чего может наблюдаться такое поведение.
Поскольку векторные объекты двигаются, то между двумя обновлениями карты за время TTL, они могут оказаться на разных тайлах одновременно. Т.е. старое положение осталось на тайле A на предыдущем зуме (в кэше), а новое попало на тайл B на текущем зуме (загрузилось из интернета). Вот и проявляется опция Брать тайлы из меньших масштабов, показывая сразу 2 объекта. И единственное решение - очищать все кэши, что равносильно отключению опции, т.е. смысла особого нету.
Измените в zmp стратегию очистки кэша: MemCacheClearStrategy=0 - вкупе с сегодняшними изменениями, должно немного помочь.
Для статических слоёв типа Викимапии это не актуально. |
|
|
|
(0019688)
|
|
omen98
|
|
11-03-2020 06:41
|
|
|
Так в том то и дело, что TTL параметр не срабатывает при изменении зума - мы ушли на другой зум - а в предыдущем электричка зависла, и не счищается при истечении времени жизни тайла в кэше. а решение наверное верное - очищать все кэши для слоев с !TTL |
|
|
|
(0019690)
|
|
zed
|
|
11-03-2020 07:27
|
|
> и не счищается при истечении времени жизни тайла в кэше
Это вы после моих фиксов такое наблюдаете или по старой памяти? |
|
|
|
(0019694)
|
|
omen98
|
|
11-03-2020 09:35
|
|
|
По старой памяти. Доберусь до компа гляну обновку |
|
|
|
(0019697)
|
|
Belkin
|
11-03-2020 20:12
(edited on: 11-03-2020 20:23) |
|
По-моему, фикс сработал. Я не увидел никаких проблем, бесконечно делая зум туда-сюда у самолётов и электричек.
Update: да, значки не размножаются, но теперь они время от времени стали пропадать на несколько секунд. Кажется, что объекты отображаются через раз. Если выставить TTL 7000, то семь секунд значки есть, семь секунд их нет. Заменa CacheStrategy на ноль не помогла. На всякий случай проверил, что в предыдущей сборке значки не пропадают.
|
|
|
|
(0019698)
|
|
zed
|
|
12-03-2020 07:30
|
|
|
Исправил. Проявилась рассинхронизация между очисткой кэша по TTL и рестартом качалки. Сейчас будет всё согласованно: вначале очистка кэша, затем рестарт качалки. И теперь значки будут "моргать" - на время пока отрабатывает качалка они исчезают, а потом по мере загрузки появляются. |
|
|
|
|
Огромное спасибо.
Иконки, конечно, мерцают, но работать со слоями теперь стало гораздо удобнее и ошибок с местоположением быть не должно.
Хочется отдельное спасибо сказать за ваш инструмент. Его используют многие отряды спасателей поисковиков, не только в России, но и в ближайшем зарубежье (по крайней мере из тех, что знаю я). SAS.Планета невероятно помогает нам в планировании спасательных операций.
Вы делаете большое дело! |
|