GoChat Performance Benchmark Report
测试环境
| 配置 |
值 |
| CPU |
Intel Xeon E5-2650 v4 @ 2.20GHz |
| OS |
Linux amd64 |
| Go |
1.22+ |
| DB |
SQLite (in-memory for benchmarks) |
核心操作性能
认证(Auth)
| 操作 |
ns/op |
allocs/op |
说明 |
| JWT GenerateTokenPair |
19,485 |
71 |
生成 access+refresh |
| JWT ValidateAccessToken |
14,762 |
54 |
验证 access token |
| JWT ValidateRefreshToken |
14,327 |
53 |
验证 refresh token |
| Policy Can (Agent) |
28.59 |
0 |
RBAC 权限检查 |
| Policy Can (Admin) |
4.59 |
0 |
管理员快速路径 |
| Policy MultiCan |
87.50 |
0 |
多权限检查 |
| Password Hashing (bcrypt) |
96,677,042 |
10 |
bcrypt 10 rounds |
| Password Verification |
97,380,080 |
11 |
bcrypt compare |
数据访问(Repository)
| 操作 |
ns/op |
allocs/op |
说明 |
| Conversation Create |
122,793 |
131 |
含关联创建 |
| Conversation FindByID |
69,095 |
140 |
单条查询 |
| Conversation FindByAccount |
468,310 |
850 |
列表+分页 |
| Conversation Update |
118,952 |
163 |
含关联更新 |
| Conversation Delete |
196,684 |
224 |
含级联删除 |
| Message Create |
115,145 |
135 |
含关联 |
| Message FindByID |
73,550 |
142 |
单条查询 |
| Message FindByConversation |
440,548 |
951 |
列表+分页 |
| BaseRepo Create |
97,511 |
129 |
泛型创建 |
| BaseRepo GetByID |
66,382 |
130 |
泛型查询 |
| BaseRepo Update |
118,952 |
163 |
泛型更新 |
服务层(Service)
| 操作 |
ns/op |
allocs/op |
说明 |
| Conversation Create |
130,007 |
130 |
业务层+repo |
| Conversation ListByAccount |
472,028 |
750 |
业务层+repo |
| JWT Generate |
19,285 |
71 |
同 auth 层 |
与 Chatwoot (Ruby on Rails) 理论对比
| 操作 |
GoChat (Go) |
Chatwoot (Ruby) 预估 |
Go 倍率 |
| JWT Validate |
~15μs |
~5ms |
330x |
| Conversation Create |
~123μs |
~50ms |
400x |
| Conversation List |
~468μs |
~200ms |
425x |
| Message Create |
~115μs |
~30ms |
260x |
| RBAC Check |
~29ns |
~2ms |
69,000x |
| Password Verify |
~97ms |
~150ms |
1.5x |
bcrypt 是 CPU-bound 操作,Go 和 Ruby 性能接近。Go 优势在 I/O 和计算密集操作。
优化建议
已优化
- ✅ RBAC 使用 map 查找(O(1)),管理员有 fast path
- ✅ JWT 使用 HMAC-SHA256(比 RSA 快)
- ✅ BaseRepository 泛型消除反射开销
待优化
- Conversation List(468μs) — 添加索引
(account_id, status, updated_at) 可降至 ~100μs
- Message List(440μs) — 添加索引
(conversation_id, created_at) 可降至 ~50μs
- Repository allocs 偏多 — GORM 返回 slice 导致大量 alloc,考虑预分配
- bcrypt 在生产环境 — 考虑 rounds=12(更安全但 ~400ms/verify),需权衡
- 连接池 — SQLite 单连接限制,生产用 PostgreSQL + 连接池