17 คะแนน โดย tsboard 2024-12-01 | 16 ความคิดเห็น | แชร์ทาง WhatsApp

ข้อสรุปสำคัญ

  • ภาษา Go ไม่ได้เร็วเสมอไป ตรงกันข้าม JS runtime อาจเร็วกว่าได้
  • Go โดดเด่นเรื่องความเรียบง่ายและประสิทธิภาพ แต่ในสภาพแวดล้อมจริง บางครั้งประสิทธิภาพอาจต่ำกว่าที่คาดไว้
  • โดยเฉพาะในสถานการณ์ที่มีฐานข้อมูล I/O จำนวนมาก ประสิทธิภาพอาจด้อยกว่า JavaScript runtime อย่าง Bun

ผลลัพธ์ของเบนช์มาร์ก

  • Go แสดงให้เห็นถึงปริมาณการรองรับคำขอที่สูงกว่าและการใช้หน่วยความจำที่ต่ำกว่า แต่การใช้ CPU สูงกว่า 2~3 เท่า
  • แต่ในสภาพแวดล้อมจริงที่มี DB I/O มาก Bun (ชุดผสมของเฟรมเวิร์ก Elysia และไลบรารี MySQL2) แสดงประสิทธิภาพที่เสถียรและมีประสิทธิผลมากกว่า
  • HTTP router มาตรฐานมีประสิทธิภาพต่ำ เมื่อลองเปลี่ยนไปใช้เฟรมเวิร์ก Fiber ก็ได้ความเร็วตอบสนองใกล้เคียงกับ Bun (อย่าใช้ Go standard HTTP Router!)

ข้อดีของ Go ที่ได้คิดทบทวนระหว่างทำเบนช์มาร์กนี้

  • มี primitive types ที่หลากหลายและให้ type safety
  • การดีพลอยแบบ single binary: สามารถเผยแพร่เป็นไฟล์รันแบบเรียบง่ายได้ ตัดการพึ่งพา runtime ออกไป
  • goroutine: รองรับการประมวลผลแบบขนานอย่างมีประสิทธิภาพ และหากใช้อย่างเหมาะสมก็สามารถดึงประสิทธิภาพฮาร์ดแวร์ออกมาได้สูงสุด

ข้อจำกัดและช่องทางในการปรับปรุงที่สัมผัสได้จากเบนช์มาร์กครั้งนี้

  • ปัญหาด้านประสิทธิภาพของ MySQL driver ที่น่าสงสัย: go-mysql-driver ของ Go แม้จะเสถียรแต่ช้า และดูเหมือนประสิทธิภาพจะด้อยกว่า mysql2 ของ JavaScript (แน่นอนว่าอาจเป็นเพราะผมเข้าใจผิดก็ได้)
  • ในงานที่ไม่มีการเชื่อมต่อ DB Go ให้ประสิทธิภาพที่ดีกว่า ซึ่งบางทีนี่ก็อาจเป็นเรื่องธรรมดา
  • ประสิทธิภาพที่ต่ำของ HTTP router: เพื่อสุขภาพจิตของคุณ ใช้ Fiber หรือเฟรมเวิร์กอื่นเถอะ!

เหตุผลที่ยังอยากใช้ Go ต่อ แม้จะไม่พอใจกับประสิทธิภาพ

  • type safety ของ Go, การดีพลอยแบบ single binary และประสิทธิภาพการประมวลผลแบบขนานของ goroutine ล้วนมีเสน่ห์มากในมุมของนักพัฒนา มี type ต่าง ๆ ที่ TypeScript ทดแทนไม่ได้ และการดีพลอยเป็นไฟล์ single binary โดยไม่ต้อง npm install ก็เป็นข้อดีที่ใหญ่มากจริง ๆ
  • จากการมองเห็นโอกาสในการปรับแต่งประสิทธิภาพเพิ่มเติม จึงตัดสินใจว่าจะเรียนรู้และใช้งาน Go ต่อไปมากขึ้น

ข้อความถึงนักพัฒนา

  • ทุกภาษาและทุกเทคโนโลยีต่างมีข้อดีข้อเสีย และผมคิดว่าภาษา Go ก็เช่นกัน
  • แทนที่จะผิดหวังกับประสิทธิภาพของ Go ลองใช้จุดแข็งของมันให้เต็มที่ และมองหาวิธีฝ่าข้อจำกัดด้านประสิทธิภาพต่อไปก็น่าจะดี
  • ผู้เขียนจึงเขียนบทความนี้ขึ้นมาเพื่อแบ่งปันข้อมูลให้กับนักพัฒนาที่ใช้ Go ว่า มีผลการวิเคราะห์แบบนี้อยู่ด้วยเช่นกัน

16 ความคิดเห็น

 
roxie 2024-12-04

