Почему мой поток загрузки файлов не распараллелен с основным потоком? Сравнительный обзор download-менеджеров Какие обычные действия программистов в таком случае

1.1. Определение потока

Потоком в Windows называется объект ядра, которому операционная система выделяет процессорное время для выполнения приложения. Каждому потоку принадлежат следующие ресурсы:

• код исполняемой функции;
• набор регистров процессора;
• стек для работы приложения;
• стек для работы операционной системы;
• маркер доступа, который содержит информацию для системы безопасности.

Все эти ресурсы образуют контекст потока в Windows . Кроме дескриптора каждый поток в Windows также имеет свой идентификатор, который уникален для потоков выполняющихся в системе. Идентификаторы потоков используются служебными программами, которые позволяют пользователям системы отслеживать работу потоков.

В операционных системах Windows различаются потоки двух типов:

• системные потоки;
• пользовательские потоки.

Системные потоки выполняют различные сервисы операционной системы и запускаются ядром операционной системы.

Пользовательские потоки служат для решения задач пользователя и запускаются приложением.

В работающем приложении различаются потоки двух типов:

• рабочие потоки (working threads);
• потоки интерфейса пользователя (user interface threads).

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

Создается поток функцией CreateThread

function CreateThread (
lpThreadAttributes: Pointer; // атрибуты защиты
dwStackSize: DWORD; // размер стека потока в байтах
lpStartAddress: TFNThreadStartRoutine; // адрес функции
lpParameter: Pointer; // адрес параметра
dwCreationFlags: DWORD; // флаги создания потока
var lpThreadId: DWORD // идентификатор потока
): THandle;

При успешном завершении функция CreateThread возвращает дескриптор созданного потока и его идентификатор, который является уникальным для всей системы. В противном случае эта функция возвращает значение nil .

Назначение параметров

lpThreadAttributes	Параметр lpThreadAttributes устанавливает атрибуты защиты создаваемого потока. До тех пор пока мы не изучим систему безопасности в Windows, мы будем устанавливать значения этого параметра в nil при вызове почти всех функций ядра Windows. В данном случае это означает, что операционная система сама установит атрибуты защиты потока, используя настройки по умолчанию.
	Параметр dwStacksize определяет размер стека, который выделяется потоку при запуске. Если этот параметр равен нулю, то потоку выделяется стек, размер которого по умолчанию равен 1 Мбайт . Это наименьший размер стека, который может быть выделен потоку. Если величина параметра dwStacksize меньше значения, заданного по умолчанию, то все равно потоку выделяется стек размером в 1 Мбайт . Операционная система Windows округляет размер стека до одной страницы памяти, который обычно равен 4 Кбайт .
	Параметр lpStartAddress указывает на исполняемую потоком функцию.
	Видно, что функции потока может быть передан единственный параметр lpParameter , который является указателем на пустой тип. Это ограничение следует из того, что функция потока вызывается операционной системой, а не прикладной программой. Программы операционной системы являются исполняемыми модулями и поэтому они должны вызывать только функции, сигнатура которых заранее определена. Поэтому для потоков определили самый простой список параметров, который содержит только указатель. Так как функции потоков вызываются операционной системой, то они также получили название функции обратного вызова .
	Параметр dwCreationFiags определяет, в каком состоянии будет создан поток. Если значение этого параметра равно 0, то функция потока начинает выполняться сразу после создания потока. Если же значение этого параметра равно CREATE_SUSPENDED , то поток создается в подвешенном состоянии. В дальнейшем этот поток можно запустить вызовом функции ResumeThread .
	Параметр lpThreadId является выходным, т. е. его значение устанавливает Windows. Этот параметр должен указывать на переменную, в которую Windows поместит идентификатор потока. Этот идентификатор уникален для всей системы и может в дальнейшем использоваться для ссылок на поток. Идентификатор потока главным образом используется системными функциями и редко функциями приложения. Действителен идентификатор потока только на время существования потока. После завершения потока тот же идентификатор может быть присвоен другому потоку.

При создании потока его базовый приоритет устанавливается как сумма приоритета процесса, в контексте которого этот поток выполняется, и уровня приоритета потока THREAD_PRIORITY_NORMAL .

