12 คะแนน โดย sftblw 2024-08-19 | 9 ความคิดเห็น | แชร์ทาง WhatsApp

Misskey (GeekNews) เป็นโปรแกรมเซิร์ฟเวอร์ไมโครบล็อกกิงที่รองรับเครือข่ายสหพันธรัฐ ActivityPub Misskey พัฒนาเป็นหลักในญี่ปุ่น และมีฟีเจอร์สนุก ๆ มากมาย เช่น การรีแอ็กชันด้วยอีโมจิ, MFM ซึ่งเป็นมาร์กอัปของตัวเอง, การติดตามคีย์เวิร์ด (Antenna), การตกแต่งโปรไฟล์, การสร้างหน้าอินเทอร์แอกทีฟด้วย AiScript ซึ่งเป็นสคริปต์ของตัวเอง, มินิเกม ฯลฯ จึงเป็นแพลตฟอร์มที่มีผู้ใช้จำนวนมากเข้ามาเพื่อความสนุก

เท่าที่ผมทราบ สแตกเทคโนโลยีของ Misskey มีดังนี้ (อาจคลาดเคลื่อนได้)

  • NodeJS, TypeScript
  • Koa.js, PostgreSQL, Redis
  • Vue

ในบทความนี้ syuilo ผู้ดูแลหลักของ Misskey ได้ทดสอบประสิทธิภาพของ Bun เมื่อเทียบกับ NodeJS โดยใช้ซอร์สโค้ดของ Misskey

  • จุดประสงค์คือทดสอบว่าเมื่อนำซอร์สเดิมไปรันด้วย Bun แล้วจะเร็วขึ้นหรือไม่ โดยในบทความระบุว่าไม่ได้ทำการปรับแต่งเฉพาะสำหรับ Bun แยกต่างหาก และหากมีโค้ดที่ไม่เข้ากันซึ่งซับซ้อน ก็จะไม่ทำการทดสอบ
  • ในบทความยังย้ำว่าควรมองเป็นเพียงกรณีศึกษาหนึ่งเท่านั้น
  • แม้จะทดสอบบน Ubuntu แต่ก็ระบุว่าใน Windows ก็แทบไม่ต่างกัน

สรุปสั้น ๆ คือ ในกรณีนี้กลับพบว่า Bun มีแนวโน้มให้ประสิทธิภาพลดลงเสียมากกว่า ดูเหมือนว่าการนำซอร์สขนาดใหญ่เดิมไปรันบน Bun ไม่ได้ทำให้เร็วขึ้นอย่างน่าอัศจรรย์... น่าจะเป็นข้อสรุปของบทความนี้ และนี่คือเนื้อหาที่ ChatGPT สรุปไว้

  • การใช้หน่วยความจำ: Node ประมาณ 200MB, Bun ประมาณ 800MB โดย Bun ใช้หน่วยความจำมากกว่ามาก
  • ความเร็วในการประมวลผล: ในงานหลายแบบ เช่น การดึงไทม์ไลน์ Node ทำได้เร็วกว่า โดยเฉพาะตอนสร้างโพสต์ Node ใช้ 5 วินาที ส่วน Bun ใช้ 10 วินาที ทำให้ Node เร็วกว่า 2 เท่า
  • AiScript: ในการรันโค้ด JavaScript ล้วน ๆ Node (เอนจิน V8) เร็วกว่าประมาณ 1.5 เท่า

ในบทความมีการเผยแพร่เบนช์มาร์กการทำงานของแต่ละส่วนของโค้ดเบส แต่ยกเว้นการรัน WebSocket แบบครั้งเดียว ทุกกรณี NodeJS ให้ผลลัพธ์เร็วกว่า ไม่ว่าจะต่างกันเล็กน้อยหรือมากก็ตาม แม้ในกรณีของ WebSocket เอง เมื่อรัน 100,000 ครั้ง NodeJS ก็ยังเร็วกว่าเล็กน้อย

อย่างไรก็ตาม syuilo ผู้เขียนบทความยังคงคาดหวังกับศักยภาพการพัฒนาของ Bun และยังกล่าวถึงความเป็นไปได้ที่ประสิทธิภาพจะดีขึ้นได้จากการปรับแต่งเพิ่มเติม

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

 
nxhtk 2024-08-19

ถ้าแค่สลับแล้วรันเลย ก็มีเคสที่ยังปรับแต่งได้ไม่ดีนักตามที่ระบุไว้ในเอกสารหรือ issue ของ bun เช่นไลบรารีที่เกี่ยวกับ node:crypto หรือ zlib

ถ้าตัวอย่างช้าลงจาก 5 วินาทีเป็น 10 วินาที ก็น่าจะเป็นส่วนลักษณะนี้จริง ๆ ครับ ผมเองก็เคยเจอว่าช้าลงหลายเท่าเพราะปัญหาแบบนี้ในไลบรารีที่เกี่ยวกับ JWT เลยต้องเปลี่ยนไลบรารีและปรับแต่งให้เหมาะสม

 
savvykang 2024-08-19

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

 
tribela 2024-08-20

ไม่แน่ใจว่าโพสต์อื่นเป็นอย่างไร แต่โพสต์นี้ถูกลงใน Misskey เลยสามารถรับดูได้ผ่านเฟดิเวิร์ส (ผมเองก็เห็นจากที่นั่นก่อน แล้วค่อยมารู้ว่าโพสต์ขึ้นที่นี่ด้วย)

 
bus710 2024-08-20

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

 
savvykang 2024-08-21

ระบบแนะนำคำค้นหาอัตโนมัติของ Google แนะนำคำค้นที่เปรียบเทียบ Kita กับ zenn ให้ ทำให้ผมหา zenn เจอได้ด้วย ขอบคุณสำหรับข้อมูลครับ

 
uyeong21c 2024-08-20

Qiita อ่านว่า คีตะ ครับ

 
bus710 2024-08-20

อ๋อ เข้าใจแล้วครับ เขินเลย

 
tsboard 2024-08-19

เป็นผลลัพธ์ที่น่าสนใจมาก ในกรณีของ Bun มักมีการแนะนำ ElysiaJS เป็นเว็บเฟรมเวิร์กกันมาก แต่มีปัญหาว่าหากไม่ใช้ API ที่ Bun ปรับแต่งมาโดยเฉพาะ กลับทำให้ประสิทธิภาพลดลงแทน มีการระบุว่าใช้ Koa.js ซึ่งคาดว่าประสิทธิภาพน่าจะตกลงไปมากจากฝั่งนั้น

 
cometkim 2024-08-19

เราควรแยกให้ชัดระหว่างความต่างของรันไทม์กับการผสานเข้ากับระบบนะครับ

ประสิทธิภาพที่ Bun ภูมิใจนำเสนอนั้น โดยรวมแล้วมาจากคุณลักษณะของ JSC การปรับแต่งบางส่วนในการผสานเข้ากับระบบ (หรือการลดทอนฟีเจอร์) และการเลือกใช้ไลบรารีพื้นฐานที่ดี

ดังนั้นในเบนช์มาร์กขนาดเล็ก Bun มักจะชนะ แต่ในเบนช์มาร์กขนาดใหญ่หรือแบบรันต่อเนื่องยาว ๆ ก็มีแนวโน้มว่าจะเป็นรอง Node.js ไปพร้อมกันครับ