0000992: Сделать многопоточную загрузку тайлов в режиме просмотра карт

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

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

(0004071) zed (manager) 10-10-2011 19:11 edited on: 10-10-2011 19:25	>больше 4-х я б уж точно не ставил Так, для информации: фришная версия GoogleEarth работает в 4 потока, PRO-шная - в 8 или 12, точно не помню. Так что, 12 по-моему само то. >кстати, ещё отдельный вопрос, как там это всё по процессорам раскидыватся У меня 2-х ядерник, оба ядра загружаются равномерно. >но через IoCompletion Не слышал про такую штуку. И что значит "не расходовать зазря"?

(0004072) vasketsov (manager) 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 (manager) 11-10-2011 04:38	>Насчёт Iocompletion - найди книжку Ну да, через месяцок, в лучшем случае, я может и найду для себя ответ на вопрос и вполне возможно, что придумаю как оптимизировать текущую реализацию многопоточности. А пока не придумано/не предложено более оптимального варианта, думаю и текущая реализация заслуживает внимания. >должна работать суммарно для всех скачиваемых карт, а не для каждой по отдельности Сейчас логика работает в 2-х направлениях: 1. Ограничивается суммарное число потоков для гуя (32 шт.) 2. Ограничивается число потоков для каждой отдельной карты

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

(0004125) Tolik (manager) 20-10-2011 16:57	> Merge with Threaded В завтрашней сборке уже будет многопоточная? Сколько будет по умолчанию?

(0004126) zed (manager) 20-10-2011 17:52	Да. Но для гуя по-умолчанию, пока что 1, так что разницы особо заметно не будет. Единственное, что теперь гуй и загрузки по выделениям, будут качаться независимыми потоками (если в zmp будет разрешено более 1-го потока).

(0004217) zed (manager) 28-10-2011 21:55	Увеличил максимальное число запросов для гуя до 32-х, теперь, по дефолту каждая карта в гуе качается своим потоком. Для того, чтобы ещё и конкретная карта начала качаться в несколько потоков, нужно в zmp прописать дополнительный параметр MaxConnectToServerCount с соответствующим числом: MaxConnectToServerCount=4

(0004218) zed (manager) 28-10-2011 22:05 edited on: 28-10-2011 22:07	vasketsov, можно вопрос? Вот есть у меня поток, в котором выполняется как минимум 2 время-затратные операции: 1) Загрузка 2) Обработка скрипта (который в свою очередь тоже может ходить по интернетам). Чисто теоретически, можно ли этот поток превратить в некий класс и пустить его через эту очередь IoCompletion? Просто, если бы у нас был поток чисто из-за того, что мы выполняем синхронный запрос в инет, то ещё можно было бы выкрутиться асинхронным методом вининета (что само по себе тоже довольно геморройно, но не смертельно), но тут на нашем пути встаёт паскаль-скрипт, который тоже очень даже может подвесить весь процесс (твоя загрузка аттачментов, к примеру). И да: >если найду свою старую писанину Кидай, интересно глянуть, что за зверь.

(0004221) Tolik (manager) 29-10-2011 06:29	zed, Вы переделаете все карты в обоих репозиториях?

(0004223) zed (manager) 29-10-2011 06:57	Не, репы трогать не надо. Надо дорабатывать САС, чтобы эти дефолтные настройки можно было вынести с гуй, а не как сейчас хардкодить.

(0004228) Tolik (manager) 30-10-2011 07:14	В версии 4484 (и 4485) вообще не качаются карты Яндекс. Ошибка 400. Уж не знаю почему, надо срочно исправить.

(0004231) zed (manager) 30-10-2011 13:28 edited on: 30-10-2011 13:29	см. баг 0001026

(0004445) zed (manager) 28-11-2011 16:52	vdemidov там сегодня всё капитально переделал и теперь загрузка карты/слоя(ёв) происходит независимыми потоками, но каждая карта/слой качается опять в 1 поток. Поэтому, хотелку переоткрываю.

(0004446) vdemidov (manager) 28-11-2011 18:10	Ты не прав. В один поток ставятся в очередь на загрузку. Максимум в очередь от UI-качальщика ставится 4 запроса. А уже у каждой карты есть свой пул потоков обработки очереди закачки. И количество потоков задается в каждом змп или если не задано, то берется глобальное MaxConnectToServerCount

(0004447) zed (manager) 28-11-2011 18:53 edited on: 28-11-2011 18:57	Не знаю, где там подвох, соединений вроде и создаётся сколько положено, но загрузка идёт по очереди, а не одновременно (соединения видимо так же создаются по-очереди и так же по-очереди юзаются).

(0004448) vdemidov (manager) 28-11-2011 19:50	Нашел. В u_ZmpInfo.pas почемуто не скопировался один из кусков твоего патча. И получалось, что по дефолту один обработчик закачек у каждой карты.

(0004449) zed (manager) 28-11-2011 19:54	О, теперь всё работает :)

(0004450) zed (manager) 28-11-2011 20:08	Хм, только число соединений с сервером оказывается больше чем MaxConnectToServerCount (хотя число потоков это число не превышает).

(0004451) zed (manager) 28-11-2011 20:10	>И получалось, что по дефолту один обработчик закачек у каждой карты. И при однопоточной загрузке с сервером было установлено 4 коннекта... что-то где-то ещё бажит?

(0004559) zed (manager) 21-12-2011 17:45	А, понял в чём дело: если у карты несколько хостов (khm1.google, khm2.google и т.д.), и при этом они возвращают Keep-Alive, то либо сам wininet, либо используемый компонент, не разрывают коннект при обращении к новому хосту, а держит его где-то там у себя внутрях, до вызова явного дисконнекта. И получается, что если мы поставим 1 поток, у нас будет 4 коннекта (по числу хостов). Это, в общем-то сильно не мешает, но вот такая фича появилась. Чтоб от этого избавиться (если вдруг чё), нужно: а) запоминать адрес последнего хоста к которому обращался данный поток и б) перед запросом тайла вызывать дисконнект, если текущий хост и последний не совпадают, ну и в) предварительно можно из пула потоков выбирать тот, который до этого тянул тайл с текущего хоста.

Users who viewed this issue
User List	Anonymous (3611x), VMatveev (1x), zed (1x)
Total Views	3613
Last View	22-11-2024 02:27

Issue History
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:21	zed	Note Added: 0004068
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	View Revisions
10-10-2011 20:08	vasketsov	Note Added: 0004072
10-10-2011 20:11	vasketsov	Note Edited: 0004072	View Revisions
10-10-2011 20:14	vasketsov	Note Edited: 0004072	View Revisions
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
14-10-2011 14:20	zed	Note Deleted: 0004068
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	View Revisions
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	View Revisions
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	=> 24xxxx
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	View Revisions
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	24xxxx => 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 => 24xxxx
22-12-2011 05:42	Tolik	Target Version	=> 24xxxx
23-01-2012 08:25	vdemidov	Fixed in Version	24xxxx => 120808
23-01-2012 08:25	vdemidov	Target Version	24xxxx => 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

SASGIS