В листинге 1.1 приведен пример программы, которая использует функцию CreateThread для создания потока и демонстрирует способ передачи параметров исполняемой потоком функции.

Листинг 1.1. Создание потока функцией CreateThread

Program CreateThreadd; {$APPTYPE CONSOLE} uses SysUtils, Windows; var n: Integer = 0; inc: Integer = 10; hThread: HWND; IDThread: DWORD; procedure Add(iNum: Pointer); stdcall; begin Writeln("Thread is started"); n:= n + Integer(iNum^); Writeln("Thread is finished"); end; begin Writeln("n = ", n); //запускаем поток Add hThread:= CreateThread(nil, 0, @Add, @inc, 0, IDThread); //Ждем, пока поток Add закончит работу WaitForSingleObject(hThread, INFINITE); //закрываем дескриптор потока Add CloseHandle(hThread); Writeln("n = ", n); Readln; end.

Отметим, что в этой программе используется функция WaitForSingleObject , которая ждет завершения потока Add .

Поток завершается вызовом функции ExitThread , которая имеет следующий прототип:

procedure ExitThread (
dwExitCode: DWORD //код завершения потока
); stdcall;

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

Один поток может завершить другой поток, вызвав функцию TerminateThread

function TerminateThread (
hThread: THandle; //дескриптор потока
dwExitCode: DWORD; //код завершения потока
): BOOL; stdcall;

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

В листинге 1.2 приведена программа, которая демонстрирует работу функции TerminateThread .

Program TerminateThreadd; {$APPTYPE CONSOLE} uses SysUtils, Windows; var count: Cardinal = 0; hThread: HWND; IDThread: DWORD; c: Char; b1: Boolean = True; procedure thread; stdcall; var b2: Boolean; begin b2:= True; while b2 do begin count:= count + 1; Sleep(100); // немного отдохнем end; end; begin hThread:= CreateThread(nil, 0, @thread, nil, 0, IDThread); while b1 do begin Write("Input ""y"" to display the count or any char to finish: "); Readln(c); if c = "y" then Writeln("count = ", count) else Break; end; //прерываем выполнение потока thread TerminateThread(hThread, 0); //закрываем дескриптор потока CloseHandle(hThread); end.

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

function SuspendThread (
hThread: THandle //дескриптор потока
): DWORD; stdcall;

Эта функция увеличивает значение счетчика приостановок на 1 и, при успешном завершении, возвращает текущее значение этого счетчика. В случае неудачи функция SuspendThread возвращает значение, равное -1.

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

Для возобновления исполнения потока используется функция ResumeThread , которая имеет следующий прототип:

function ResumeThread (
hThread: THandle //дескриптор потока
): DWORD; stdcall;

Функция ResumeThread уменьшает значение счетчика приостановок на 1 при условии, что это значение было больше нуля. Если полученное значение счетчика приостановок равно 0, то исполнение потока возобновляется, в противном случае поток остается в подвешенном состоянии. Если при вызове функции ResumeThread значение счетчика приостановок было равным 0, то это значит, что поток не находится в подвешенном состоянии. В этом случае функция не выполняет никаких действий. При успешном завершении функция ResumeThread возвращает текущее значение счетчика приостановок, в противном случае - значение -1.

Поток может задержать свое исполнение вызовом функции Sleep , которая имеет следующий прототип:

procedure Sleep (
dwMilliseconds: DWORD //миллисекунды
); stdcall;

Единственный параметр функции Sleep определяет количество миллисекунд, на которые поток, вызвавший эту функцию, приостанавливает свое исполнение. Если значение этого параметра равно 0, то выполнение потока просто прерывается, а затем возобновляется при условии, что нет других потоков, ждущих выделения процессорного времени. Если же значение этого параметра равно INFINITE , тo поток приостанавливает свое исполнение навсегда, что приводит к блокированию работы приложения.

В листинге 1.3 приведена программа, которая демонстрирует работу функций SuspendThread , ResumeThread и Sleep .

