View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000992 | SAS.Планета | Хотелка / Feature request | public | 10-10-2011 17:16 | 10-10-2012 11:49 |
| Reporter | zed | Assigned To | vdemidov | ||
| Priority | normal | Severity | minor | Reproducibility | have not tried |
| Status | closed | Resolution | fixed | ||
| Platform | Windows | OS | XP | OS Version | SP3 |
| Product Version | 110418 | ||||
| Target Version | 120808 | Fixed in Version | 120808 | ||
| Summary | 0000992: Сделать многопоточную загрузку тайлов в режиме просмотра карт | ||||
| Description | И тут речь именно о режиме просмотра, а не о загрузке выделенной области. В общем-то, давно такое желание возникло и уже с полгода как я начал неспеша это реализовывать (ветка Threaded в репах). И вроде бы, оно уже готово - берём exe из аттача и тестируем. Там специальная версия, с хардкодно заданным числом потоков на карту = 12, плюс игнорируется параметр Пауза для карты, так что на гугла сильно не наседайте, бо могут быстро забанить. В релизной версии число потоков будет браться из параметра MaxConnectToServerCount в zmp (если параметр отсутствует, как сейчас во многих картах, то берётся по дефолу = 1, т.е. пока мы этот счётчик не подкрутим, САС в кучу потоков качать не будет), ну и, соответственно, Пауза будет учитываться как положено. | ||||
| Tags | загрузка, закачка, потоки | ||||
|
|
Ну, типа, работает. Тайлы быстрее загружаются, за раз появляется несколько. Классно, ждём релиза. Предлагаю установить по умолчанию не 1, а несколько. Неохота править все zmp, лучше исправить только проблемные. |
|
|
>Предлагаю установить по умолчанию не 1, а несколько если не многопроцессорная тачка (кстати, ещё отдельный вопрос, как там это всё по процессорам раскидыватся) и не гигабитный интернет в соседнем доме с хранилищем тайлов, от сильно больших значений проку не будет. больше 4-х я б уж точно не ставил. >числом потоков на карту = 12 А пробовал с меньшим числом, но через IoCompletion (чтобы тупо потоки не расходовать зазря)? |
|
|
>больше 4-х я б уж точно не ставил Так, для информации: фришная версия GoogleEarth работает в 4 потока, PRO-шная - в 8 или 12, точно не помню. Так что, 12 по-моему само то. >кстати, ещё отдельный вопрос, как там это всё по процессорам раскидыватся У меня 2-х ядерник, оба ядра загружаются равномерно. >но через IoCompletion Не слышал про такую штуку. И что значит "не расходовать зазря"? |
|
|
Насчёт Iocompletion - найди книжку Рихтера "Программирование серверных приложений". Там объяснялась логика их использования. Общий смысл - экономия потоков и прочих ресурсов на относительно длительных однообразных операциях. При высоком уровне масштабируемости: кому надо - сделает себе 100500 потоков, кому надо - оставит 4. Я когда-то давно писал с их помощью функцию копирования файлов на Native NT API. По сравнению с "проводниковой" работало быстрее раза в 1.5-2. А если файл копировался из локалки - то ещё больше была разница. На 2000-й винде это было. И что такое "зазря" там тоже объяснятся. Навряд ли у меня лучше получится объяснить. Пусть тебя Native NT API не пугает: Рихтер им не пользуется, всё доступно и из Win32. Если говорить о числе потоков "на карту", да ещё увеличить это в пару-тройку раз для включённых "гибридов", которые тоже надо скачивать - как раз и получишь "требуемые" 12. Логика ограничения числа потоков при обсуждаемой скачке должна работать суммарно для всех скачиваемых карт, а не для каждой по отдельности. |
|
|
>Насчёт Iocompletion - найди книжку Ну да, через месяцок, в лучшем случае, я может и найду для себя ответ на вопрос и вполне возможно, что придумаю как оптимизировать текущую реализацию многопоточности. А пока не придумано/не предложено более оптимального варианта, думаю и текущая реализация заслуживает внимания. >должна работать суммарно для всех скачиваемых карт, а не для каждой по отдельности Сейчас логика работает в 2-х направлениях: 1. Ограничивается суммарное число потоков для гуя (32 шт.) 2. Ограничивается число потоков для каждой отдельной карты |
|
|
>как оптимизировать текущую реализацию многопоточности всё точно, это будет именно оптимизация. ибо IoCompletion (они же CompletionPort) - не более чем инструмент синхронизации, просто придуманный именно для ожидания завершения асинхронного ввода/вывода. фактически ждать приходится именно на окончании ввода-вывода, а не на дополнительных примитивах. потому и потоков можно меньше создавать, раз они общую очередь юзают, и работает в целом быстрее. Но повторюсь, это было кучу лет назад, сейчас может и не будет такого выигрыша в скорости/ресурсах. >думаю и текущая реализация заслуживает внимания конечно. я право не хотел тебя обидеть, извини если тебе показалось обратное. просто было интересно, может ты пробовал, но отказался по какой-либо причине от этого. а причин там может быть море. если найду свою старую писанину (а она хрен знает на какой CD-юк скинута кучу лет назад) - кину ей в тебя. там правда пример очень простой, просто копирование файла, который тривиально делится на куски, а тут у тебя задачи куда посложнее, чтобы очереди оптимально огранизовать в том числе, ведь скорость скачки будет разная для разных сервисов. |
|
|
> Merge with Threaded В завтрашней сборке уже будет многопоточная? Сколько будет по умолчанию? |
|
|
Да. Но для гуя по-умолчанию, пока что 1, так что разницы особо заметно не будет. Единственное, что теперь гуй и загрузки по выделениям, будут качаться независимыми потоками (если в zmp будет разрешено более 1-го потока). |
|
|
Увеличил максимальное число запросов для гуя до 32-х, теперь, по дефолту каждая карта в гуе качается своим потоком. Для того, чтобы ещё и конкретная карта начала качаться в несколько потоков, нужно в zmp прописать дополнительный параметр MaxConnectToServerCount с соответствующим числом: MaxConnectToServerCount=4 |
|
|
vasketsov, можно вопрос? Вот есть у меня поток, в котором выполняется как минимум 2 время-затратные операции: 1) Загрузка 2) Обработка скрипта (который в свою очередь тоже может ходить по интернетам). Чисто теоретически, можно ли этот поток превратить в некий класс и пустить его через эту очередь IoCompletion? Просто, если бы у нас был поток чисто из-за того, что мы выполняем синхронный запрос в инет, то ещё можно было бы выкрутиться асинхронным методом вининета (что само по себе тоже довольно геморройно, но не смертельно), но тут на нашем пути встаёт паскаль-скрипт, который тоже очень даже может подвесить весь процесс (твоя загрузка аттачментов, к примеру). И да: >если найду свою старую писанину Кидай, интересно глянуть, что за зверь. |
|
|
zed, Вы переделаете все карты в обоих репозиториях? |
|
|
Не, репы трогать не надо. Надо дорабатывать САС, чтобы эти дефолтные настройки можно было вынести с гуй, а не как сейчас хардкодить. |
|
|
В версии 4484 (и 4485) вообще не качаются карты Яндекс. Ошибка 400. Уж не знаю почему, надо срочно исправить. |
|
|
см. баг 0001026 |
|
|
vdemidov там сегодня всё капитально переделал и теперь загрузка карты/слоя(ёв) происходит независимыми потоками, но каждая карта/слой качается опять в 1 поток. Поэтому, хотелку переоткрываю. |
|
|
Ты не прав. В один поток ставятся в очередь на загрузку. Максимум в очередь от UI-качальщика ставится 4 запроса. А уже у каждой карты есть свой пул потоков обработки очереди закачки. И количество потоков задается в каждом змп или если не задано, то берется глобальное MaxConnectToServerCount |
|
|
Не знаю, где там подвох, соединений вроде и создаётся сколько положено, но загрузка идёт по очереди, а не одновременно (соединения видимо так же создаются по-очереди и так же по-очереди юзаются). |
|
|
Нашел. В u_ZmpInfo.pas почемуто не скопировался один из кусков твоего патча. И получалось, что по дефолту один обработчик закачек у каждой карты. |
|
|
О, теперь всё работает :) |
|
|
Хм, только число соединений с сервером оказывается больше чем MaxConnectToServerCount (хотя число потоков это число не превышает). |
|
|
>И получалось, что по дефолту один обработчик закачек у каждой карты. И при однопоточной загрузке с сервером было установлено 4 коннекта... что-то где-то ещё бажит? |
|
|
А, понял в чём дело: если у карты несколько хостов (khm1.google, khm2.google и т.д.), и при этом они возвращают Keep-Alive, то либо сам wininet, либо используемый компонент, не разрывают коннект при обращении к новому хосту, а держит его где-то там у себя внутрях, до вызова явного дисконнекта. И получается, что если мы поставим 1 поток, у нас будет 4 коннекта (по числу хостов). Это, в общем-то сильно не мешает, но вот такая фича появилась. Чтоб от этого избавиться (если вдруг чё), нужно: а) запоминать адрес последнего хоста к которому обращался данный поток и б) перед запросом тайла вызывать дисконнект, если текущий хост и последний не совпадают, ну и в) предварительно можно из пула потоков выбирать тот, который до этого тянул тайл с текущего хоста. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 10-10-2011 17:16 | zed | New Issue | |
| 10-10-2011 17:16 | zed | File Added: SASPlanet.MultiThreaded.zip | |
| 10-10-2011 17:17 | zed | File Added: Image 1.png | |
| 10-10-2011 17:33 | Tolik | Note Added: 0004069 | |
| 10-10-2011 18:59 | vasketsov | Note Added: 0004070 | |
| 10-10-2011 19:11 | zed | Note Added: 0004071 | |
| 10-10-2011 19:25 | zed | Note Edited: 0004071 | |
| 10-10-2011 20:08 | vasketsov | Note Added: 0004072 | |
| 10-10-2011 20:11 | vasketsov | Note Edited: 0004072 | |
| 10-10-2011 20:14 | vasketsov | Note Edited: 0004072 | |
| 11-10-2011 04:38 | zed | Note Added: 0004073 | |
| 11-10-2011 07:33 | vasketsov | Note Added: 0004075 | |
| 14-10-2011 06:53 | gpsMax | Tag Attached: загрузка | |
| 14-10-2011 06:53 | gpsMax | Tag Attached: закачка | |
| 14-10-2011 13:15 | Tolik | Assigned To | => zed |
| 14-10-2011 13:15 | Tolik | Status | new => assigned |
| 14-10-2011 14:20 | zed | File Deleted: Image 1.png | |
| 20-10-2011 16:57 | Tolik | Note Added: 0004125 | |
| 20-10-2011 17:52 | zed | Note Added: 0004126 | |
| 28-10-2011 21:55 | zed | Note Added: 0004217 | |
| 28-10-2011 22:05 | zed | Note Added: 0004218 | |
| 28-10-2011 22:07 | zed | Note Edited: 0004218 | |
| 29-10-2011 06:29 | Tolik | Note Added: 0004221 | |
| 29-10-2011 06:57 | zed | Note Added: 0004223 | |
| 30-10-2011 07:14 | Tolik | Note Added: 0004228 | |
| 30-10-2011 13:28 | zed | Note Added: 0004231 | |
| 30-10-2011 13:29 | zed | Note Edited: 0004231 | |
| 03-11-2011 19:09 | gpsMax | Tag Attached: потоки | |
| 16-11-2011 12:17 | zed | Relationship added | related to 0001046 |
| 25-11-2011 14:04 | zed | File Deleted: SASPlanet.MultiThreaded.zip | |
| 25-11-2011 14:05 | zed | Status | assigned => resolved |
| 25-11-2011 14:05 | zed | Fixed in Version | => 41xxxx |
| 25-11-2011 14:05 | zed | Resolution | open => fixed |
| 28-11-2011 16:47 | zed | Assigned To | zed => |
| 28-11-2011 16:47 | zed | Status | resolved => acknowledged |
| 28-11-2011 16:52 | zed | Note Added: 0004445 | |
| 28-11-2011 18:10 | vdemidov | Note Added: 0004446 | |
| 28-11-2011 18:53 | zed | Note Added: 0004447 | |
| 28-11-2011 18:57 | zed | Note Edited: 0004447 | |
| 28-11-2011 19:50 | vdemidov | Note Added: 0004448 | |
| 28-11-2011 19:51 | vdemidov | Status | acknowledged => resolved |
| 28-11-2011 19:51 | vdemidov | Fixed in Version | 41xxxx => 120808 |
| 28-11-2011 19:51 | vdemidov | Assigned To | => vdemidov |
| 28-11-2011 19:54 | zed | Note Added: 0004449 | |
| 28-11-2011 20:08 | zed | Note Added: 0004450 | |
| 28-11-2011 20:10 | zed | Note Added: 0004451 | |
| 21-12-2011 17:45 | zed | Note Added: 0004559 | |
| 22-12-2011 05:42 | Tolik | Fixed in Version | 120808 => 41xxxx |
| 22-12-2011 05:42 | Tolik | Target Version | => 41xxxx |
| 23-01-2012 08:25 | vdemidov | Fixed in Version | 41xxxx => 120808 |
| 23-01-2012 08:25 | vdemidov | Target Version | 41xxxx => 120808 |
| 23-01-2012 10:51 | vdemidov | Product Version | => 110418 |
| 04-02-2012 16:51 | zed | Relationship added | related to 0000664 |
| 10-10-2012 11:49 | Tolik | Status | resolved => closed |
| 08-08-2025 13:24 | zed | Category | Хотелка => Хотелка / Feature request |