SASGIS - SAS.Планета
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000992SAS.Планета[All Projects] Хотелкаpublic10-10-2011 17:1610-10-2012 11:49
Reporterzed 
Assigned Tovdemidov 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformWindowsOSXPOS VersionSP3
Product Version110418 
Target Version120808Fixed in Version120808 
Summary0000992: Сделать многопоточную загрузку тайлов в режиме просмотра карт
DescriptionИ тут речь именно о режиме просмотра, а не о загрузке выделенной области.
В общем-то, давно такое желание возникло и уже с полгода как я начал неспеша это реализовывать (ветка Threaded в репах). И вроде бы, оно уже готово - берём exe из аттача и тестируем. Там специальная версия, с хардкодно заданным числом потоков на карту = 12, плюс игнорируется параметр Пауза для карты, так что на гугла сильно не наседайте, бо могут быстро забанить. В релизной версии число потоков будет браться из параметра MaxConnectToServerCount в zmp (если параметр отсутствует, как сейчас во многих картах, то берётся по дефолу = 1, т.е. пока мы этот счётчик не подкрутим, САС в кучу потоков качать не будет), ну и, соответственно, Пауза будет учитываться как положено.
Steps To Reproduce
Additional Information
Tagsзагрузка, закачка, потоки
Relationships
related to 0001046closed zed Вынести в настройки дефолтное число потоков для карты (MaxConnectToServerCount) 
related to 0000664closed vdemidov Хотелось бы больше одновременных соединений 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
10-10-2011 17:16zedNew Issue
10-10-2011 17:16zedFile Added: SASPlanet.MultiThreaded.zip
10-10-2011 17:17zedFile Added: Image 1.png
10-10-2011 17:21zedNote Added: 0004068
10-10-2011 17:33TolikNote Added: 0004069
10-10-2011 18:59vasketsovNote Added: 0004070
10-10-2011 19:11zedNote Added: 0004071
10-10-2011 19:25zedNote Edited: 0004071bug_revision_view_page.php?bugnote_id=4071#r2046
10-10-2011 20:08vasketsovNote Added: 0004072
10-10-2011 20:11vasketsovNote Edited: 0004072bug_revision_view_page.php?bugnote_id=4072#r2048
10-10-2011 20:14vasketsovNote Edited: 0004072bug_revision_view_page.php?bugnote_id=4072#r2049
11-10-2011 04:38zedNote Added: 0004073
11-10-2011 07:33vasketsovNote Added: 0004075
14-10-2011 06:53gpsMaxTag Attached: загрузка
14-10-2011 06:53gpsMaxTag Attached: закачка
14-10-2011 13:15TolikAssigned To => zed
14-10-2011 13:15TolikStatusnew => assigned
14-10-2011 14:20zedFile Deleted: Image 1.png
14-10-2011 14:20zedNote Deleted: 0004068
20-10-2011 16:57TolikNote Added: 0004125
20-10-2011 17:52zedNote Added: 0004126
28-10-2011 21:55zedNote Added: 0004217
28-10-2011 22:05zedNote Added: 0004218
28-10-2011 22:07zedNote Edited: 0004218bug_revision_view_page.php?bugnote_id=4218#r2130
29-10-2011 06:29TolikNote Added: 0004221
29-10-2011 06:57zedNote Added: 0004223
30-10-2011 07:14TolikNote Added: 0004228
30-10-2011 13:28zedNote Added: 0004231
30-10-2011 13:29zedNote Edited: 0004231bug_revision_view_page.php?bugnote_id=4231#r2142
03-11-2011 19:09gpsMaxTag Attached: потоки
16-11-2011 12:17zedRelationship addedrelated to 0001046
25-11-2011 14:04zedFile Deleted: SASPlanet.MultiThreaded.zip
25-11-2011 14:05zedStatusassigned => resolved
25-11-2011 14:05zedFixed in Version => 24xxxx
25-11-2011 14:05zedResolutionopen => fixed
28-11-2011 16:47zedAssigned Tozed =>
28-11-2011 16:47zedStatusresolved => acknowledged
28-11-2011 16:52zedNote Added: 0004445
28-11-2011 18:10vdemidovNote Added: 0004446
28-11-2011 18:53zedNote Added: 0004447
28-11-2011 18:57zedNote Edited: 0004447bug_revision_view_page.php?bugnote_id=4447#r2205
28-11-2011 19:50vdemidovNote Added: 0004448
28-11-2011 19:51vdemidovStatusacknowledged => resolved
28-11-2011 19:51vdemidovFixed in Version24xxxx => 120808
28-11-2011 19:51vdemidovAssigned To => vdemidov
28-11-2011 19:54zedNote Added: 0004449
28-11-2011 20:08zedNote Added: 0004450
28-11-2011 20:10zedNote Added: 0004451
21-12-2011 17:45zedNote Added: 0004559
22-12-2011 05:42TolikFixed in Version120808 => 24xxxx
22-12-2011 05:42TolikTarget Version => 24xxxx
23-01-2012 08:25vdemidovFixed in Version24xxxx => 120808
23-01-2012 08:25vdemidovTarget Version24xxxx => 120808
23-01-2012 10:51vdemidovProduct Version => 110418
04-02-2012 16:51zedRelationship addedrelated to 0000664
10-10-2012 11:49TolikStatusresolved => closed

