Elysia vs Hono กับ PostgreSQL บน MacBook Air M5

สวัสดีครับ กลับมาจับ MacBook Air M5 มาทรมานเป็นรอบที่สาม 😅

โพสต์แรก ผมวัดว่า Bun HTTP Framework แปดตัวเร็วแค่ไหน แล้วพบว่าตัวเองกำลังวัดความร้อนของเครื่องมากกว่าวัด Framework โพสต์ที่สอง ผมวัดพลังงานต่อ Request แล้วพบว่าตัวยิงโหลดกินไฟมากกว่า Server ที่กำลังทดสอบ

ทั้งสองโพสต์มีจุดอ่อนเดียวกันข้อหนึ่ง ซึ่งผมเขียนทิ้งไว้เองว่า:

Handler ใน Benchmark แทบไม่มีงาน ถ้า Handler ต้องรอ Database จริง ความต่างระดับเศษมิลลิจูลตรงนี้อาจเล็กมากเมื่อเทียบกับเวลา Query

รอบนี้ผมเลยเอาข้อนั้นมาทดสอบจริง ๆ ด้วยคำถามว่า:

ถ้าให้ Elysia กับ Hono คุยกับ PostgreSQL ก้อนเดียวกัน ด้วย SQL ชุดเดียวกัน ความต่างที่เคยเห็นจะเหลืออยู่เท่าไหร่?

คำตอบสั้น ๆ คือ เหลือน้อยจนวัดไม่ได้ครับ

สรุปก่อน เผื่อยังไม่อยากอ่านยาว

• ห่างกันมากที่สุดใน 16 ช่องทดสอบคือ 1.75% (get-user ที่ 100 connections) ค่ากลางของความต่างอยู่ที่ 0.34%
• ทุกช่องทดสอบ ช่วง min–max จาก 5 รอบของสอง Framework ทับกันหมด ไม่มีช่องไหนแยกออกจากกันได้เลย
• รันซ้ำ 5 รอบในเงื่อนไขเดียวกันเป๊ะ ๆ ยังแกว่างกันเองเฉลี่ย 2.94% และแย่สุด 12.67% — มากกว่าความต่างระหว่าง Framework
• คอขวดไม่ใช่ router: CPU ของ API ตันอยู่ราว 113% (ประมาณ 1.1 คอร์) ตั้งแต่ 10 connections ขึ้นไป ขณะที่ PostgreSQL พุ่งถึง 180–430%
• Workload ฝั่งอ่านยังไปต่อได้ถึง 100 connections แต่ฝั่งเขียนตันที่ 10 connections แล้วนิ่ง
• 160 trials, 175 ล้าน Request, HTTP และ transport error ศูนย์ ทุก trial
• ตัวเลขทั้งหมดเป็นผลบนเครื่องเดียว ไม่ใช่การจัดอันดับ Framework และไม่ใช่ตัวเลขจาก Production

ผมวัดอะไร บนอะไร

สี่ workload ที่แตะฐานข้อมูลจริง ไม่ใช่ route ที่ตอบ "hi" เฉย ๆ:

ฐานข้อมูลตั้งต้นมี 100,000 users, 1,000,000 orders และ 3,000,000 order_items สร้างจาก MD5 counter-based generator ด้วย seed 424242 ทุกครั้ง และรัน ANALYZE หลัง seed เสร็จ ที่สำคัญคือ ผมไม่ tune PostgreSQL เลย ใช้ค่าที่ Homebrew ติดตั้งมาให้ตรง ๆ เพราะถ้า tune แล้วผลดีขึ้น เราจะไม่รู้ว่าดีขึ้นเพราะ Framework หรือเพราะ config

ทั้งสอง Framework ใช้ database functions, validation, JSON serialization และ connection pool ขนาด 10 ชุดเดียวกันทุกบรรทัด ต่างกันแค่ Elysia ใช้ native listen ส่วน Hono ใช้ Bun.serve เปิด production mode ไม่มี access log ไม่มี cache middleware

