TCP, HTTP и зона наилучшего восприятия многопоточности

Я пытаюсь понять показатели производительности, которые я получаю и как определить оптимальное количество потоков.

Посмотрите нижнюю часть этого сообщения для моих результатов

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

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

Общий объем загруженных данных составляет 2 271 122 байта в 1316 файлы через соединение на 2.5 Мбит из http://hubblesite.org/gallery/album/entire/npp/all/hires/true/. Изображения миниатюр размещаются компанией, которая утверждает, что специализировалась на низкой задержке для широкополосных приложений.

Стенные времена:

1 Поток занимает 4:48 - 0 тайм-аутов
2 Потока занимают 2:38 - 0 тайм-аутов
5 Потоков занимают 2:22 - 20 тайм-аутов
10 Потоков занимают 2:27 - 40 тайм-аутов
50 Потоков занимают 2:27 - 170 тайм-аутов

В худшем случае (50 потоков) меньше чем 2 секунды процессорного времени используются клиентом.

в среднем размер файла 1.7k
в среднем rtt 100 мс (как измеряется ping)
в среднем cli cpu/img 1 мс

Самая быстрая средняя скорость загрузки является 5 потоками на уровне приблизительно 15 КБ / секунда в целом.

Сервер на самом деле, кажется, имеет довольно низкую задержку, поскольку требуется только 218 мс для получения, каждое изображение, означающее это, берет только 18 мс в среднем, чтобы сервер обработал каждый запрос:

0 cli отправляет syn
50 srv rcvs syn
50 srv отправляют syn + ack
100 cli ведут установленный / cli, отправляет, добираются
150 srv recv's добираются
168 файлов чтений srv, отправляет данные, вызовы близко
218 cli recv HTTP-заголовки + завершают файл в 2 сегментах MSS == 1448

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

То, что я не понимаю, - то, почему я не вижу фактически улучшения производительности вне 2 потоков. Сервер, кажется, достаточно быстр, но уже начинает приводить к таймауту соединений в 5 потоках.

Тайм-ауты, кажется, запускаются приблизительно после 900 - 1000 успешных соединений, является ли это 5 или 50 потоками, которые я принимаю, вероятно, некоторый порог регулировки на сервере, но я ожидал бы, что 10 потоков все еще будут значительно быстрее, чем 2.

Я пропускаю что-то здесь?

РЕДАКТИРОВАНИЕ 1

Только для пользы сравнений я установил расширение DownThemAll Firefox и загрузил изображения с помощью него. Я установил его на 4 одновременных соединения с 10 вторыми тайм-аутами. DTM занял приблизительно 3 минуты для загрузки всех файлов +, пишут им в диск, и он также начал испытывать тайм-ауты приблизительно после 900 соединений.

Я собираюсь выполнить tcpdump, чтобы попытаться получить лучшее изображение, что продолжается на tcp протокольном уровне.

Я также очистил кэш Firefox и поразил перезагрузку. 40 Секунд для перезагрузки страницы и всех изображений. Это казалось слишком быстрым - возможно, Firefox сохранил их в кэше памяти, который не был очищен? Таким образом, я открыл Opera, и также потребовалось приблизительно 40 секунд. Я предполагаю, что они настолько быстрее, потому что они должны использовать конвейерную обработку HTTP/1.1?

И ответ!??

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

При достигании 5 потоков неконвейерная версия получает первые 1 026 изображений за 77 секунд, но занимает еще 65 секунд для получения оставления 290 изображениями. Это в значительной степени подтверждает теорию MattH о моем клиенте, поражаемом a SYN FLOOD событие, заставляющее серверу прекратить отвечать на мои попытки подключения в течение короткого промежутка времени. Однако это - только часть проблемы, так как 77 секунд являются все еще очень медленными, чтобы 5 потоков получили 1 026 изображений; если Вы удаляете SYN FLOOD проблема все еще потребовалось бы приблизительно 99 секунд для получения всех файлов. Таким образом на основе небольшого исследования и некоторых tcpdumpкажется, что другая часть проблемы является задержкой и установлением соединения наверху.

Вот то, куда мы возвращаемся к проблеме нахождения "Зоны наилучшего восприятия" или оптимального количества потоков. Я изменил клиент для реализации Конвейерной обработки HTTP/1.1 и нашел, что оптимальное количество потоков в этом случае между 15 и 20. Например:

1 Поток занимает 2:37 - 0 тайм-аутов
2 Потока занимают 1:22 - 0 тайм-аутов
5 Потоков занимают 0:34 - 0 тайм-аутов
10 Потоков занимают 0:20 - 0 тайм-аутов
11 Потоков занимают 0:19 - 0 тайм-аутов
15 Потоков занимают 0:16 - 0 тайм-аутов

Существует четыре фактора, которые влияют на это; задержка / rtt, максимальная сквозная пропускная способность, recv размер буфера и размер загружаемых файлов изображений. Обратитесь на этот сайт за обсуждением того, как получают размер буфера, и задержка RTT влияют на доступную пропускную способность.

В дополнение к вышеупомянутому средний размер файла влияет на максимальную скорость передачи для каждого подключения. Каждый раз Вы проблема a ПОЛУЧАЮТ запрос, Вы создаете пустой разрыв в своем канале передачи, который является размером соединения RTT. Например, если Вы - Максимальная Возможная Скорость передачи (recv размер, цвета буйволовой кожи / RTT) 2.5 Мбит, и Ваш RTT составляет 100 мс, затем каждый ПОЛУЧАТЬ запрос подвергается минимальному разрыву 32 КБ в Вашем канале. Для большого среднего размера изображения 320 КБ, который составляет 10% наверху на файл, эффективно уменьшая Вашу доступную пропускную способность до 2.25 Мбит. Однако для небольшого среднего размера файла 3.2 КБ служебные переходы к 1 000%-му и доступной пропускной способности уменьшается до 232 кбит / второй - приблизительно 29 КБ.

Таким образом найти оптимальное количество потоков:

Размер разрыва = MPTR * RTT
MPTR / (MPTR / Размер Разрыва + размер файла AVG) * размер файла AVG)

Для моего выше сценария это дает мне оптимальное количество потока 11 потоков, которое является чрезвычайно близко к моим результатам реального мира.

Если скорость фактического соединения медленнее, чем теоретический MPTR затем, это должно использоваться в вычислении вместо этого.