Notes
(0004069)
Tolik   
10-10-2011 17:33   
Ну, типа, работает.
Тайлы быстрее загружаются, за раз появляется несколько.
Классно, ждём релиза.

Предлагаю установить по умолчанию не 1, а несколько. Неохота править все zmp, лучше исправить только проблемные.
(0004070)
vasketsov   
10-10-2011 18:59   
>Предлагаю установить по умолчанию не 1, а несколько
если не многопроцессорная тачка (кстати, ещё отдельный вопрос, как там это всё по процессорам раскидыватся) и не гигабитный интернет в соседнем доме с хранилищем тайлов, от сильно больших значений проку не будет. больше 4-х я б уж точно не ставил.

>числом потоков на карту = 12
А пробовал с меньшим числом, но через IoCompletion (чтобы тупо потоки не расходовать зазря)?
(0004071)
zed   
10-10-2011 19:11   
(edited on: 10-10-2011 19:25)
>больше 4-х я б уж точно не ставил
Так, для информации: фришная версия GoogleEarth работает в 4 потока, PRO-шная - в 8 или 12, точно не помню. Так что, 12 по-моему само то.

>кстати, ещё отдельный вопрос, как там это всё по процессорам раскидыватся
У меня 2-х ядерник, оба ядра загружаются равномерно.

>но через IoCompletion
Не слышал про такую штуку. И что значит "не расходовать зазря"?
(0004072)
vasketsov   
10-10-2011 20:08   
(edited on: 10-10-2011 20:14)
Насчёт Iocompletion - найди книжку Рихтера "Программирование серверных приложений". Там объяснялась логика их использования. Общий смысл - экономия потоков и прочих ресурсов на относительно длительных однообразных операциях. При высоком уровне масштабируемости: кому надо - сделает себе 100500 потоков, кому надо - оставит 4.
Я когда-то давно писал с их помощью функцию копирования файлов на Native NT API. По сравнению с "проводниковой" работало быстрее раза в 1.5-2. А если файл копировался из локалки - то ещё больше была разница. На 2000-й винде это было.
И что такое "зазря" там тоже объяснятся. Навряд ли у меня лучше получится объяснить. Пусть тебя Native NT API не пугает: Рихтер им не пользуется, всё доступно и из Win32.

Если говорить о числе потоков "на карту", да ещё увеличить это в пару-тройку раз для включённых "гибридов", которые тоже надо скачивать - как раз и получишь "требуемые" 12. Логика ограничения числа потоков при обсуждаемой скачке должна работать суммарно для всех скачиваемых карт, а не для каждой по отдельности.
(0004073)
zed   
11-10-2011 04:38   
>Насчёт Iocompletion - найди книжку
Ну да, через месяцок, в лучшем случае, я может и найду для себя ответ на вопрос и вполне возможно, что придумаю как оптимизировать текущую реализацию многопоточности. А пока не придумано/не предложено более оптимального варианта, думаю и текущая реализация заслуживает внимания.

>должна работать суммарно для всех скачиваемых карт, а не для каждой по отдельности
Сейчас логика работает в 2-х направлениях:
1. Ограничивается суммарное число потоков для гуя (32 шт.)
2. Ограничивается число потоков для каждой отдельной карты
(0004075)
vasketsov   
11-10-2011 07:33   
>как оптимизировать текущую реализацию многопоточности
всё точно, это будет именно оптимизация. ибо IoCompletion (они же CompletionPort) - не более чем инструмент синхронизации, просто придуманный именно для ожидания завершения асинхронного ввода/вывода. фактически ждать приходится именно на окончании ввода-вывода, а не на дополнительных примитивах. потому и потоков можно меньше создавать, раз они общую очередь юзают, и работает в целом быстрее. Но повторюсь, это было кучу лет назад, сейчас может и не будет такого выигрыша в скорости/ресурсах.

>думаю и текущая реализация заслуживает внимания
конечно.
я право не хотел тебя обидеть, извини если тебе показалось обратное.
просто было интересно, может ты пробовал, но отказался по какой-либо причине от этого. а причин там может быть море.
если найду свою старую писанину (а она хрен знает на какой CD-юк скинута кучу лет назад) - кину ей в тебя. там правда пример очень простой, просто копирование файла, который тривиально делится на куски, а тут у тебя задачи куда посложнее, чтобы очереди оптимально огранизовать в том числе, ведь скорость скачки будет разная для разных сервисов.
(0004125)
Tolik   
20-10-2011 16:57   
> Merge with Threaded