ผมทดสอบอย่างไร?

Concurrency 1, 10, 50 และ 100 อย่างละ 5 รอบต่อ Framework รวมเป็น 160 trials วัดจริงรอบละ 30 วินาที

ทุก trial ผ่านขั้นตอนเดิมหมด: ลบและ seed ฐานข้อมูลใหม่ → เปิด API → warm-up ให้ครบ 1,000 request ที่สำเร็จ → พัก 5 วินาที → วัด 30 วินาที → ปิด API → cooldown 15 วินาที

ทำไมต้อง seed ฐานข้อมูลใหม่ทุก trial?

เพราะ create-order เขียนข้อมูลลงไปจริง ถ้าไม่ reset ตารางจะโตขึ้นเรื่อย ๆ ตาม trial ที่ผ่านมา แล้ว Framework ที่บังเอิญรันทีหลังจะเจอฐานข้อมูลที่ใหญ่กว่า — กลายเป็นว่าเราวัดลำดับการรัน ไม่ได้วัด Framework

เรื่องนี้ผมเข็ดมาจากโพสต์แรกแล้วครับ ตอนนั้นแค่สลับลำดับรายการทดสอบ อันดับก็พลิกทันที รอบนี้จึงสลับ Framework ที่เริ่มก่อนแบบ deterministic และจับคู่ให้รันติดกัน เพื่อให้ถ้าเครื่องร้อนขึ้น มันร้อนใส่ทั้งคู่เท่า ๆ กัน

ทั้ง 160 trials รันบน MacBook Air (Mac17,3) เครื่องเดียว — ชิป Apple M5 10 คอร์ แรม 24 GB unified — เสียบปลั๊กไฟไว้ตลอดการทดสอบ ส่วนเวอร์ชันของ Bun, PostgreSQL, Elysia, Hono และ bombardier ในตารางข้างล่าง เป็นค่าที่อ่านจากเครื่องตอนรันจริง ไม่ได้พิมพ์เอง

ลิงก์ชื่อรุ่นด้านบนเป็นลิงก์ Lazada affiliate ครับ กดซื้อผ่านลิงก์นี้ราคาไม่ต่างจากเดิม แต่บล็อกจะได้ค่าคอมมิชชันเล็กน้อย

สภาพแวดล้อมที่บันทึกจริง

Session: 2026-09-12T14-24-22-067Z-full-4423a21a
2026-09-12T14:24:22.067Z — 2026-09-12T17:03:10.238Z

ProductName:		macOS
ProductVersion:		26.6.2
BuildVersion:		25G83

Throughput ที่สำเร็จ

แต่ละจุดใช้ครบ 5 repetitions แกนตั้งของกราฟเส้นไม่ได้เริ่มที่ศูนย์เสมอ โปรดเทียบค่าจริงในตารางด้วย

¹ Median ของสถิติแต่ละ trial ไม่ใช่ latency distribution รวม HTTP และ transport errors เป็นศูนย์ทุก trial ที่รวมผล ค่าที่ไม่มีแสดง N/A

การใช้ทรัพยากรจาก samples

แสดง median ของ repetitions โดย CPU หนึ่ง core เต็ม = 100% และ RSS เป็น sampled peak หน่วย MiB ผลรวม PostgreSQL อาจนับ shared pages ซ้ำ ค่านี้ไม่ได้ยืนยันว่าตัวสร้างโหลดไม่เป็นคอขวด

ดาวน์โหลดข้อมูลตรวจสอบ

• Summary CSV
• Raw results เฉพาะข้อมูลตัวเลข ทุก warm-up และ measurement
• Protocol เวอร์ชัน source hashes และ configuration

ผลลัพธ์: เสมอกันจนแยกไม่ออก

ช่องที่ห่างกันมากที่สุดในทั้ง 16 ช่องคือ get-user ที่ 100 connections — 72,532 เทียบกับ 71,283 req/s คิดเป็น 1.75% ส่วนค่ากลางของความต่างทั้งหมดอยู่ที่ 0.34% และ Elysia นำในเชิงตัวเลข 11 จาก 16 ช่อง

