Сравнительный обзор download-менеджеров. Почему приложение грузит CPU

22/02/2018

Ещё один менеджер закачек, по своим функциям не уступающий более известным аналогам. Так, например, программа с успехом работает с протоколами http и ftp, успешно поддерживает докачку файлов, а также имеет встроенный планировщик, в котором можно задать не только время закачки, но и их количество, а также задать автоматическое выключение компьютера. Кроме этого, программа обладает приятным внешним видом, который, кстати, можно изменить с помощью скинов, а также понятным интерфейсом. Имеется здесь и плавающее окошко, в котором отображается информация о текущих загрузках, и возможность автоматического переименования файло...

03/07/2017

EagleGet - простой менеджер закачек, позволяющий скачивать любые файлы из интернета на высокой скорости, а также обладающий понятным интерфейсом, с которым может разобраться практически любой пользователь. Отличительной особенностью данной программы является то, что она автоматически настраивает параметры загрузки, исходя из возможностей и особенностей вашего Интернет-соединения. Кроме того позволяет вам не беспокоиться о том, что закачка будет прервана из-за неполадок. Программа сможет продолжить загрузку файла с того места, где она была прервана. Если, конечно, данная возможность поддерживается сайтом, с которого вы загружает...

27/06/2017

Download Master - один из популярнейших менеджеров закачек. Он отличается от других таких программ высокой продуктивностью и доступным для пользователя интерфейсом. Как считается, существует три проблемы при скачивании файлов из сети: скорость скачивания, продолжение прерванных закачек и управление уже скачанными файлами. Download Master решает их все. С помощью HTTP, HTTPS и FTP протоколов эта программа значительно повышает скорость скачивания из Интернета. Это достигается при помощи технологии разбивания файла на потоки информации, которые скачиваются в одно время. Если интернет соединение во время скачивания прерва...

12/05/2017

29/11/2016

Free Download Manager – бесплатный менеджер закачек, обладающий широкими возможностями. Данная программа может скачивать файлы на максимальной скорости, поскольку увеличивает её за счёт использования нескольких потоков загрузки, однако это далеко не все её функции. Прежде всего, следует отметить тот факт, что Free Download Manager является ещё и Torrent клиентов. Т.е. по сути это две программы в одной. Кроме того, данная программа обладает функцией скачивания сайтов целиком. Это бывает полезно, когда у вас не очень хороший интернет, да и оплата производится за время соединения, то иногда выгоднее скачать весь сайт сра...

27/11/2015

JDownloader - полезное приложение, предназначенное для быстрого скачивания медиа файлов, документов либо программ. Позволяет закачивать файлы в разы быстрее, чем с помощью загрузчик браузера. Все закачки можно ставить в свою очередь. Настройки программы позволяют запускать скачивание сразу после добавления ссылки. Работает на базе распространённой платформы Java. Отлично взаимодействует с популярными файлообменными хранилищами. Приложение вынимает ссылку на файл из сети и справляется с ограничителями скорости. Позволяет беспрепятственно скачивать информацию с файлообменников. Интерфейс менеджера закачек включает три закладки.

07/07/2015

Ninja Download Manager - весьма удобный менеджер закачек, с которым можно без особых трудностей загружать большие файлы. Программа позволяет останавливать или возобновлять загрузку файла, а также увеличивает скорость до максимально возможной. Приложение может автоматически перехватывать все ссылки, находящиеся в буфере обмена операционной среды. Ninja Download Manager позволяет перетаскивать файлы посредством drag&drop. Можно упорядочиваться загрузки по желанию пользователя. Возможность составления расписания помогает начинать либо останавливать загрузки без участия пользователя. Помимо этих функций Ninja Download Manager спосо...

16/03/2015

SD Download Manager – приложение для загрузки, скачивания различных файлов, документов из интернет-источников. Работает быстрее браузерного загрузчика, благодаря использованию до 32 активных подключений. Новый динамический алгоритм сжатия и скачивания данных делает загрузку документов и различных файлов быстрее в разы. Утилита помогает возобновить, прерванные по причинам, операции скачивания, а также взаимодействует с битыми ссылками. Поддерживает протоколы интернет-соединений HTTP, HTTPS, FTP-протоколы, брандмауэры, файл перенаправления авторизации. Использует захват загрузок с веб-браузера Mozilla Firefox, также проводит мон...

10/03/2015

DAM - создана для скачивания файлов с интернета. Может не только скачать отдельные файлы, а также скачивает музыку и видео с таких сайтов как например YouTube. Главная особенность программы в том что она многократно увеличивает скорость загрузки, по сравнению с базовым загрузчиком который присутствует в других браузерах. Поддерживается всеми популярными веб-браузерами, Firefox, IE, Chrome и т.д. Программа может планировать, восстанавливать и запускать остановленные загрузки. В отличие от других загрузчиков, не тратит время зря на бесполезные действия и сразу сохраняет файлы полностью, а не по частям. Не имеет какого либо шпионс...

18/11/2014

Большинство людей каждый день пользуются Интернетом. И очень часто приходится скачивать книги, фильмы, музыку, программы и так далее. Пользоваться обычными программами для загрузки, а тем более стандартными средствами - долго и неудобно. И именно для того, чтобы максимально повысить уровень работы в Интернете, были разработаны так называемые Менеджеры загрузок, то есть программы, предоставляющие необходимые средства. Одна из них (и наиболее популярная) - Download Accelerator Plus. Так в чем же заключается принцип работы программы? Скачиваемый файл буквально "разрезается" на части, и все они загружаются одновременно.

10/11/2014

DDownloads – это приложение, которое содержит в себе специальный каталог, выполняющий функции оперативного поиска, а также установки различных необходимых программ. Данный каталог представлен в виде определенного списка ссылок на разные бесплатные программы. Оснащен встроенным модулем, выполняющим автоматические функции по обновлению, что позволяет регулярно расширять и актуализировать ссылки. Каталог разделен на несколько категорий для удобного поиска. Для каждой из программ в DDownloads содержится описание и характеристики, информация по их рейтингу и о производителях. Размещенные ссылки позволяют скачать разные версии програ...

29/09/2013

Orbit Downloader – ещё один менеджер закачек с удобным интерфейсом и некоторыми уникальными возможностями. Программа способна скачивать файлы по всем стандартным протоколам, включая http, https, ftp, а также обладает функцией остановки и старта любой из закачек, если, конечно, данный способ поддерживается сервером. Программа имеет встроенный планировщик, позволяющий выполнять все закачки в указанное вами время, например, вы можете запланировать старт всех закачек на 2 часа ночи. Помимо этого в стандартные функции программы входит возможность многопоточной закачки, а также интеграция во все популярные браузеры.

17/06/2013

Мощная качалка файлов, заметно ускоряющая время загрузки файлов благодаря разбиению файла на несколько потоков. Программа умеет отсортировать файлы по типу, перехватить ссылки из буфера обмена, интернироваться в браузеры Google Chrome и Mozilla Firefox и т.д. Кроме этого в программе присутствует детектор ресурсов (встроенный компактный браузер), с помощью которого можно легко "перехватить" все имеющиеся файлы на указанной вами страницы. Естественно, предусмотрены импорт и экспорт списков заданий, а также поддержка прокси и даже создание и скачивание торрент файлов. Таким образом можно сказать, что FlashGet это универсальный мен...