В завтрашней сборке уже будет многопоточная?
Сколько будет по умолчанию?
(0004126)
zed   
20-10-2011 17:52   
Да. Но для гуя по-умолчанию, пока что 1, так что разницы особо заметно не будет. Единственное, что теперь гуй и загрузки по выделениям, будут качаться независимыми потоками (если в zmp будет разрешено более 1-го потока).
(0004217)
zed   
28-10-2011 21:55   
Увеличил максимальное число запросов для гуя до 32-х, теперь, по дефолту каждая карта в гуе качается своим потоком. Для того, чтобы ещё и конкретная карта начала качаться в несколько потоков, нужно в zmp прописать дополнительный параметр MaxConnectToServerCount с соответствующим числом:
MaxConnectToServerCount=4
(0004218)
zed   
28-10-2011 22:05   
(edited on: 28-10-2011 22:07)
vasketsov, можно вопрос?
Вот есть у меня поток, в котором выполняется как минимум 2 время-затратные операции: 1) Загрузка 2) Обработка скрипта (который в свою очередь тоже может ходить по интернетам). Чисто теоретически, можно ли этот поток превратить в некий класс и пустить его через эту очередь IoCompletion?

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

И да:
>если найду свою старую писанину
Кидай, интересно глянуть, что за зверь.
(0004221)
Tolik   
29-10-2011 06:29   
zed, Вы переделаете все карты в обоих репозиториях?
(0004223)
zed   
29-10-2011 06:57   
Не, репы трогать не надо. Надо дорабатывать САС, чтобы эти дефолтные настройки можно было вынести с гуй, а не как сейчас хардкодить.
(0004228)
Tolik   
30-10-2011 07:14   
В версии 4484 (и 4485) вообще не качаются карты Яндекс. Ошибка 400. Уж не знаю почему, надо срочно исправить.
(0004231)
zed   
30-10-2011 13:28   
(edited on: 30-10-2011 13:29)
см. баг 0001026
(0004445)
zed   
28-11-2011 16:52   
vdemidov там сегодня всё капитально переделал и теперь загрузка карты/слоя(ёв) происходит независимыми потоками, но каждая карта/слой качается опять в 1 поток. Поэтому, хотелку переоткрываю.
(0004446)
vdemidov   
28-11-2011 18:10   
Ты не прав. В один поток ставятся в очередь на загрузку. Максимум в очередь от UI-качальщика ставится 4 запроса. А уже у каждой карты есть свой пул потоков обработки очереди закачки. И количество потоков задается в каждом змп или если не задано, то берется глобальное MaxConnectToServerCount
(0004447)
zed   
28-11-2011 18:53   
(edited on: 28-11-2011 18:57)
Не знаю, где там подвох, соединений вроде и создаётся сколько положено, но загрузка идёт по очереди, а не одновременно (соединения видимо так же создаются по-очереди и так же по-очереди юзаются).
(0004448)
vdemidov   
28-11-2011 19:50   
Нашел. В u_ZmpInfo.pas почемуто не скопировался один из кусков твоего патча. И получалось, что по дефолту один обработчик закачек у каждой карты.
(0004449)
zed   
28-11-2011 19:54   
О, теперь всё работает :)
(0004450)
zed   
28-11-2011 20:08   
Хм, только число соединений с сервером оказывается больше чем MaxConnectToServerCount (хотя число потоков это число не превышает).
(0004451)
zed   
28-11-2011 20:10   
>И получалось, что по дефолту один обработчик закачек у каждой карты.
И при однопоточной загрузке с сервером было установлено 4 коннекта... что-то где-то ещё бажит?
(0004559)
zed   
21-12-2011 17:45   
А, понял в чём дело: если у карты несколько хостов (khm1.google, khm2.google и т.д.), и при этом они возвращают Keep-Alive, то либо сам wininet, либо используемый компонент, не разрывают коннект при обращении к новому хосту, а держит его где-то там у себя внутрях, до вызова явного дисконнекта. И получается, что если мы поставим 1 поток, у нас будет 4 коннекта (по числу хостов).
Это, в общем-то сильно не мешает, но вот такая фича появилась. Чтоб от этого избавиться (если вдруг чё), нужно: а) запоминать адрес последнего хоста к которому обращался данный поток и б) перед запросом тайла вызывать дисконнект, если текущий хост и последний не совпадают, ну и в) предварительно можно из пула потоков выбирать тот, который до этого тянул тайл с текущего хоста.