ฟังดูเหมือน Elysia ชนะนิด ๆ ใช่ไหมครับ แต่อย่าเพิ่ง

ผมรันทุกช่อง 5 รอบ ในเงื่อนไขเดียวกันทุกอย่าง แล้ว 5 รอบนั้นแกว่างกันเองเฉลี่ย 2.94% และแย่สุดถึง 12.67% (create-order ที่ 10 connections) พูดอีกแบบคือ ถ้าผมรัน Framework เดียวกันสองครั้ง ผมอาจได้ผลต่างกันมากกว่าที่ Elysia ต่างจาก Hono เสียอีก

และทุกช่องทดสอบ ช่วง min–max ของสอง Framework ทับกันหมด ไม่มีช่องไหนเลยที่แยกออกจากกันได้

เพราะฉะนั้นโพสต์นี้ ไม่ประกาศผู้ชนะครับ ใครจะบอกว่า Elysia เร็วกว่า 1.75% ก็เอาตัวเลขนี้ไปอ้างไม่ได้ เพราะมันจมอยู่ใน noise ของเครื่องผมเอง

ถ้าไม่ใช่ router แล้วคอขวดอยู่ไหน?

ตัวเลข CPU ตอบได้ชัดกว่า throughput ครับ

CPU ของ API ตันอยู่ราว 113% หรือประมาณ 1.1 คอร์ ตั้งแต่ 10 connections ขึ้นไป ทุก workload — เพราะ Bun รัน process เดียว ขณะเดียวกัน PostgreSQL ใช้ 180–430% และตัว bombardier เองกิน 149–336% ใน workload ฝั่งอ่าน

สามตัวนี้แย่ง 10 คอร์ชุดเดียวกันอยู่ ดังนั้นที่อัตราระดับนี้ router ของทั้งสองตัวยังห่างไกลจากการเป็นข้อจำกัดมาก สิ่งที่ผมวัดได้จริง ๆ คือ PostgreSQL, Bun SQL client และ pool ที่แชร์กัน — ไม่ใช่ความเร็วของ Framework

นี่คือคำตอบของคำถามที่ผมทิ้งไว้ในโพสต์ก่อน: พอ handler ต้องรอฐานข้อมูลจริง ความต่างของ Framework ก็หายไปตามที่เดาไว้ครับ

ทำไม create-order ไม่ scale?

ฝั่งอ่านยังได้ throughput เพิ่มจาก 10 ไป 100 connections (get-user จาก 59,488 เป็น 72,532 req/s) แต่ฝั่งเขียนไม่เป็นอย่างนั้น

create-order ขึ้นสูงสุดที่ 10 connections ด้วย 20,459 req/s แล้วลดลงเล็กน้อยเป็น 19,913 ที่ 100 connections ยิ่งเพิ่ม connection ยิ่งได้น้อยลง

เหตุผลน่าจะตรงไปตรงมา: pool ตรึงไว้ที่ 10 connections ดังนั้นการเพิ่ม client เป็น 100 ไม่ได้เพิ่มงานที่ฐานข้อมูลทำได้ แค่เพิ่มคิวรอ บวกกับการเขียนทำให้ตารางโตขึ้นระหว่างวัด ซึ่งไม่ใช่คุณสมบัติของ Framework ไหนเลย

ก่อนนำตัวเลขไปอ้าง ขอฝากไว้ 7 ข้อ