Это четвертая статья из серии "Преодолевая границы Windows", в рамках которой я рассказываю об ограничениях, существующих для фундаментальных ресурсов в Windows. На сей раз, я собираюсь обсудить с вами ограничение на максимальное количество потоков и процессов, поддерживаемое Windows. Здесь я кратко опишу различие между потоком и процессом, ограничение потока опроса (от англ. survey thread), после чего мы поговорим об ограничениях, связанных с процессами. В первую очередь я решил рассказать об ограничениях потоков, так как каждый активный процесс имеет, по крайней мере, один поток (процесс, который завершился, но ссылка на который хранится в обработчике, предоставленном другим процессом, не имеет ни одного потока), так что ограничения процессов напрямую зависят от основных ограничений, связанных с потоками.

В отличие от некоторых вариантов UNIX, большинство ресурсов Windows не имеют фиксированного ограничения, заложенного в операционную систему на этапе сборки, а скорее получают ограничения на основании имеющихся в распоряжении ОС базовых ресурсов, о которых я рассказывал ранее. Процессы и потоки, например, требуют для себя физической памяти, виртуальной памяти и памяти пула, так что число процессов и потоков, которые могут быть созданы на данной системе Windows, в конечном счете, определяется одним из этих ресурсов, в зависимости от того, каким образом эти процессы или потоки были созданы и какое из ограничений базовых ресурсов будет достигнуто первым. Поэтому я рекомендую вам, чтобы вы прочитали мои предыдущие статьи, если вы до сих пор этого не сделали, потому что далее я буду обращаться к таким понятиям, как зарезервированная память, выделенная память и системное ограничение памяти, о которых я говорил в предыдущих своих статьях:

Процессы и потоки
Процесс Windows по своей сути является контейнером, в котором хранится код команд из исполняемого файла. Он представляет собой объект процесса ядра и Windows использует этот объект процесса и связанные с ним структуры данных для хранения и сопровождения информации об исполняемом коде приложения. Например, процесс имеет виртуальное адресное пространство, в котором хранятся его частные и общие данные и в которое отображаются исполняемый образ и связанные с ним библиотеки DLL. Windows с помощью инструментов диагностики записывает информацию об использовании процессом ресурсов для обеспечения учета и выполнения запросов и регистрирует ссылки процесса на объекты операционной системы в таблице дескриптора процесса. Процессы работают с контекстом безопасности, именуемом маркером, который идентифицирует учетную запись пользователя, группы учетной записи и привилегии, назначенные процессу.

Процесс включает в себя один или более потоков, которые фактически выполняют код в процессе (технически, выполняются не процессы, а потоки) и представлены в системе в виде объектов потоков ядра. Есть несколько причин, почему приложения создают потоки в дополнение к их исходному начальному потоку: 1) процессы, обладающие пользовательским интерфейсом, обычно создают потоки для того, чтобы выполнять свою работу и при этом сохранять отзывчивость основного потока к командам пользователя, связанными с вводом данных и управлением окнами; 2) приложения, которые хотят использовать несколько процессоров для масштабирования производительности или же которые хотят продолжать работать, в то время как потоки останавливают свою работу, ожидая синхронизации операций ввода/вывода, создают потоки, чтобы получить дополнительную выгоду от многопоточной работы.

Ограничения потоков
Помимо основной информации о потоке, включая данные о состоянии регистров ЦП, присвоенный потоку приоритет и информацию об использовании потоком ресурсов, у каждого потока есть выделенная ему часть адресного пространства процесса, называемая стеком, которую поток может использовать как рабочую память по ходу исполнения кода программы, для передачи параметров функций, хранения локальных переменных и адресов результатов работы функций. Таким образом, чтобы избежать нерациональной траты виртуальной памяти системы, первоначально распределяется только часть стека, или же часть ее передается потоку, а остаток просто резервируется. Поскольку стеки в памяти растут по нисходящей, система размещает так называемые "сторожевые" страницы (от англ. guard pages) памяти вне выделенной части стека, которые обеспечивают автоматическое выделение дополнительной памяти (называемой расширением стека), когда она потребуется. На следующей иллюстрации показано, как выделенная область стека углубляется и как сторожевые страницы перемещаются по мере расширения стека в 32-битном адресном пространстве:

Структуры Portable Executable (PE) исполняемых образов определяют объем адресного пространства, которое резервируется и изначально выделяется для стека потока. По умолчанию компоновщик резервирует 1Мб и выделяет одну страницу (4Кб), но разработчики могут изменять эти значения либо меняя значения PE, когда они организуют связь со своей программой, либо путем вызова для отдельного потока функции CreateTread . Вы можете использовать утилиту, такую как Dumpbin , которая идет в комплекте с Visual Studio, чтобы посмотреть настройки исполняемой программы. Вот результаты запуска Dumpbin с опцией /headers для исполняемой программы, сгенерированной новым проектом Visual Studio:

Переведя числа из шестнадцатеричной системы исчисления, вы можете увидеть, что размер резерва стека составляет 1Мб, а выделенная область памяти равна 4Кб; используя новую утилиту от Sysinternals под названием MMap , вы можете подключиться к этому процессу и посмотреть его адресное пространство, и тем самым увидеть изначально выделенную страницу памяти стека процесса, сторожевую страницу и остальную часть зарезервированной памяти стека:

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

Ограничения 32-битных потоков
Даже если бы у процесса вообще не было ни кода, ни данных и все адресное пространство могло бы быть использовано под стеки, то 32-битный процесс с установленным по умолчанию адресным пространством в 2 б мог бы создать максимум 2048 потоков. Вот результаты работы программы Testlimit , запущенной в 32-битной Windows с параметром -t (создание потоков), подтверждающие наличие этого ограничения:

Еще раз, так как часть адресного пространства уже использовалась под код и начальную динамическую память, не все 2Гб были доступны для стеков потоков, так что общее количество созданных потоков не смогло достигнуть теоретического предела в 2048 потоков.

Я попробовал запустить Testlimit с дополнительной опцией, предоставляющей приложению расширенное адресное пространство, надеясь, что если уж ему дадут больше 2Гб адресного пространства (например, в 32-битных системах это достигается путем запуска приложения с опцией /3GB или /USERVA для Boot.ini, или же эквивалентной опцией BCD на Vista и позднее increaseuserva), оно будет его использовать. 32-битным процессам выделяется 4Гб адресного пространства, когда они запускаются на 64-битной Windows, так сколько же потоков сможет создать 32-битный Testlimit, запущенный на 64-битной Windows? Если основываться на том, что мы уже обсудили, ответ должен быть 4096 (4Гб разделенные на 1Мб), однако на практике это число значительно меньше. Вот 32-битный Testlimit, запущенный на 64-битной Windows XP:

Причина этого несоответствия кроется в том факте, что когда вы запускаете 32-битное приложение на 64-битной Windows, оно фактические является 64-битным процессом, которое выполняет 64-битный код от имени 32-битных потоков, и потому в памяти для каждого потока резервируются области под 64-битные и 32-битные стеки потоков. Для 64-битного стека резервируется 256Кб (исключения составляют ОС, вышедшие до Vista, в которых исходный размер стека 64-битных потоков составляет 1Мб). Поскольку каждый 32-битный поток начинает свое существование в 64-битном режиме и размер стека, который ему выделяется при старте, превышает размер страницы, в большинстве случаев вы увидите, что под 64-битный стек потока выделяется как минимум 16Кб. Вот пример 64-битных и 32-битных стеков 32-битного потока (32-битный стек помечен как "Wow64"):

32-битный Testlimit смог создать в 64-битной Windows 3204 потока, что объясняется тем, что каждый поток использует 1Мб + 256Кб адресного пространство под стек (повторюсь, исключением являются версии Windows до Vista, где используется 1Мб+ 1Мб). Однако, я получил другой результат, запустив 32-битный Testlimit на 64-битной Windows 7:

Различия между результатами на Windows XP и Windows 7 вызвано более беспорядочной природой схемы распределения адресного пространства в Windows Vista, Address Space Layout Randomization (ASLR), которая приводит к некоторой фрагментации. Рандомизация загрузки DLL, стека потока и размещения динамической памяти, помогает улучшить защиту от вредоносного ПО. Как вы можете увидеть на следующем снимке программы VMMap, в тестовой системе есть еще 357Мб доступного адресного пространства, но наибольший свободный блок имеет размер 128Кб, что меньше чем 1Мб, необходимый для 32-битного стека:

Как я уже отмечал, разработчик может переустановить заданный по умолчанию размер резерва стека. Одной из возможных причин для этого может быть стремление избежать напрасного расхода адресного пространства, когда заранее известно, что стеком потока всегда будет использоваться меньше, чем установленный по умолчанию 1Мб. PE-образ Testlimit по умолчанию использует размер резерва стека в 64Кб, и когда вы указываете вместе параметром -t параметр -n, Testlimit создает потоки со стеками размером в 64Кб. Вот результат работы этой утилиты на системе с 32-битной Windows XP и 256Мб RAM (я специально провел этот тест на слабой системе, что подчеркнуть данное ограничение):

Здесь следует отметить, что произошла другая ошибка, из чего следует, что в данной ситуации причиной является не адресное пространство. Фактически, 64Кб-стеки должны обеспечить приблизительно 32 000 потоков (2Гб/64Кб = 32768). Так какое же ограничение проявилось в данном случае? Если посмотреть на возможных кандидатов, включая выделенную память и пул, то никаких подсказок в нахождении ответа на этот вопрос они не дают, поскольку все эти значения ниже их пределов:

Ответ мы можем найти в дополнительной информации о памяти в отладчике ядра, который укажет нам искомое ограничение, связанное с доступной резидентной памятью, весь объем которой был исчерпан:

Доступная резидентная память - это физическая память, выделяемая для данных или кода, которые обязательно должны находиться в оперативной памяти. Размеры невыгружаемого пула и невыгружаемых драйверов высчитываются независимо от этого, также как, например, память, зарезервированная в RAM для операций ввода/вывода. У каждого потока есть оба стека пользовательского режима, об этом я уже говорил, но у них также есть стек привилегированного режима (режима ядра), который используется тогда, когда потоки работают в режиме ядра, например, исполняя системные вызовы. Когда поток активен, его стек ядра закреплен в памяти, так что поток может выполнять код в ядре, для которого нужные страницы не могут отсутствовать.

Базовый стек ядра занимает 12Кб в 32-битной Windows и 24Кб в 64-битной Windows. 14225 потоков требуют для себя приблизительно 170Мб резидентной памяти, что точно соответствует объему свободной памяти на этой системе с выключенным Testlimit:

Как только достигается предел доступной системной памяти, многие базовые операции начинают завершаться с ошибкой. Например, вот ошибка, которую я получил, дважды кликнув на ярлыке Internet Explorer, расположенном на рабочем столе:

Как и ожидалось, работая на 64-битной Windows с 256Мб RAM, Testlimit смог создать 6600 потоков - примерно половину от того, сколько потоков эта утилита смогла создать в 32-битной Windows с 256Мб RAM - до того, как исчерпалась доступная память:

Причиной, по которой ранее я употреблял термин "базовый" стек ядра, является то, что поток, который работает с графикой и функциями управления окнами, получает "большой" стек, когда он исполняет первый вызов, размер которого равен (или больше) 20Кб на 32-битной Windows и 48Кб на 64-битной Windows. Потоки Testlimit не вызывают ни одного подобного API, так что они имеют базовые стеки ядра.
Ограничения 64-битных потоков

Как и у 32-битных потоков, у 64-битных потоков по умолчанию есть резерв в 1Мб для стека, но 64-битные имеют намного больше пользовательского адресного пространства (8Тб), так что оно не должно стать проблемой, когда дело доходит до создания большого количества потоков. И все же очевидно, что резидентная доступная память по-прежнему является потенциальным ограничителем. 64-битная версия Testlimit (Testlimit64.exe) смогла создать с параметром -n и без него приблизительно 6600 потоков на системе с 64-битной Windows XP и 256Мб RAM, ровно столько же, сколько создала 32-битная версия, потому что был достигнут предел резидентной доступной памяти. Однако, на системе с 2Гб оперативной памяти Testlimit64 смог создать только 55000 потоков, что значительно меньше того количества потоков, которое могла бы создать эта утилита, если бы ограничением выступила резидентная доступная память (2Гб/24Кб = 89000):

В данном случае причиной является выделенный начальный стек потока, который приводит к тому, что в системе заканчивается виртуальная память и появляется ошибка, связанная с нехваткой объема файла подкачки. Как только объем выделенной памяти достигает размера оперативной памяти, скорость создания новых потоков существенно снижается, потому что система начинает "пробуксовывать", ранее созданные стеки потоков начинают выгружаться в файл подкачки, чтобы освободить место для стеков новых потоков, и файл подкачки должен увеличиваться. С включенным параметром -n результаты те же, поскольку таким же остается начальный объем выделенной памяти стека.

Ограничения процессов
Число процессов, поддерживаемых Windows, очевидно, должно быть меньше, чем число потоков, потому как каждый процесс имеет один поток и сам по себе процесс приводит к дополнительному расходу ресурсов. 32-битный Testlimit, запущенный на системе с 64-битной Windows XP и 2Гб системной памяти создает около 8400 процессов:

Если посмотреть на результат работы отладчика ядра, то становится понятно, что в данном случае достигается ограничение резидентной доступной памяти:

Если бы процесс использовал резидентную доступную память для размещения только лишь стека потока привилегированного режима, Testlimit смог бы создать намного больше, чем 8400 потоков на системе с 2Гб. Количество резидентной доступной памяти на этой системе без запущенного Testlimit равно 1,9Гб:

Путем деления объема резидентной памяти, используемой Testlimit (1,9Гб), на число созданных им процессов получаем, что на каждый процесс отводится 230Кб резидентной памяти. Так как 64-битный стек ядра занимает 24 Кб, мы получаем, что без вести пропали примерно 206Кб для каждого процесса. Где же остальная часть используемой резидентной памяти? Когда процесс создан, Windows резервирует достаточный объем физической памяти, чтобы обеспечить минимальный рабочий набор страниц (от англ. working set). Это делается для того, чтобы гарантировать процессу, что любой ситуации в его распоряжении будет достаточное количество физической памяти для сохранения такого объема данных, который необходим для обеспечения минимального рабочего набора страниц. По умолчанию размер рабочего набора страниц зачастую составляет 200Кб, что можно легко проверить, добавив в окне Process Explorer столбец Minimum Working Set:

Оставшиеся 6Кб - это резидентная доступная память, выделяемая под дополнительную нестраничную память (от англ. nonpageable memory), в которой хранится сам процесс. Процесс в 32-битной Windows использует чуть меньше резидентной памяти, поскольку его привилегированный стек потока меньше.

Как и в случае со стеками потока пользовательского режима, процессы могут переопределять установленный для них по умолчанию размер рабочего набора страниц с помощью функции SetProcessWorkingSetSize . Testlimit поддерживает параметр -n, который, в совокупности с параметром -p, позволяет устанавливать для дочерних процессов главного процесса Testlimit минимально возможный размер рабочего набора страниц, равный 80Кб. Поскольку дочерним процессам нужно время, чтобы сократить их рабочие наборы страниц, Testlimit, после того, как он больше не сможет создавать процессы, приостанавливает работу и пробует ее продолжить, давая его дочерним процессам шанс выполниться. Testlimit, запущенный с параметром -n на системе с Windows 7 и 4Гб RAM уже другого, отличного от ограничения резидентной доступной памяти, предела - ограничения выделенной системной памяти:

На снимке снизу вы можете увидеть, что отладчик ядра сообщает не только о том, что был достигнут предел выделенной системной памяти, но и о том, что, после достижения этого ограничения, имели место тысячи ошибок распределения памяти, как виртуальной, так и памяти, выделенной под выгружаемый пул (предел выделенной системной памяти фактически был достигнут несколько раз, так как, когда случалась ошибка, связанная с нехваткой объема файла подкачки, этот самый объем увеличивался, отодвигая это ограничение):

До запуска Testlimit средний уровень выделенного объема памяти был равен приблизительно 1,5Гб, так что потоки заняли около 8Гб выделенной памяти. Следовательно, каждый процесс потреблял примерно 8 Гб/6600 или 1,2Мб. Результат выполнения команды!vm отладчика ядра, которая показывает распределение собственной памяти (от англ. private memory) для каждого процесса, подтверждает верность данного вычисления:

Начальный объем выделенной памяти под стек потока, описанный ранее, оказывает незначительное влияние на остальные запросы на предоставление памяти, требуемой для структур данных адресного пространства процесса, записей таблицы страниц, таблицы дескрипторов, объектов процесса и потока, и собственных данных, которые процесс создает во время своей инициализации.

Сколько процессов и потоков будет достаточно?
Таким образом, ответы на вопросы "сколько потоков поддерживает Windows?" и "сколько процессов вы можете одновременно запустить на Windows?" взаимосвязаны. Помимо нюансов методов, по которым потоки определяют размер их стека и процессы определяют их минимальный рабочий набор страниц, двумя главными факторами, определяющим ответы на эти вопросы для каждой конкретной системы, являются объем физической памяти и ограничение выделенной системной памяти. В любом случае, если приложение создает достаточное количество потоков или процессов, чтобы приблизиться к этим пределам, то его разработчику следует пересмотреть проект этого приложения, поскольку всегда существуют различные способы достигнуть того же результата с разумным числом процессов. Например, основной целью при масштабировании приложения является стремление сохранить число выполняющихся потоков равным числу ЦП, и один из способов добиться этого состоит в переходе от использования синхронных операции ввода/вывода к асинхронным с использованием портов завершения, что должно помочь сохранить соответствие числа запущенных потоков с числом ЦП.

Рассмотрев методы сжатия, объединения, кэширования и создания параллельных соединений, разумно было бы заняться следующим вопросом: Какая часть страницы должна загружаться вместе с основным HTML-файлом, а какая — только с внешними файлами?

Было собрано тестовое окружение в виде одной страницы, для которой применены различные оптимизационные техники (заодно было получено реальное ускорение для загрузки произвольной страницы и показано, как все эти техники реально влияют на скорость загрузки страницы).

Кроме того, были проведены теоретические выкладки для определения оптимального распределения загрузки по стадиям с учетом всех аспектов.

Реальная ситуация

Рис. 29. Диаграмма загрузки (неизмененного) сайта WebHiTech.ru

Основная идея вариации потока загрузки заключалась в создании минимального количества «белых мест» на диаграмме загрузки. Как видно из рис. 29, около 80% при загрузке страницы составляют простои соединений (естественно, что данный график не отражает реальную загрузку открытых в браузере каналов загрузки, однако, при уточнении картины ситуация практически не меняется). Параллельные загрузки начинаются только после прохождения «узкого места», которое заканчивается (в данном случае) после предзагрузки страницы — после CSS-файла.

Для оптимизации скорости загрузки нам нужно уменьшить число файлов (вертикальные стрелки), загружающихся параллельно, и «сдвинуть» их максимально влево (горизонтальная стрелка). Уменьшение «белых мест» (фактически, уменьшение простоя каналов загрузки), по идее, должно увеличить скорость загрузки за счет ее распараллеливания. Давайте посмотрим, действительно ли это так и как этого добиться.

Шаг первый: простая страница

