คำนวณขนาด Thread Pool
คำนวณขนาด thread pool ด้วย N = cores x (1 + W/C): พรีเซ็ต IO-bound/CPU-bound, อัตราส่วน wait/compute และ config executor สำหรับ Java และ Python
Loading tool...
คำนวณขนาด Thread Pool คืออะไร?
Thread Pool Size Calculator ใช้สูตรคลาสสิก N = cores x (1 + W/C) กับ workload จริงของคุณ: ใส่จำนวนคอร์, target utilization และเวลารอเทียบเวลาคำนวณเฉลี่ย แล้วได้ขนาด pool ที่แนะนำพร้อม config executor พร้อมวางสำหรับ Java, virtual threads และ Python
ประโยชน์หลัก
- ได้ขนาด pool ที่พอดี แทนการเดาจำนวน thread
- พรีเซ็ต IO-bound และ CPU-bound ฝังค่า default ที่พิสูจน์แล้ว
- config executor สำเร็จรูปลด boilerplate ตอนตั้งค่า
- validation กัน input ที่ไม่สมเหตุสมผลอย่างเวลาติดลบ
- คณิตฝั่ง client ทันทีและเป็นส่วนตัว
กรณีการใช้งาน
- •ปรับ worker pool ของ web server หรือ API ตาม latency profile ที่รู้จัก
- •ตั้งค่า worker งานเบื้องหลังสำหรับ task ที่ผูกกับ database
- •ตัดสินใจระหว่าง fixed pool กับ virtual หรือ async threads
- •สอนการไซซ์ concurrency ด้วยสูตรมาตรฐาน
วิธีคำนวณขนาด Thread Pool
- เลือกพรีเซ็ต: เริ่มจากพรีเซ็ต IO-bound หรือ CPU-bound หรือกำหนดค่าเองตาม workload ของคุณ
- ปรับตัวเลข: ใส่จำนวนคอร์จริง, target utilization และเวลารอกับเวลาประมวลผลเฉลี่ยต่อ task
- คัดลอก config: คัดลอกขนาด pool ที่แนะนำไปใส่ executor config ของ Java, virtual threads หรือ Python
คุณสมบัติหลัก
- สูตรคลาสสิก N = cores x (1 + W/C) พร้อมอัตราส่วน W/C แบบสด
- พรีเซ็ต IO-bound (utilization 90%, รอหนัก) และ CPU-bound (เต็มคอร์)
- config executor คัดลอกได้สำหรับ Java, virtual threads, Python และ Node
- ตรวจจำนวนคอร์ ช่วง utilization และเวลาติดลบ
- คำนวณใหม่ทันทีทุกครั้งที่แก้ค่า
- คณิตฝั่ง client ล้วน - เป็นส่วนตัวและฟรี
คำถามที่พบบ่อย
สูตร N = cores x (1 + W/C) แปลว่าอะไร?
มันขยายจำนวนคอร์ตามสัดส่วนเวลาที่ task รอเทียบกับประมวลผล task ที่รอ 100 ms และคำนวณ 100 ms มี W/C = 1 เครื่อง 4 คอร์จึงทำงานเต็มประสิทธิภาพด้วย 8 threads
ควรใช้พรีเซ็ต CPU-bound เมื่อไร?
เมื่อ task เป็นงานคำนวณหนักและแทบไม่บล็อก - ประมวลผลรูป บีบอัด คณิตศาสตร์ thread เกินจำนวนคอร์จะเพิ่มแต่ overhead ของ context switch
ทำไม pool ฝั่ง IO-bound ถึงใหญ่มาก?
task แบบ IO-bound ใช้ชีวิตส่วนใหญ่รอ socket ดิสก์ หรือ API thread เพิ่มช่วยให้ CPU ทำงานต่อขณะตัวอื่นรอ pool จึงขยายตามอัตราส่วน wait/compute
แล้ว virtual threads (Java 21+) หรือ async runtime ล่ะ?
virtual threads และ async runtime ทำให้การไซซ์ platform pool แทบไม่จำเป็นสำหรับงาน IO-bound - หนึ่ง virtual thread ต่อ task ดีกว่า สูตรนี้ยังใช้กับ platform threads และ worker pool ปกติ