//Пример работы функций SuspendThread, ResumeThread и Sleep program SuspendThreadd; {$APPTYPE CONSOLE} uses SysUtils, Windows; var nCount: Cardinal = 0; dwCount: DWORD; hThread: HWND; IDThread: DWORD; c: Char; b: Boolean = True; procedure thread; stdcall; begin while b do begin nCount:= nCount + 1; Sleep(100); // приостанавливаем поток на 100 миллисекунд end; end; begin hThread:= CreateThread(nil, 0, @thread, nil, 0, IDThread); while b do begin Writeln("Input:"); Writeln(#9, """n"" to exit"); Writeln(#9, """y"" to display the count"); Writeln(#9, """s"" to suspend thread"); Writeln(#9, """r"" to resume thread"); Readln(c); case c of "n": Break; "y": Writeln("count = ", nCount); "s": begin //приостанавливаем поток thread dwCount:= SuspendThread(hThread); Writeln("Thread suspend count = ", dwCount); end; "r": begin //возобнавляем поток thread dwCount:= ResumeThread(hThread); Writeln("Thread suspend count = ", dwCount); end; end; end; //прерываем выполнение потока thread TerminateThread(hThread, 0); //закрываем дескриптор потока CloseHandle(hThread); end.

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

function GetCurrentThread : THandle; stdcall;

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

В листинге 1.4 приведен пример программы, которая вызывает функцию GetCurrentThread , а затем выводит на консоль полученный псевдодескриптор.

//Пример работы функции GetcurrentThread program GetCurrentThreadd; {$APPTYPE CONSOLE} uses SysUtils, Windows; var hThread: HWND; begin // получаем псевдодескриптор текущего потока hThread:= GetCurrentThread; // получаем псевдодескриптор текущего потока Writeln(hThread); Readln; end.

Большинство функций Win32 API возвращают код, по которому можно определить, как завершилась функция: успешно или нет. Если функция завершилась неудачей, то код возврата обычно равен false , nil или -1. В этом случае функция Win32 API также устанавливает внутренний код ошибки, который называется кодом последней ошибки (last-error code) и поддерживается отдельно для каждого потока. Чтобы получить код последней ошибки, нужно вызвать функцию GetLastError , которая имеет следующий прототип:

function GetLastError : DWORD; stdcall;

Эта функция возвращает код последней ошибки, установленной в потоке. Установить код последней ошибки в потоке можно при помощи функции SetLastError , имеющей следующий прототип:

procedure SetLastError (
dwErrCode: DWORD //код ошибки
); stdcall;

Чтобы получить сообщение, соответствующее коду последней ошибки, необходимо использовать функцию FormatMessage , которая имеет следующий прототип:

function FormatMessage (
dwFlags: DWORD; // режимы форматирования
lpSource: Pointer; // источник сообщения
dwMessageId: DWORD; // идентификатор сообщения
dwLanguageId: DWORD; // идентификатор языка
lpBuffer: PChar; // буфер для сообщения
nSize: DWORD; // максимальный размер буфера для сообщения
Arguments: Pointer // список значений для вставки в сообщение
): DWORD; stdcall;

В листинге 1.5 приведен пример программы, которая вызывает функцию FormatMessage

Program ErrorMessageBoxx; {$APPTYPE CONSOLE} uses SysUtils, Windows; var hHandle: THandle; procedure ErrorMessageBox; var lpMsgBuf: PChar; begin FormatMessage(FORMAT_MESSAGE_ALLOCATE_BUFFER or FORMAT_MESSAGE_FROM_SYSTEM or FORMAT_MESSAGE_IGNORE_INSERTS, nil, GetLastError, 0, @lpMsgBuf, 0, nil); MessageBox(0, lpMsgBuf, "Error Win32 API", MB_OK or MB_ICONINFORMATION); //Освободить буфер LocalFree(Integer(lpMsgBuf)); end; //тест для функции вывода сообщения об ошибке на консоль begin hHandle:= 0; //неправильный вызов функции закрытия дескритптора if not CloseHandle(hHandle) then ErrorMessageBox; end.

Исходный код скачать . Выполнен на Delphi XE.

Используемая литература: Александр Побегайло "Системное программироввние в Windows"

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

Потоки

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