พูดนอกเรื่องนิดหน่อย แต่ฟอนต์ IBM Plex Sans KR สวยมากเลย

 
tsboard 2024-12-04

ผมก็ชอบฟอนต์นั้นมากจริงๆ เลยเอามาใช้เหมือนกัน แต่มีจุดที่น่าเสียดายอยู่แค่อย่างเดียวคือ ถ้าดูบนจอความละเอียดต่ำ มันจะไม่ได้สวยเป็นพิเศษเท่าไรครับ 555 แต่ถ้าดูบนจอ 5K นี่สวยจริงๆ!

 
kuber 2024-12-02

ผมคิดว่าการวิจารณ์อะไรสักอย่างควรทำด้วยความระมัดระวังอย่างมาก

ทั้งยังไม่ชัดเจนว่าเป็นปัญหาในระดับตัวภาษาเอง เป็นปัญหาของไลบรารีเฉพาะตัว หรือเป็นปัญหาในโค้ด อีกทั้งก็ยังไม่ได้ให้ข้อมูลมากพอที่คนอื่นจะนำไปทำซ้ำได้ แต่กลับออกมาระบุในที่สาธารณะว่าอะไรบางอย่างไม่ดี

ต่อให้จะไม่ได้มีเจตนาเช่นนั้นก็ตาม เนื้อหาแบบนั้นก็ดูจะไม่ใช่สิ่งที่ทำให้ผู้คนที่ใช้ชีวิตอยู่ในอีโคซิสเต็มนั้นรู้สึกดีนัก

 
tsboard 2024-12-03

สวัสดีครับ/ค่ะ! ก่อนอื่นต้องขอขอบคุณสำหรับความคิดเห็นอันมีค่าของคุณ ผม/ฉันเข้าใจว่าคุณแสดงความคิดเห็นนั้นด้วยความรู้สึกแบบใด และหากคุณรู้สึกว่าผม/ฉันกำลังตำหนิอนาคตของภาษา Go หรือผู้ใช้งาน ผม/ฉันขอย้ำอีกครั้งว่านั่นไม่ใช่เจตนา และขออภัยมา ณ ที่นี้ด้วยครับ/ค่ะ และถ้าคุณสะดวก ลองกดที่ชื่อบทความดูนะครับ/คะ ภายในมีข้อมูลหลายส่วนรวมถึงลิงก์ไปยังบทความบล็อกของท่านอื่นเพิ่มเติมอยู่ด้วย (แม้จะค่อนข้างยาวสักหน่อย) ซึ่งผม/ฉันคิดว่าถ้าได้อ่านแล้ว คุณน่าจะเข้าใจเจตนาของผม/ฉันได้ชัดเจนยิ่งขึ้น

ผม/ฉันมองว่าภาษาคอมพิวเตอร์ก็คล้ายกับรถยนต์ประเภทหนึ่ง แต่ละคันมีทั้งข้อดีและข้อเสียแตกต่างกัน มีต้นทุนในการครอบครองไม่เหมือนกัน และแม้จะดูเหมือนทำหน้าที่คล้ายกัน แต่ก็ไล่ตามคุณค่าคนละแบบ ในแง่นี้ผม/ฉันคิดว่ามันคล้ายกันมาก แน่นอนว่าการมีความผูกพันและรักรถคันนั้นเป็นพิเศษก็เป็นเรื่องธรรมดา ผม/ฉันเองก็รักรถของตัวเองและเชื่อมั่นในผู้ผลิตรถคันนั้นเช่นกัน

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

แม้ในเวอร์ชันสรุปจะพูดถึงเรื่องนี้ได้ไม่มาก แต่ในเนื้อหาฉบับเต็มของบล็อก ผม/ฉันปิดท้ายไว้ว่า แม้ Go จะมีจุดที่น่าเสียดายอยู่บ้าง แต่ข้อดีก็ยังมีมากกว่า จึงตั้งใจว่าจะใช้งานมันต่อไป (=ขับต่อไป) ผม/ฉันคิดว่าแต่ละภาษามีคุณค่าและจุดเด่นที่มุ่งเน้นต่างกัน จึงพยายามใช้งานภาษาให้หลากหลายที่สุดเท่าที่ทำได้ (=รถหลากหลายรุ่น) เหตุผลที่ผม/ฉันพยายามจะย้ายจาก JS runtime ที่ใช้งานได้ดีอยู่แล้วไปเป็นภาษา Go ก็ด้วยเหตุผลนั้นเช่นกัน

