Как Echo достигает высокой производительности HTTP-маршрутизации?

Как работает radix tree

В обычном trie каждый узел хранит один символ. В radix tree узел хранит целую строку-префикс, что уменьшает глубину дерева. Поиск маршрута выполняется за O(k), где k — длина URL, независимо от количества зарегистрированных маршрутов.

// При регистрации этих маршрутов Echo строит radix tree:
e.GET("/", handler)
e.GET("/users", handler)
e.GET("/users/:id", handler)
e.GET("/users/:id/posts", handler)
e.GET("/products", handler)
e.GET("/products/:id", handler)

// Дерево выглядит примерно так:
// root
// ├── "/" → handler
// ├── "users" → handler
// │   └── "/:id" → handler
// │       └── "/posts" → handler
// └── "products" → handler
//     └── "/:id" → handler

Маршрутизатор Echo: radix tree

Echo использует структуру данных radix tree (сжатое префиксное дерево, также известное как Patricia trie) для хранения и поиска маршрутов. Это ключевой элемент, который обеспечивает высокую производительность по сравнению с линейным перебором маршрутов.

Нулевые аллокации на горячем пути

Echo реализован так, чтобы не аллоцировать память при обработке большинства запросов. Объекты echo.Context берутся из sync.Pool и возвращаются туда после обработки запроса:

// Из исходного кода Echo (упрощённо)
func (e *Echo) ServeHTTP(w http.ResponseWriter, r *http.Request) {
	// Берём Context из пула — нет аллокации
	c := e.pool.Get().(*context)
	c.Reset(r, w)

	// Ищем обработчик в radix tree
	h := e.findRouter(r.Host).Find(r.Method, getPath(r), c)

	// Выполняем обработчик
	if err := h(c); err != nil {
		e.HTTPErrorHandler(err, c)
	}

	// Возвращаем Context в пул
	e.pool.Put(c)
}

Benchmark-сравнение (иллюстративный пример)

// go test -bench=. -benchmem ./...
// Запуск собственного бенчмарка для проверки производительности:
package main

import (
	"net/http"
	"net/http/httptest"
	"testing"

	"github.com/labstack/echo/v4"
)

func BenchmarkEchoRouting(b *testing.B) {
	e := echo.New()
	e.GET("/users/:id", func(c echo.Context) error {
		return c.String(http.StatusOK, c.Param("id"))
	})

	req := httptest.NewRequest(http.MethodGet, "/users/42", nil)
	w := httptest.NewRecorder()

	b.ResetTimer()
	b.ReportAllocs()
	for i := 0; i < b.N; i++ {
		e.ServeHTTP(w, req)
	}
}
// Типичный результат: ~200 ns/op, 0 allocs/op

Приоритет маршрутов

Radix tree Echo разрешает конфликты по принципу: статические маршруты побеждают параметрические, параметрические — wildcard:

• /users/new — статический, приоритет выше
• /users/:id — параметрический
• /users/* — wildcard, наименьший приоритет

Виртуальные хосты

Echo поддерживает роутинг по Host-заголовку через e.Host(), создавая отдельное radix tree для каждого хоста:

// Отдельные деревья для каждого домена
api := e.Host("api.example.com")
api.GET("/users", listUsers)

www := e.Host("www.example.com")
www.GET("/", homePage)

Подводные камни

• Конфликт параметров одного уровня: нельзя зарегистрировать /users/:id и /users/:name одновременно — второй перезапишет первый без ошибки.
• Регистрация маршрутов после старта: добавление маршрутов после e.Start() не является потокобезопасным — регистрируйте все маршруты до запуска сервера.
• sync.Pool и горутины: echo.Context нельзя хранить после возврата обработчика — он уйдёт обратно в пул. Для асинхронных операций копируйте нужные данные из контекста.
• Wildcard и вложенные параметры: c.Param("*") содержит весь хвост URL включая слэши — не забывайте об этом при построении файловых путей.
• Метод OPTIONS: Echo автоматически обрабатывает OPTIONS для CORS только если включён соответствующий middleware — пустой OPTIONS без middleware вернёт 405.
• Производительность с большим числом маршрутов: при тысячах маршрутов время построения дерева при старте растёт, но время поиска остаётся постоянным.

• Давать ответ про производительность маршрутизации Echo только на уровне определения, не показывая поведение в реальном приложении.
• Игнорировать границы ответственности вокруг темы «производительность маршрутизации Echo»: кто отменяет работу, кто владеет ресурсом и где формируется ответ клиенту.
• Не связывать производительность маршрутизации Echo с observability, тестированием или безопасностью, когда это влияет на продакшен-поведение.

• Точно объясняет, что именно делает производительность маршрутизации Echo и где это используется в Go-коде.
• Связывает производительность маршрутизации Echo с корректным lifecycle запроса, отменой, конкурентностью или конфигурацией сервера там, где это уместно.
• Не изобретает API и опирается на реальные контракты официальной документации.