Редакция 1: очистка очевидного

  • Статья

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

Предупреждение

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

 

#include <windows.h>

BYTE Set(row, col, bAlive)
{
    SOCKET s = socket(...);
    BYTE byRet = 0;
    BYTE tmp[3];
    tmp[0] = (BYTE)row;
    tmp[1] = (BYTE)col;
    tmp[2] = (BYTE)bAlive;
    bind( s, ... );
    connect( s, ... );
    send( s, &tmp, 3 );
    recv( s, &byRet, 1 );
    closesocket( s );
    return byRet;
}

Изменения в этой версии

Эта версия отражает следующие изменения:

  • Удален SNDBUF=0. Задержки в 200 миллисекундах из-за небуферированных отправлений и отложенных подтверждений удаляются.
  • Удалено поведение send-Send-Receive. Это изменение устраняет задержки в 200 миллисекундах из-за nagle и задержки взаимодействия ACK.
  • Удалено маленькое предположение. Теперь байты находятся в порядке.

Оставшиеся проблемы

В этой версии остаются следующие проблемы:

  • Приложение по-прежнему интенсивно подключается. Так как задержки в 600 миллисекундах удаляются, приложение теперь достигает 12 подключений в секунду устойчивой скорости. Теперь многие параллельные подключения становятся проблемой.
  • Приложение все еще толстый; неизменяемые ячейки по-прежнему распространяются на сервер.
  • Приложение по-прежнему демонстрирует плохую потоковую передачу; 3-байтовые отправки по-прежнему небольшие.
  • Теперь приложение отправляет 2 байта/RTT, что равно 4 КБ/с на напрямую подключенном Ethernet. Это не слишком быстро, но TIME-WAIT, скорее всего, вызовет проблемы в первую очередь.
  • Накладные расходы снизились до 99,3%, что по-прежнему не является хорошим процентом накладных расходов.

Ключевые метрики производительности

Следующие ключевые метрики производительности выражаются в времени кругового пути (RTT), Goodput и протоколе. Описание этих терминов см. в разделе сетевой терминологии .

Эта версия отражает следующие метрики производительности:

  • Время ячейки — 2×RTT
  • Goodput — 2 байта/RTT
  • Издержки на протокол — 99,3 процента

Улучшение медленного приложения

Сетевая терминология

Базовая версия: очень низкопроизводительное приложение

Редакция 2. Изменение для меньшего числа подключений

Редакция 3. Отправка сжатого блока

Будущие улучшения