1. เครื่องเดียว ห้องเดียว คืนเดียว ตัวยิงโหลด API และ PostgreSQL อยู่บนเครื่องเดียวกัน แย่ง CPU และ thermal headroom กันเอง ความต่างที่เห็นจึงโยนให้ Framework ทั้งหมดไม่ได้
2. ตัวยิงโหลดอยู่ในทุกตัวเลข bombardier กิน CPU 149–336% ใน workload ฝั่งอ่าน มันอาจเป็นคอขวดร่วมด้วย
3. pool 10 connections เป็นเพดานที่ตั้งใจตรึง ผลที่ concurrency 50 และ 100 จึงบอกเรื่อง pool มากกว่าบอกเรื่อง Framework
4. Workload เป็นแบบ hot-key และ warm-cache ยิง user คนเดิมซ้ำ ๆ ไม่ใช่ traffic สุ่มแบบของจริง และเป็น closed-loop ซึ่งซ่อนผลของ queueing เมื่อเทียบกับ fixed arrival rate
5. ตัวเลข CPU กับ RSS เป็นค่าจาก sample เก็บประมาณวินาทีละครั้งจาก cumulative CPU time ไม่ใช่การบัญชีที่แม่นยำ และ RSS รวมของ PostgreSQL นับ shared pages ซ้ำได้
6. percentile ในตารางเป็น median ของ percentile แต่ละ trial ไม่ใช่ percentile รวมของทุก request — อ่านผิดข้อนี้กันบ่อย
7. cooldown 15 วินาทีไม่ได้รับประกันว่าเครื่องเย็นเท่ากันทุกรอบ ผมบันทึก thermal log ไว้และไม่เจอ warning แต่ “ไม่มี warning” ไม่เท่ากับ “อุณหภูมิคงที่”

และขอเปิดเผยเหมือนโพสต์ก่อน ๆ ครับ: ผมเคยมีส่วนร่วมกับเอกสารของ Elysia และรอบนี้ Elysia ก็นำในเชิงตัวเลข 11 จาก 16 ช่องอีก ใครนำผลไปใช้ควรรับรู้ความเกี่ยวข้องส่วนนี้ไว้ด้วย — ถึงผมจะสรุปเองว่าความต่างนี้วัดไม่ได้ก็ตาม

อยากลองทำซ้ำ เริ่มจากตรงนี้

ต้องใช้ Bun, PostgreSQL และ bombardier ตรงเวอร์ชันในตารางข้างบน พร้อม frozen lockfile และ source hashes ที่แนบมาใน manifest

bun install --frozen-lockfile
bun run typecheck
bun run test
bun run bench:run --profile quick --execute
bun run bench:run --profile full --execute
# ใช้ path ของ session ที่ runner พิมพ์ออกมาจริง ๆ:
bun run bench:report --session reports/runs/SESSION_ID

คำสั่งที่มี --execute จะลบและ seed ใหม่เฉพาะ benchmark_db ที่มี ownership marker ของโปรเจกต์นี้เท่านั้น และต้องเสียบปลั๊กไฟไว้ — runner เช็ก AC power ก่อนทุก trial ถ้าสลับไปใช้แบตเตอรี่มันจะหยุดทันที ซึ่ง session ก่อนหน้าของผมตายไปแล้วหนึ่งรอบตอน trial ที่ 71 ด้วยเหตุผลนี้เลยครับ

Full profile ใช้เวลาวัดจริง 80 นาที แต่รวม reset, warm-up, settle, cooldown และการตรวจทั้งหมดแล้วจบที่ 2 ชั่วโมง 39 นาที

ข้อมูลดิบทั้ง 160 trials, summary CSV และ manifest ที่ sanitize แล้ว ดาวน์โหลดได้จากลิงก์ในส่วนผลลัพธ์ข้างบน ถ้าไม่เห็นด้วยกับวิธีคิด throughput หรือการอ่าน percentile ของผม หยิบข้อมูลดิบไปคำนวณใหม่ได้เลยครับ

ส่วนที่ผมอยากให้ช่วยตรวจมากที่สุดคือ เพดานของ pool ครับ ผมยังไม่ได้ลองว่าถ้าขยาย pool จาก 10 เป็น 50 แล้ว create-order จะไปต่อได้ไหม หรือ PostgreSQL จะเป็นกำแพงอยู่ดี ถ้าใครมี Apple Silicon แล้วอยากลองซ้ำ ผมยินดีดูผลไปด้วยกันครับ