D
Size: a a a
2020 April 06
k
там типа 8х8м
Покупай vr
m
чуток потюнил
k
Только загрузки починил?
m
ну чуть ускорил
там над будет еще переделать немног
там над будет еще переделать немног
m
m
Переслано от mr.slavik
https://github.com/telegramdesktop/tdesktop/pull/6442#issuecomment-529764829
It is not that simple :( On fast networks such constant changes will improve the speed, but on slow networks it will cause over loaded connections which will lead to constant reconnecting by timeouts and decrease in speed / sometimes not loading at all.
Well, so it can be to regulate the number of concurrent loading threads depending on the file size and network speed?
I experimented with my python microservice - I managed to achieve a stable download speed of ~ 240Mbit / s for one worker (process). Depending on the size of the downloaded file, from 4 to 24 threads are allocated for downloading the file — for small files, the cost of creating a large number of threads, switching contexts and locks eliminates the gain from multithreading. The worker always has at least 2 threads ready - so as not to waste resources on creating and deleting threads when loading several small files.
Depending on the file size, additional threads are allocated and live until the end of the file download process. Threads start with a randomized delay between 200ms and 2000ms. List of chunks to load is composed at start time for each thread. Lists are independently processed by each thread with minimal mutual blocking.
A desktop client has a problem when scrolling through gifs, for example - they are placed in the queue and processed according to the FIFO strategy, when it would be more appropriate to use LIFO - first uploading files that are in the user's field of view.
It is not that simple :( On fast networks such constant changes will improve the speed, but on slow networks it will cause over loaded connections which will lead to constant reconnecting by timeouts and decrease in speed / sometimes not loading at all.
Well, so it can be to regulate the number of concurrent loading threads depending on the file size and network speed?
I experimented with my python microservice - I managed to achieve a stable download speed of ~ 240Mbit / s for one worker (process). Depending on the size of the downloaded file, from 4 to 24 threads are allocated for downloading the file — for small files, the cost of creating a large number of threads, switching contexts and locks eliminates the gain from multithreading. The worker always has at least 2 threads ready - so as not to waste resources on creating and deleting threads when loading several small files.
Depending on the file size, additional threads are allocated and live until the end of the file download process. Threads start with a randomized delay between 200ms and 2000ms. List of chunks to load is composed at start time for each thread. Lists are independently processed by each thread with minimal mutual blocking.
A desktop client has a problem when scrolling through gifs, for example - they are placed in the queue and processed according to the FIFO strategy, when it would be more appropriate to use LIFO - first uploading files that are in the user's field of view.
m
m
m
m
Переслано от mr.slavik
типа предыдущий клиент сперва с измененными константами(tdmt) и телега 2.0
m
m
m
m
Переслано от mr.slavik
у меня в боте от размера файла зависит
сколько потоков его будут грузить
типа чтобы в среднем за одно и то-же время загружал и большие и маленькие файлы
типа по таймауту рожать 8секундному - сомнительное решение
сколько потоков его будут грузить
типа чтобы в среднем за одно и то-же время загружал и большие и маленькие файлы
типа по таймауту рожать 8секундному - сомнительное решение
m
m
Переслано от mr.slavik
почему этот чудесный пример нейминга еще не в канале у него
m
Переслано от mr.slavik
ну и на самом деле мелкими блоками дольше отправляется