ผม/ฉันคิดว่าตัวเองเขียนบทความอย่างระมัดระวังแล้ว เพื่อหลีกเลี่ยงการถกเถียงเรื่องภาษาที่ไม่จำเป็นให้ได้มากที่สุด แต่ถึงกระนั้น หากยังมีชาว Gopher ท่านใดที่อ่านบทความนี้แล้วรู้สึกไม่สบายใจ ผม/ฉันก็หวังว่าคุณจะคลายความขุ่นข้องใจลงได้อีกครั้ง และขอปิดท้ายคอมเมนต์นี้ด้วยการบอกว่า ผม/ฉันเป็นโค้ดเดอร์สายโรแมนติกที่รักแม้แต่ภาษา PHP ซึ่งเคยโดนวิจารณ์อย่างหนักเช่นกันครับ/ค่ะ!

 
savvykang 2024-12-03

ในต้นฉบับมีทั้งการวิเคราะห์ในมุมของผู้เขียนเองเกี่ยวกับส่วนที่ช้า และเหตุผลว่าทำไมถึงยังจะเลือกใช้ Go อยู่ดี จึงไม่ค่อยเข้าใจว่าเพราะเหตุใดคุณถึงรับบทความนี้ไปในเชิงการตัดสินคุณค่าครับ

 
kuber 2024-12-02

แม้จะเป็นเรื่องปลีกย่อย แต่ std ไลบรารีของ Go มีประสิทธิภาพลดลงเรื่อย ๆ ตามกาลเวลา สาเหตุหลักคือเป็น trade-off จากการเพิ่มฟีเจอร์ต่าง ๆ เพื่อให้สอดคล้องกับมาตรฐาน RFC และรับมือกับช่องโหว่ด้านความปลอดภัยจำนวนมากที่มีการรายงานเข้ามา

ช่วงหลังนี้ เพื่อให้ผ่านการรับรอง FIPS ก็คาดว่าน่าจะต้องแลกกับประสิทธิภาพที่ลดลงมากขึ้นอีกพอสมควร

ถ้าตัดบริบทเบื้องหลังเหล่านี้ออกไปทั้งหมด แล้วเขียนแค่ว่าในบางสถานการณ์ที่เรียบง่ายมาก ๆ ประสิทธิภาพไม่ดี ก็คิดว่าน่าจะเพียงพอที่จะทำให้หลายคนเข้าใจผิดได้เลยนะ เฮ้อ

 
ifmkl 2024-12-02

กำลังรอเวอร์ชัน 1.0 ของ tsboard อยู่นะครับ 555

 
tsboard 2024-12-02

ขอบคุณที่รอครับ! ผมจะทำงานต่อไปด้วยความยินดีครับ 555

 
kandk 2024-12-02

ผมคิดว่าเมื่อ JS ใช้ JIT ก็ไม่มีเหตุผลอะไรเป็นพิเศษที่มันจะต้องช้านะครับ
ถ้าไม่นับเรื่องมัลติเธรด ความเสถียร ฯลฯ..

 
tsboard 2024-12-02

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

 
joyfui 2024-12-02

เข้าเว็บไซต์ไม่ได้ มีใครเป็นเหมือนผมคนเดียวไหม?

 
tsboard 2024-12-02

สวัสดีครับ! ขอบคุณที่แจ้งผ่านคอมเมนต์นะครับ 555 ตอนนี้ยังย้ายไซต์ไปยังโฮสติ้งไม่ได้ เลยมีปัญหาเข้าใช้งานสะดุดเป็นบางครั้งครับ! จะรีบจัดการให้เร็วที่สุดเท่าที่จะทำได้ครับ (ตอนนี้ Mini PC ที่บ้านกำลังทำงานหนักมากอยู่ 😂)

 
joyfui 2024-12-02

โอ้ ตอนนี้ใช้ได้แล้วครับ จะอ่านอย่างตั้งใจเลย!

 
tsboard 2024-12-02

ย้ายเว็บไซต์จากมินิพีซีที่บ้านไปยังเซิร์ฟเวอร์เสมือนขนาดห้องเล็กหนึ่งห้องแล้ว...! วันนี้มีหลายท่านเข้ามาแบบไม่คาดคิดจนต้องกดกลับกันไป แต่ตอนนี้ขอแจ้งว่าไม่มีปัญหาแล้ว!

 
lemonmint 2024-12-02

ผมสงสัยว่าถ้าลองทดสอบด้วยไดรเวอร์ github.com/jackc/pgx/v5 และ PostgreSQL แล้ว ผลลัพธ์จะออกมาต่างไปหรือเปล่า

 
tsboard 2024-12-02

ผมก็สงสัยเหมือนกันว่าผลลัพธ์นี้เป็นปัญหาที่จำกัดอยู่แค่กับ mysql หรือว่าใช้ได้กับทุกสถานการณ์ที่มีการใช้ DB หวังว่าสักวันคงจะมีคนอื่นมาแชร์ผลลัพธ์กันนะครับ 555