Текстовые потоки

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

Двоичные потоки

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

Файлы

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

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

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

Файл отсоединяется от определенного потока (т.е. разрывается связь между файлом и потоком) с помощью операции закрытия . При закрытии файла, открытого с целью вывода, содержимое (если оно есть) связанного с ним потока записывается на внешнее устройство. Этот процесс, который обычно называют дозаписью потока, гарантирует, что никакая информация случайно не останется в буфере диска. Если программа завершает работу нормально, т.е. либо main() возвращает управление операционной системе, либо вызывается exit() , то все файлы закрываются автоматически. В случае аварийного завершения работы программы, например, в случае краха или завершения путем вызова abort() , файлы не закрываются.

У каждого потока, связанного с файлом, имеется управляющая структура, содержащая информацию о файле; она имеет тип FILE . В этом блоке управления файлом никогда ничего не меняйте .

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

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

Рассмотрев методы сжатия, объединения, кэширования и создания параллельных соединений, разумно было бы заняться следующим вопросом: Какая часть страницы должна загружаться вместе с основным 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.

Номер шага	Описание	Общий размер (кб)	Время загрузки (мс)
1	Обычная страница. Ничего не сжато (только html отдается через gzip)	63	117
2	HTML/CSS файлы и картинки минимизированы	58	108
3	Один-единственный файл. Картинки вставлены через data:URI	49	104
4	HTML-файл параллельно загружает 6 частей с данными и собирает их на клиенте	49	233
4.5	HTML-файл загружает 4 iframe	49	205
5	Вариант #3, только JPEG-изображения (примерно одинаковые по размеру) вынесены в файлы и загружаются через (new Image()).src в head странице	49	98

Таблица 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-движки — лучше оптимизированными), чтобы такие методы заработали. Сейчас же выбор один — алгоритмическое кэширование.

Суть проблемы.

Ваше запущенное приложение в какой то момент начинает активно грузить CPU, вас зовёт тестер и просит починить это!

Какие обычные действия программистов в таком случае?

• Просят локализовать, если получается, то решить проблему вопрос времени.
• Начинается добавление логов, счетчиков проходов и тому подобного. Все отдается тестеру или заказчику с требованием воспроизвести и вернуть лог на анализ. Хорошо если воспроизвести удастся и все станет ясно.
• Предположить время, когда "все работало" и по изменениями в системе контроля версий искать возможные причины.

Как проще поступить вэтом случае?

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

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

Для демонстрации я запустил свое приложение с именем процесса "Qocr.Application.Wpf.exe ", в которое добавил фейковый код бесконечного цикла . Теперь давайте найдём причину загрузки ядра без отладчика . Для этого я иду в ствойства процесса, далее:

1. Переходим на вкладку Threads и видим, что имеется 1 поток, который грузит на 16% CPU .
2. Выделяем этот поток и жмем Stack, открылось окно "Stack for thread ID ".
3. В окне видим, что наш поток был создан тут Qocr.Application.Wpf.exe!<>c. b__36_1+0x3a и в данный момент вызывает GetDirectories из метода InitLanguages().

Продемонстрирую действия выше на изображении со стрелками:

Открыв исходный код программы и перейдя к методу InitLanguages можно увидеть мой фейковый код. Зная эту информацию, а именно место отстановки, можно уже принимать меры.

Код стека (из примера выше) вызывающий бесконечный цикл (Можно проверить):