Вначале бралась обычная страница, для которой использовалось только gzip-сжатие HTML-файла. Это самое простое, что может быть сделано для ускорения загрузки страницы. Данная оптимизация бралась за основу, с которой сравнивалось все остальное. Для тестов препарировалась главная страница конкурса WebHiTech (http://webhitech.ru/) с небольшим количеством дополнительных картинок (чтобы было больше внешних объектов, и размер страницы увеличивался).

В самом начале (head) страницы замеряется начальное время, а по событию window.onload (заметим, что только по нему, ибо только оно гарантирует, что вся страница целиком находится в клиентском браузере) — конечное, затем вычисляется разница. Но этот очень простой пример, перейдем к следующим шагам.

Шаг второй: уменьшаем изображения

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

Дополнительно с минимизацией картинок была уменьшена таблица стилей (через CSS Tidy) и сам HTML-файл (убраны лишние пробелы и переводы строк). Скриптов на странице не было, поэтому общее время загрузки изменилось не сильно. Но это еще не конец, и мы переходим к третьему шагу.

Шаг третий: все-в-одном

Можно использовать data:URI и внедрить все изображения в соответствующие HTML/CSS-файлы, уменьшив, таким образом, размер страницы (за счет gzip-сжатия, по большому счету, потому что таблица стилей перед этим не сжималась) еще на 15%, однако, время загрузки при этом уменьшилось всего на 4% (при включенном кэшировании, уменьшилось число запросов с 304-ответом). При загрузке страницы в первый раз улучшения гораздо более стабильны: 20%.

CSS-файл, естественно, тоже был включен в HTML, поэтому при загрузке всей страницы осуществлялся только один запрос к серверу (для отображения целой страницы с парой десяткой объектов).

Шаг четвертый: нарезаем поток

Можно попробовать распределить первоначальный монолитный файла на несколько (5- 10) равных частей, которые бы затем собирались и внедрялись прямо в document.body.innerHTML. Т.е. сам начальный HTML-файл очень мал (фактически, содержит только предзагрузчик) и загружается весьма быстро, а после этого стартует параллельная загрузка еще множества одинаковых файлов, которые используют канал загрузки максимально плотно.

Однако, как показали исследования, издержки на XHR-запросы и сборку innerHTML на клиенте сильно превосходят выигрыш от такого распараллеливания. В итоге, страница будет загружаться в 2-5 раз дольше, размер при этом изменяется не сильно.

Можно попробовать использовать вместо XHR-запросов классические iframe, чтобы избежать части издержек. Это помогает, но не сильно. Страница все равно будет загружаться в 2-3 раза дольше, чем хотелось бы.

И немного к вопросу применения фреймов: очень часто наиболее используемые части сайта делают именно на них, чтобы снизить размер передаваемых данных. Как уже упомянуто выше, основная часть задержек происходит из-за большого количества внешних объектов на странице, а не из-за размера внешних объектов. Поэтому на данный момент эта технология далеко не так актуальна, как в 90-е годы прошлого столетия.

Также стоит упомянуть, что при использовании iframe для навигации по сайту встает проблема обновления этой самой навигации (например, если мы хотим выделить какой-то пункт меню как активный). Корректное решение этой проблемы требует от пользователя включенного JavaScript, и оно довольно нетривиально с технической стороны. В общем, если без фреймов можно обойтись при проектировании сайта — значит, их не нужно использовать.

Шаг пятый: алгоритмическое кэширование

Проанализировав ситуацию с первыми тремя шагами, мы видим, что часть ускорения может быть достигнута, если предоставить браузеру возможность самому загружать внешние файлы как отдельные объекты, а не как JSON-код, который нужно как-то преобразовать. Дополнительно к этому всплывают аспекты кэширования: ведь быстрее загрузить половину страницы, а для второй половины проверить запросами со статус- кодами 304, что объекты не изменились. Загрузка всей страницы клиентом в первый раз в данном случае будет немного медленнее (естественно, решение по этому поводу будет зависеть от числа постоянных пользователей ресурса).

В результате удалось уменьшить время загрузки еще на 5%, итоговое ускорение (в случае полного кэша) достигло 20%, размер страницы при этом уменьшился на 21%. Возможно вынесение не более 50% от размера страницы в загрузку внешних объектов, при этом объекты должны быть примерно равного размера (расхождение не более 20%). В таком случае скорость загрузки страницы для пользователей с полным кэшем будет наибольшей. Если страница оптимизируется под пользователей с пустым кэшем, то наилучший результат достигается только при включении всех внешних файлов в исходный HTML.

Итоговая таблица

Ниже приведены все результаты оптимизации для отдельной взятой страницы. Загрузка тестировалась на соединении 100 Кб/с, общее число первоначальных объектов: 23.

Таблица 5. Различные способы параллельной загрузки объектов на странице

Шаг шестой: балансируем стадии загрузки

Итак, как нам лучше всего балансировать загрузку страницы между ее стадиями? Где та «золотая середина», обеспечивающая оптимум загрузки? Начнем с предположения, что у нас уже выполнены все советы по уменьшению объема данных. Это можно сделать всегда, это достаточно просто (в большинстве случаев нужны лишь небольшие изменения в конфигурации сервера). Также предположим, что статика отдается уже с кэширующими заголовками (чтобы возвращать 304-ответы в том случае, если ресурсный файл физически не изменился с момента последнего посещения).

Что дальше? Дальнейшие действия зависят от структуры внешних файлов. При большом (больше двух) числе файлов, подключаемых в страницы, необходимо объединить файлы стилей и файлы скриптов. Ускорение предзагрузки страницы будет налицо.

Если объем скриптов даже после сжатия достаточно велик (больше 10 Кб), то стоит их подключить перед закрывающим , либо вообще загружать по комбинированному событию window.onload (динамической загрузке скриптов посвящено начало седьмой главы). Тут мы, фактически, переносим часть загрузки из второй стадии в четвертую, ускоряется лишь «визуальная» загрузка страницы.

Общее количество картинок должно быть минимальным. Однако тут тоже очень важно равномерно распределить их объем по третьей стадии загрузки. Довольно часто одно изображение в 50-100 Кб тормозит завершение загрузки, разбиение его на 3-4 составляющие способно ускорить общий процесс. Поэтому при использовании большого количества фоновых изображений лучше разбивать их на блоки по 10-20, которые будут загружаться параллельно.

Шаг седьмой: балансируем кэширование

Если все же на странице присутствует больше 10 внешних объектов в третьей стадии (картинок и различных мультимедийных файлов), тут уже стоит вводить дополнительный хост для увеличения числа параллельных потоков. В этом случае издержки на DNS-запрос окупятся снижением среднего времени установления соединения. 3 хоста стоит вводить уже после 20 объектов, и т.д. Всего не более 4 (как показало исследование рабочей группы Yahoo! после 4 хостов издержки, скорее, возрастут, чем снизятся).

Вопрос о том, сколько объема страницы включать в сам HTML-файл (кода в виде CSS, JavaScript или data:URI), а сколько оставлять на внешних объектах, решается очень просто. Баланс в данном случае примерно равен соотношению числа постоянных и единовременных посещений. Например, если 70% пользователей заходят на сайт в течение недели, то примерно 70% страницы должно находиться во внешних объектах и только 30% — в HTML-документе.

Когда страницу должны увидеть только один раз, логично будет включить все в саму страницу. Однако тут уже вступают в силу психологические моменты. Если у среднего пользователя страница при этом будет загружаться больше 3-4 секунд (учитывая время на DNS-запрос и соединение с сервером), то будет необходимо разбиение на две части: первоначальная версия, которая отобразится достаточно быстро, и остальная часть страницы.

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

Заключение

Вот так, на примере обычной страницы (уже достаточно хорошо сделанной, стоит отметить) мы добились ускорения ее загрузки еще на 15-20% (и это без учета применения gzip-сжатия для HTML, которое в данном случае дает примерно 10% от общей скорости). Наиболее важные методы уже приведены выше, сейчас лишь можно упомянуть, что при оптимизации скорости работы страницы лучше всегда полагаться на внутренние механизмы браузера, а не пытаться их эмулировать на JavaScript (в данном случае речь идет об искусственной «нарезке» потока). Может быть, в будущем клиентские машины станут достаточно мощными (или же JavaScript-движки — лучше оптимизированными), чтобы такие методы заработали. Сейчас же выбор один — алгоритмическое кэширование.

• Перевод
• Tutorial

От переводчика: данная статья является седьмой в цикле переводов официального руководства по библиотеке SFML. Прошлую статью можно найти Данный цикл статей ставит своей целью предоставить людям, не знающим язык оригинала, возможность ознакомится с этой библиотекой. SFML - это простая и кроссплатформенная мультимедиа библиотека. SFML обеспечивает простой интерфейс для разработки игр и прочих мультимедийных приложений. Оригинальную статью можно найти . Начнем.

Что такое поток?

Поток - это по сути последовательность инструкций, которые выполняются параллельно с другими потоками. Каждая программа создает по меньшей мере один поток: основной, который запускает функцию main(). Программа, использующая только главный поток, является однопоточной; если добавить один или более потоков, она станет многопоточной.

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

Потоки SFML или std::thread?

Если вы работаете с компилятором, который поддерживает новый стандарт и содержит заголовочный файл, забудьте о классах потоков SFML и используйте стандартные классы C++ вместо них. Но, если вы работаете с компилятором, не поддерживающим данный стандарт, или планируете распространять ваш код и хотите добиться полной портируемости, потоковые классы SFML являются хорошим выбором

Создание потоков с помощью SFML

#include #include void func() { // эта функция запускается когда вызывается thread.launch() for (int i = 0; i < 10; ++i) std::cout << "I"m thread number one" << std::endl; } int main() { // создание потока с функцией func в качестве точки входа sf::Thread thread(&func); // запуск потока thread.launch(); // главные поток продолжает быть запущенным... for (int i = 0; i < 10; ++i) std::cout << "I"m the main thread" << std::endl; return 0; }
В этом коде функции main и func выполняются параллельно после вызова thread.launch(). Результатом этого является то, что текст, выводимый обеими функциями, смешивается в консоли.

Точка входа в поток, т.е. функция, которая будет выполняться, когда поток запускается, должна быть передана конструктору sf::Thread . sf::Thread пытается быть гибким и принимать различные точки входа: non-member функции или методы классов, функции с аргументами или без них, функторы и так далее. Приведенный выше пример показывает, как использовать функцию-член, вот несколько других примеров.

• non-member функция с одним аргументом:

  Void func(int x) { } sf::Thread thread(&func, 5);

• метод класса:

  Class MyClass { public: void func() { } }; MyClass object; sf::Thread thread(&MyClass::func, &object);

• функтор (функциональный объект):

  Struct MyFunctor { void operator()() { } }; sf::Thread thread(MyFunctor());

// с лямбда-функцией sf::Thread thread((){ std::cout << "I am in thread!" << std::endl; });
// с std::bind void func(std::string, int, double) { } sf::Thread thread(std::bind(&func, "hello", 24, 0.5));
Если вы хотите использовать sf::Thread внутри класса, не забудьте, что он не имеет стандартного конструктора. Поэтому, вы должны инициализировать его в конструкторе вашего класса в списке инициализации:

Class ClassWithThread { public: ClassWithThread() : m_thread(&ClassWithThread::f, this) { } private: void f() { ... } sf::Thread m_thread; };
Если вам действительно нужно создать экземпляр sf::Thread после инициализации объекта, вы можете создать его в куче.

Запуск потока

Sf::Thread thread(&func); thread.launch();
launch вызывает функцию, которую вы передали в конструктор нового потока, и сразу же завершает свою работу, так что вызывающий поток может сразу же продолжить выполнение.

Остановка потоков

Sf::Thread thread(&func); // запуск потока thread.launch(); ... // выполнение блокируется до тех пор, пока поток не завершится thread.wait();
Функция ожидания также неявно вызывается деструктором sf::Thread , так что поток не может оставаться запущенным (и бесконтрольным) после того, как его экземпляр sf::Thread уничтожается. Помните это, когда вы управляете вашими потоками (смотрите прошлую секцию статьи).

Приостановка потока

Void func() { ... sf::sleep(sf::milliseconds(10)); ... }
sf::sleep имеет один аргумент - время приостановки. Это время может быть выражено в любой единице, как было показано в статье про .

Обратите внимание, что вы можете приостановить любой поток с помощью данной функции, даже главный поток.

Sf::sleep является наиболее эффективным способом приостановить поток: на протяжении приостановки потока, он (поток) практически не потребляет ресурсы процессора. Приостановка, основанная на активном ожидании, вроде пустого цикла while, потребляет 100% ресурсов центрального процессора и делает… ничего. Однако имейте в виду, что продолжительность приостановки является просто подсказкой; реальная продолжительность приостановки (больше или меньше указанного вами времени) зависит от ОС. Так что не полагайтесь на эту функцию при очень точном отсчете времени.

Защита разделяемых данных

Существует несколько программных инструментов, которые могут помочь вам защитить разделяемые данные и сделать ваш код потокобезопасным, их называют примитивами синхронизации. Наиболее распространенными являются следующие примитивы: мьютексы, семафоры, условные переменные и спин-блокировки. Все они - варианты одной и той же концепции: они защищают кусок кода, давая только определенному потоку право получать доступ к данным и блокируя остальные.

Наиболее распространенным (и используемым) примитивом является мьютекс. Мьютекс расшифровывается как «Взаимное исключение». Это гарантия, что только один поток может выполнять код. Посмотрим, как мьютексы работают, на примере ниже:

#include #include sf::Mutex mutex; void func() { mutex.lock(); for (int i = 0; i < 10; ++i) std::cout << "I"m thread number one" << std::endl; mutex.unlock(); } int main() { sf::Thread thread(&func); thread.launch(); mutex.lock(); for (int i = 0; i < 10; ++i) std::cout << "I"m the main thread" << std::endl; mutex.unlock(); return 0; }
Этот код использует общий ресурс (std::cout), и, как мы видим, это приводит к нежелательным результатам. Вывод потоков смешался в консоли. Чтобы убедиться в том, что вывод правильно напечатается, вместо того, чтобы быть беспорядочно смешанным, мы защищаем соответствующие области кода мьютексом.

Первый поток, который достигает вызова mutex.lock(), блокирует мьютекс и получает доступ к коду, который печатает текст. Когда другие потоки достигают вызова mutex.lock(), мьютекс уже заблокирован, и другие потоки приостанавливают свое выполнение (это похоже на вызов sf::sleep, спящий поток не потребляет время центрального процессора). Когда первый поток разблокирует мьютекс, второй поток продолжает свое выполнение, блокирует мьютекс и печатает текст. Это приводит к тому, что текст в консоли печатается последовательно и не смешивается.

Мьютекс - это не только примитив, который вы можете использовать для защиты разделяемых данных, вы можете использовать его во многих других случаях. Однако, если ваше приложение делает сложные вещи при работе с потоками, и вы чувствуете, что возможностей мьютексов недостаточно - не стесняйтесь искать другую библиотеку, обладающую большим функционалом.

Защита мьютексов

Чтобы быть уверенным, что мьютекс всегда разблокирован в среде, в которой он (мьютекс) может выбросить исключение, SFML предоставляет RAII класс, позволяющий обернуть мьютекс в класс sf::Lock. Блокировка происходит в конструкторе, разблокировка происходит в деструкторе. Просто и эффективно.

Sf::Mutex mutex; void func() { sf::Lock lock(mutex); // mutex.lock() functionThatMightThrowAnException(); // mutex.unlock(), если функция выбросит исключение } // mutex.unlock()
Помните, что sf::Lock может также быть использован в функциях, которые имеют множество возвращаемых значений.

Sf::Mutex mutex; bool func() { sf::Lock lock(mutex); // mutex.lock() if (!image1.loadFromFile("...")) return false; // mutex.unlock() if (!image2.loadFromFile("...")) return false; // mutex.unlock() if (!image3.loadFromFile("...")) return false; // mutex.unlock() return true; } // mutex.unlock()

Распространенные заблуждения

Встроенные функции Windows не предусматривают возможность докачки файлов - в итоге в случае обрыва связи информацию приходится загружать заново, затрачивая на это лишнее время и нервы и оплачивая лишний трафик. И даже при нормальном соединении быстрым такой вариант скачивания не назовешь, ведь закачка производится в один поток. Другое дело - специальные менеджеры закачки (download-менеджеры), умеющие возобновлять закачку с того места, где она была прервана, и разбивающие скачиваемые файлы на секции, загружаемые одновременно, что позволяет добиться существенного увеличения скорости скачивания.

На рынке сегодня предлагается множество download-менеджеров со сходной функциональностью - разобраться в том, какое решение окажется лучшим в конкретной ситуации, непросто. Поэтому в данной статье мы проведем сравнительную оценку нескольких популярных download-менеджеров, предлагаемых разными разработчиками.

Сразу уточним, что все они, разумеется, поддерживают многопоточное скачивание и докачку файлов после обрыва связи и автоматически подбирают оптимальную (в зависимости от типа соединений) скорость скачивания. А также интегрируются в популярные браузеры, заменяя стандартный модуль закачки, и следят за буфером обмена, самостоятельно выявляя ссылки. А значит, в целом любое из названных решений обеспечивает быстрое и надежное скачивание файлов с FTP- и HTTP-серверов.

Между собой менеджеры закачки различаются разнообразными нюансами (см. таблицу). В частности, не все они обеспечивают частичное скачивание ZIP-архивов, корректно распознают ссылки с файлохранилищ, таких как Rapidshare в бесплатном режиме, и позволяют напрямую (то есть просто добавив URL вида http://www.youtube.com/watch?v=...) скачивать клипы с онлайновых видеосервисов3 (YouTube, Google Video и др.). Не все download-менеджеры умеют производить скачивание с защищенных FTP- и веб-серверов (то есть по протоколам SFTP и HTTPS соответственно) и позволяют оценить размер файла перед его загрузкой. А уж поддержка BitTorrent- и eDonkey-клиентов вообще реализована лишь в некоторых менеджерах загрузки, что, впрочем, на наш взгляд, уже не столь актуально, поскольку функциональность подобных клиентов невелика. В различных решениях разные списки поддерживаемых интернет-браузеров, да и сам принцип подобной интеграции различен: где-то достаточно просто включить соответствующие флажки в настройках, а где-то потребуется предварительно скачать и установить соответствующий браузеру плагин. Кроме того, имеются и более тонкие различия, касающиеся самого процесса закачки, - например в одних решениях при обнаружении активности браузера приоритет по трафику автоматически изменяется (а где-то это придется делать вручную), в других можно назначать закачкам приоритеты (что в части продуктов не предусмотрено) и т.п.

GetRight/GetRight Pro 6.3e

Разработчик : Headlight Software

Размер дистрибутива: GetRight - 4,78 Мбайт; GetRight Pro - 4,91 Мбайт

Работа под управлением: Windows 95/98/Me/NT/2000/XP/Vista

Способ распространения: shareware (30-дневная демо-версия: GetRight - http://download.getright.com/getright-download.exe ; GetRight Pro - http://download.getright.com/getright_pro_setup.exe)

Цена : GetRight - 19,95 долл.; GetRight Pro - 49,95 долл.

GetRight - давно присутствующий на рынке и завоевавший популярность благодаря удобству и надежной работе менеджер закачки, который сегодня уже далеко не столь привлекателен для широкого круга пользователей, поскольку по ряду параметров уступает аналогам и предлагается по весьма высокой цене. Да и дальнейшая разработка этого решения, по сути, уже не ведется. Данный download-менеджер позволяет скачивать файлы (в том числе по расписанию) по протоколам HTTP, HTTPS, FTP и FTPS и может использоваться для скачивания файлов с файлообменных серверов, получения новых музыкальных клипов в Podcast/RSS-канал и скачивания файлов по протоколу BitTorrent (имеется возможность одновременного получения части данных по FTP/HTTP, а части - из BitTorrent с последующим «склеиванием» на лету). Предусмотрена возможность автоматического добавления полученных мультимедиафайлов в плейлисты приложений MediaPlayer и iTunes. Однако утилита не поможет при скачивании видео с видеохостингов и частичном скачивании архивов.

GetRight автоматически интегрируется в ведущие браузеры, причем указать перечень интересующих браузеров можно при установке утилиты. Специальный встроенный обозреватель обеспечивает просмотр структуры папок FTP-серверов и HTTP-сайтов. Ограничение трафика производится вручную путем установки максимально допустимого предела скорости закачки, при этом разрешается включить флажок для снятия этого ограничения в моменты активности скринсейвера. Перед скачиванием можно проверить интересующий адрес на существование и уточнить размер файла. Количество одновременно скачиваемых файлов и число потоков регулируются, а лучшие «зеркала» для скачивания несложно найти автоматически либо указать вручную. В зависимости от типов закачиваемые файлы могут распределяться по разным папкам, для папок разрешается устанавливать приоритеты. По завершении закачки возможно автоматическое проведение оценки целостности полученных файлов и проверки их на вирусы.

Программа представлена в двух версиях - базовой GetRight и расширенной GetRight Pro. В Pro-версии предусмотрена возможность работы в режиме «клиент-сервер» (для скачивания файлов одним компьютером в сети, которому с остальных просто передаются ссылки) и в качестве прокси-сервера (позволяет другим интернет-утилитам использовать возможности GetRight по докачке файлов). В нее также встроен функционал для синхронизации уже скачанных файлов в случае появления на серверах их обновлений и закачки файлов на серверы, имеется скриптовый язык (обеспечивает расширенные возможности управления скачиванием), можно лимитировать скорость скачивания отдельных файлов и др.

Download Master 5.5.12.1171

Разработчик: WestByte Software

Размер дистрибутива: стандартная версия - 5,24 Мбайт; версия Portable - 3,7 Мбайт

Работа под управлением: Windows 95/98/Me/NT 4.0/2000/XP/Vista

Способ распространения: freeware (http://www.westbyte.com/dm/index.phtml?page=download&lng=Russian)

Цена: бесплатно

Download Master - многофункциональный download-менеджер, позволяющий загружать файлы не только с FTP- и HTTP-серверов, но также с популярных видеосервисов (YouTube, Google Video, RuTube, Видео@mail.?ru, Rambler Vision) и файлохранилищ (включая Rapidshare) в бесплатном режиме. В случае ZIP-архивов их содержимое может просматриваться перед закачкой, предусмотрена также возможность закачки только выбранных из архива файлов. Реализован поиск файлов, программ, игр и музыки в каталоге файлов TopDownloads.

Download Master интегрируется во все самые популярные браузеры (для клонов IE потребуется настройка параметров), а встроенный в утилиту FTP Explorer обеспечивает удобную навигацию по FTP-серверам. Утилита умеет самостоятельно определять типы загружаемых файлов и распределяет их по категориям (программы, музыка, видео и пр.), а при снижении скорости автоматически перезапускает закачку, что позволяет избежать простоев. Скачивание ведется в несколько потоков. При необходимости для определенных сайтов число потоков несложно ограничить и настроить программу так, чтобы скачиваемые с них файлы сохранялись в определенных папках и/или категориях. По окончании скачивания возможно отключение от Интернета, переход в спящий режим, выключение компьютера и т.п. Предусмотрено управление скоростью закачки и автоматическое ее снижение в случае, если пользователь занялся интернет-серфингом. Возможна работа по расписанию, а также проверка закачанных файлов на обновление и синхронизация (автообновление) файлов на сервере и локальном ПК.

Программа представлена в двух версиях: стандартной Download Master и портативной Download Master Portable. Последняя не требует установки и может быть записана на флэшку или внешний диск, что обеспечивает возможность скачивания файлов на любом подключенном к Интернету компьютере. В версии Portable нет интеграции с браузерами и отключена возможность экспорта/импорта настроек, поэтому для применения на собственном компьютере более удобной будет стандартная версия программы.

ReGet Deluxe 5.2

Разработчик: ReGet Software

Размер дистрибутива: ReGet Deluxe - 2,5 Мбайт; ReGet Deluxe Personal - 2 Мбайт

Работа под управлением: Windows 2000(SP3/SP4)/XP(SP2)/Server 2003/Vista

Способ распространения: shareware (30-дневная демо-версия: ReGet Deluxe - http://download.reget.com/regetdx.exe ; ReGet Deluxe Personal - http://download.reget.com/regetdxpers.exe)

Цена: ReGet Deluxe - 600 руб; ReGet Deluxe Personal - бесплатно (только для домашнего применения)

ReGet Deluxe - многофункциональный менеджер закачек, позволяющий загружать файлы (в том числе по расписанию) не только с обычных FTP- и HTTP-серверов, но и с защищенных файловых (SFTP) и веб (HTTPS)-серверов. Также утилита умеет скачивать мультимедиаконтент через потоковые протоколы (MMS, RTSP) и может использоваться для скачивания с файлообменных серверов (MySpace.com, iDrive.com и т.д.), однако она не поможет скачать флэш-видео с видеохостингов, в частности с YouTube. Утилита отображает размер скачиваемого файла еще перед закачкой, позволяет просматривать ZIP-архивы и скачивать их частично и умеет автоматически переключаться на более быстрые «зеркала».

ReGet Deluxe автоматически интегрируется в Internet Explorer и ряд его клонов, интеграция в часть браузеров осуществляется через плагины сторонних разработчиков. Встроенный FTP-браузер упрощает поиск нужных файлов на FTP-серверах. Загружаемые файлы могут автоматически раскладываться по разным папкам с учетом назначенной им пользователем категории, причем при использовании макросов допускается даже автоматическое создание нужных папок в соответствии с расширениями скачанных файлов, датой загрузки или именем сервера, с которого был скачан файл. При замедлении конкретной закачки утилита автоматически отключается от сервера и соединяется с ним снова, давая закачке стартовый толчок. Одновременно может загружаться несколько файлов - их количество (как и число потоков) зависит от типа соединения. В ходе скачивания утилита замечает активность браузера и автоматически понижает свой трафик при передаче браузером данных. По завершении скачивания она может автоматически разорвать интернет-соединение, запустить внешнее приложение, выключить компьютер и т.п.

Программа представлена в двух редакциях: ReGet Deluxe и ReGet Deluxe Personal, последняя не имеет мультиязычной поддержки и предназначена для использования только на домашнем компьютере. Утилита может работать в одном из трех режимов: упрощенном (в нем работают лишь базовые функции), расширенном и режиме эксперта, переключение между ними осуществляется при помощи команд главного меню.

Free Download Manager 3.0 build 848

Разработчик : Free Download Manager.ORG

Размер дистрибутива: 6,39 Мбайт

Работа под управлением: Windows 9x/Me/2000/2003/XP/Vista (только 32-битные версии)

Способ распространения: freeware (http://freedownloadmanager.org/download.htm)

Цена: бесплатно

Free Download Manager - полноценный и очень удобный менеджер закачки, позволяющий загружать файлы (в том числе по расписанию) с FTP- и HTTP-серверов, защищенных веб (HTTPS)-серверов, а также с популярных файлохранилищ и видеосервисов (YouTube, Google Video и др.). Возможна одновременная разгрузка от нескольких «зеркал». При скачивании видеоконтента допускается автоматическое преобразование FLV-файлов в другие видеоформаты с помощью встроенного перекодировщика видео. Предусмотрена частичная загрузка ZIP-архивов, скачивание файлов через сеть BitTorrent и целиком сайтов для их последующего просмотра в офлайне. Имеется также специальный Upload manager, обеспечивающий загрузку файлов в онлайновое хранилище WikiFortio (http://www.wikifortio.com/), где разрешается до месяца хранить файлы размером до 100 Мбайт.

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

Программа представлена в двух редакциях: стандартной Free Download Manager и облегченной Free Download Manager Lite. В последней нет поддержки протокола BitTorrent, а также отсутствуют встроенный видеоконвертор и менеджер закачки файлов на серверы. В обеих редакциях есть функционал для записи портативной версии, которая не требует установки и может быть записана на флэшку или внешний диск.

Orbit Downloader 2.8.13

Разработчик: OrbitDownloader

Размер дистрибутива: 2,17 Мбайт

Работа под управлением: Windows NT/2000/XP/2003/Vista

Способ распространения: freeware (http://www.orbitdownloader.com/download.htm)

Цена: бесплатно

Orbit Downloader - очень простой в применении, но достаточно функциональный и удобный менеджер закачки, отличающийся расширенной поддержкой социальных сервисов. Он позволяет загружать не только файлы по протоколам FTP и HTTP, но и разного рода потоковый флэш-, видео- и аудиоконтент через протоколы RTSP/MMS/RTMP с MySpace, YouTube, Imeem, Pandora и других подобных сервисов. Возможна загрузка файлов с файлообменных сервисов (включая Rapidshare, MegaUpload, 4shared, Depositfiles и пр.), а также проведение загрузки по технологии Metalink, позволяющей скачивать отдельные сегменты из сетей практически с любым протоколом. Скачивание медиаконтента с социальных сервисов реализовано в этой утилите через встроенный модуль Grab++, работающий только под Internet Explorer. Причем технология скачивания принципиально отличается от принятой в других download-менеджерах: если обычно менеджеру загрузки принято просто указывать ссылку вида http://www.youtube.com/watch?v=.., то модуль Grab++ определяет прямую ссылку при наведении указателя мыши на нужный ролик в окне его просмотра.

Программа интегрируется в популярные браузеры, причем поддержка нужных браузеров настраивается уже в ходе ее установки. Ограничение трафика производится вручную через настройки. Одновременно могут скачиваться несколько файлов - каждый в несколько потоков, число потоков регулируется, можно также изменить количество потоков для отдельно взятой закачки. Уточнить размер файла перед закачкой невозможно, равно как и частично скачать ZIP-архив, но разрешается просматривать содержимое ZIP-файла до его скачивания. Увеличение скорости закачки достигается не только за счет многопоточности, но и благодаря использованию технологии Orbitnet, базирующейся на Р2Р и автопоиске «зеркал». Уже закачанные файлы несложно перераспределить по разным папкам. По завершении скачивания утилита может проверить файл на вирусы встроенным антивирусом, автоматически разорвать интернет-соединение и выключить компьютер.

FlashGet 1.9.6

Разработчик : Trend Media Corporation Ltd

Размер дистрибутива: 4,43 Мбайт

Работа под управлением: Windows (все версии)

Способ распространения: freeware (http://www.flashget.com/en/download.htm?uid=undefined)

Цена: бесплатно

FlashGet - наверное, самый популярный в мире менеджер закачки файлов с наибольшей историей развития. Сегодня эта утилита по-прежнему достойна внимания благодаря удобству, простоте использования и высокой скорости скачивания, однако ее функционал устроит не всех пользователей, поскольку в большинстве своем он ограничен лишь базовыми возможностями. FlashGet позволяет скачивать файлы по протоколам HTTP/FTP/MMS/RTSP и вполне корректно распознает ссылки с Rapidshare. Однако в целом при работе с файловыми хостингами могут быть проблемы, а скачивание видео с видеохостингов вообще невозможно, равно как и частичная закачка ZIP-архивов. Вместе с тем в последней версии утилиты появилась возможность скачивания по протоколам BitTorrent и eMule, что предусмотрено далеко не в каждом download-менеджере.

FlashGet умеет интегрироваться в популярные браузеры, поддержка части из которых требует установки плагинов. Встроенные FTP- и HTTP-обозреватели упрощают поиск нужных файлов. Оптимальная скорость соединения указывается в настройках путем установки типа соединения, возможна установка ограничения трафика вручную выбором одного из трех предустановленных режимов. Скачиваемые файлы могут распределяться по разным папкам с учетом указанных пользователем категорий. Предусмотрен автоматический поиск «зеркал» и осуществление загрузки с самых быстрых и доступных серверов. Несложно настроить проведение скачивания в строго назначенное время, а по его завершении утилита может проверить файлы на вирусы и разорвать соединение.

ReGet Junior 2.2

Разработчик: ReGet Software

Размер дистрибутива: 1,66 Мбайт

Работа под управлением: Windows 95/98/Me/NT/2000/XP

Способ распространения: shareware (30-дневная демо-версия - http://download.reget.com/regetjr.exe)

Цена: 250 руб.

ReGet Junior - самый простой в применении download-менеджер, ориентированный на начинающих пользователей. Утилита обладает минимальным функционалом, и ее привлекательность заключается лишь в том, что разбираться с настройками не потребуется в принципе. Она позволяет загружать файлы с FTP- и HTTP-серверов и интегрируется в наиболее популярные браузеры. Скачивание ведется в несколько потоков, и одновременно могут загружаться несколько файлов; число потоков и одновременно скачиваемых файлов не регулируется.

Заключение

Итак, функционал download-менеджеров от разных разработчиков весьма схож - все они обеспечивают надежную и быструю закачку файлов из Сети. Поэтому многим домашним пользователям, работающим в наиболее популярных под Windows браузерах, вполне достаточно обзавестись для решения данной задачи одним бесплатным инструментом, например Download Master, Free Download Manager, ReGet Deluxe (в редакции Personal) или Orbit Downloader. Теоретически все они умеют скачивать разного рода информацию, включая файлы с серверов типа Rapidshare.com и, за исключением ReGet Deluxe, потоковый флэш-, видео- и аудиоконтент с YouTube и прочих социальных сервисов. Однако возможность захвата видео и flash наиболее полно реализована в Orbit Downloader, на который и стоит обратить внимание любителям закачки такого рода контента. Что касается FlashGet, то делать ставку на него, на наш взгляд, особого смысла не имеет в силу уступающей вышеназванным программам функциональности.

Выбор пользователей Google Chrome и Apple Safari скромнее - им придется воспользоваться Download Master, Free Download Manager или Orbit Downloader, поскольку в других рассмотренных download-менеджерах поддержка соответствующих браузеров отсутствует. При этом нужно иметь в виду, что закачкой медиаконтента с социальных сервисов в Orbit Downloader им воспользоваться не удастся, поскольку она работает только под Internet Explorer.