Skip to content

Оптимизация производительности

Сравнение предустановок конфигурации

МетрикаDefaultSecurePerformanceMinimal
Таймаут Request180s15s60s180s
MaxIdleConns502010010
MaxConnsPerHost105202
MaxRetries3130
MaxResponseBodySize10MB5MB50MB1MB
HTTP/2ВклВклВклВкл
CookiesВыклВыклВклВыкл
Защита SSRFВклВклВклВкл
FollowRedirectsВклВыклВклВыкл

Выбор по сценарию

СценарийРекомендованная предустановкаРекомендации по настройке
Обычные веб-сервисыDefault-
Обработка URL от пользователейSecure-
Внутренние микросервисы с высокой нагрузкойPerformanceУвеличить MaxIdleConns
Одноразовые скриптыMinimal-
Сервис загрузки файловPerformanceУвеличить MaxResponseBodySize
Финансовые/медицинские APISecure + пользовательскаяДобавить промежуточное ПО аудита
go
// Сценарий высокой пропускной способности
client, _ := httpc.New(httpc.PerformanceConfig())

// Тонкая настройка на основе предустановки
cfg := httpc.PerformanceConfig()
cfg.Timeouts.Request = 120 * time.Second
cfg.Connection.MaxIdleConns = 200
client, _ := httpc.New(cfg)

Повторное использование пула объектов

Внутри HTTPC переиспользует объекты ответов движка и построители строк через sync.Pool, снижая нагрузку на GC; Result создаётся заново для каждого запроса и утилизируется GC:

go
result, err := client.Get(url)
if err != nil {
    return err
}
// Result создаётся заново для каждого запроса, утилизируется GC, ручное освобождение не требуется

TIP

В высоконагруженных сценариях повторное использование пула объектов значительно снижает нагрузку на GC.

Антипаттерны производительности

АнтипаттернПричинаПравильный подход
Создание клиента на каждый запросСоединения не переиспользуютсяГлобальное переиспользование клиента
Слишком большой MaxResponseBodySizeВысокое потребление памятиУстановите разумные ограничения
Использование result.String() на горячих путяхНакладные расходы на построение строкиИспользуйте Body() напрямую

Что дальше