Какими способами можно измерить и оценить производительность транзакций в Go?

Ну слушай, смотри, как это всё работает на самом деле, а не в этих ваших книжках для распиздяев. Оценивать, насколько быстро твоя транзакция бегает — это ж целая наука, блядь. И подходы на стадии, когда ты в трусах кодишь, и когда это уже в бою работает — они, сука, как небо и земля!

1. Как померить, чтобы не обосраться

• Бенчмарки (Когда ты дома, в тапочках) Пока ты ещё не выкатил свою поделку на прод, можно поиздеваться над кодом в тишине. В Го для этого есть встроенная штука в testing. Запускаешь — и она тебе показывает, где твой код тормозит, как черепаха в сиропе.

  import "testing"
  
  // db - это ваше подключение к БД
  func BenchmarkCreateUserTransaction(b *testing.B) {
      b.ReportAllocs() // Эта штука покажет, сколько памяти ты бездарно просрал
      for i := 0; i < b.N; i++ {
          // Тут твоя священная бизнес-логика
          // типа tx, _ := db.Begin(); ...; tx.Commit()
      }
  }
  // Запускаешь: go test -bench=. и сидишь, охуевая от цифр

• Профилирование (Когда надо копнуть глубоко) А вот если бенчмарк показал, что всё хуёво, но не сказал — где именно, то тут в бой идёт pprof. Эта, блядь, волшебная палочка покажет тебе, какая функция жрёт процессор, как голодный студент доширак. Просто включаешь его — и он тебе вывалит всю подноготную, кто тут самый прожорливый.

• Мониторинг в бою (Когда уже всё летит в прод и падает) Вот это, ёпта, самое интересное. Когда твой код уже работает у живых людей, ты не можешь просто так воткнуть в него pprof и всё затормозить. Тут нужны метрики, которые тихо-мирно собираются. Царь и бог здесь — Prometheus. Чтобы засечь время транзакции, идеально подходит Histogram. Ставишь замер в начале и в конце — и вуаля, ты знаешь, сколько она длилась.

  // timer — это prometheus.NewTimer(yourHistogramVec)
  timer := prometheus.NewTimer(dbTransactionDuration.WithLabelValues("create_user"))
  defer timer.ObserveDuration() // Эта строчка запишет время, когда функция закончится
  
  // ... а тут твой код, который может и не закончиться, если накосячил...

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

2. На что смотреть, чтобы не облажаться

• Задержка (Latency): Не верь среднему арифметическому, ёпта! Это хуйня полная. Смотри на перцентили — p90, p99. Потому что если для 99% пользователей всё летает, а для одного процента — пиздец как долго, то этот один процент тебе всю репутацию и проебёт. Они же самые громкие!
• Пропускная способность (Throughput): Сколько транзакций в секунду твоя система может проглотить? Если это число меньше, чем приходит запросов — готовь таз, скоро будет фонтан из ошибок.
• Процент ошибок (Error Rate): Если каждая десятая транзакция отваливается — это пиздец, а не система. Надо срочно искать, кто тут всех подводит.
• Жрунство ресурсов: Твоя транзакция может быть быстрой, но при этом она так жрёт память и процессор, что остальные процессы голодают. Смотри за CPU, памятью и дисковым вводом-выводом. Если всё упирается в диск — ну, тут я тебе сочувствую, блядь.