Private void InitLanguages() { new Thread (() => { while (true ) { var dir = Directory .GetDirectories(@"C:\" ); } ; }).Start(); }

Ложка дегтя в бочке с медом.

Два момента, которые стоит знать, если решите воспользоваться способом выше:

1. Потоки созданные CLR (созданные в коде .NET приложения) после останова не продолжают выполнение. В результате чего поток останавливается и остается висеть до перезапуска программы.
2. Если стек исполнения не содержит полезной информации, то стоит проделать остановку и просмотр стека несколько раз. Вероятность наткнуться на место зацикливания очень велика.

5.6. Уплотняем поток загрузки

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

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

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

Из книги Разгони свой сайт автора Мациевский Николай

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

Из книги Iptables Tutorial 1.1.19 автора Andreasson Oskar

Из книги ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ ВСТРОЕННЫХ СИСТЕМ. Общие требования к разработке и документированию автора Госстандарт России

Из книги Linux для пользователя автора Костромин Виктор Алексеевич

2.4.3. Варианты загрузки Итак, на мой взгляд, выбор варианта загрузки производится следующим образом: Если у вас установлена Windows NT или Windows 2000, то используйте NT Loader. Если у вас стоит Windows 95 или Windows 98 на FAT16, и вы не хотите ставить программу-загрузчик из другой ОС или от

Из книги 200 лучших программ для Интернета. Популярный самоучитель автора Краинский И

8.2. Процедура загрузки ОС Linux Для начала надо отметить, что все, о чем будет рассказано в этом разделе, относится к дистрибутиву Red Hat и его аналогам. В других дистрибутивах (например, Debian) процедуры загрузки могут быть организованы иначе.

Из книги Asterisk™: будущее телефонии Второе издание автора Меггелен Джим Ван

Менеджеры загрузки Ничто так не раздражает пользователя Интернета, как медленная скорость загрузки. Решать эту проблему можно по-разному. Можно использовать различные браузеры и выбрать самый быстрый или накопить денег и купить дорогой модем, который будет уверенно

Из книги TCP/IP Архитектура, протоколы, реализация (включая IP версии 6 и IP Security) автора Фейт Сидни М

Протокол, используемый для загрузки Телефоны Polycom могут загружать свою конфигурацию по одному из трех протоколов: TFTP, HTTP и FTP.Сразу же хотим попросить избегать TFTP. Он не обеспечивает необходимой безопасности, и телефон не может использовать информацию о дате для

Из книги Самоучитель работы на Macintosh автора Скрылина Софья

11.11 Параметры загрузки Параметры таблицы 11.1 могут содержаться в ответах протоколов BOOTP или DHCP, а параметры таблицы 11.2 могут использоваться только в DHCP.Таблица 11.2 Параметры DHCP Дополнительные параметры только для DHCP Requested IP Address (запрошенный IP-адрес) Клиент запросил

Из книги Первые шаги с Windows 7. Руководство для начинающих автора Колисниченко Денис Н.

4.1.6. Папка Загрузки Нажатие на кнопку Сохранить (Save), расположенную в заголовке письма, приводит к автоматическому сохранению прикрепленных файлов в папке Загрузки (Downloads), которая находится в домашней папке пользователя (рис. 4.21). Ее можно открыть, как любую папку, в окне

Из книги Linux: Полное руководство автора Колисниченко Денис Николаевич

2.4.4. Включение загрузки с DVD Чтобы загрузиться с установочного диска Windows, нужно изменить порядок загрузки в BIOS Setup (чтобы система загружалась с DVD, а не с жесткого диска). В случае со стационарным компьютером для входа в BIOS Setup обычно достаточно нажать клавишу сразу,

Из книги Adobe Flash. Создание аркад, головоломок и других игр с помощью ActionScript автора Розенцвейг Гэри

9.1.2. Продолжение загрузки. Демон initС момента загрузки ядра процесс начальной загрузки системы идет под управлением самой системы. Первой получает управление процедура автозапуска ядра. Она определяет объем доступной оперативной памяти, тип и быстродействие процессора,

Из книги Как раскрутить и разрекламировать Web-сайт в сети Интернет автора Загуменов Александр Петрович

Экран загрузки Хотя вы всегда должны стремиться, чтобы размер готового файла был минимальным, у вас наверняка будут ролики, загрузка которых займет больше, чем несколько секунд при работе через модем. Если игра имеет размер в сотни килобайт, у некоторых пользователей ее

Из книги Linux глазами хакера автора Флёнов Михаил Евгеньевич

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

Из книги Windows 10. Секреты и устройство автора Алмаметов Владимир

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

Из книги автора

10.3.2. Контроль загрузки файлов Загрузка файлов - самая опасная возможность для сервера. Каждый пользователь должен иметь право обращаться только к своей директории. А что делать, чтобы анонимные пользователи тоже могли работать с файлами? В этом случае нужно по