หลังจากการสัมภาษณ์งานครั้งล่าสุดครั้งหนึ่ง ฉันรู้สึกประหลาดใจเมื่อพบว่าบริษัทที่ฉันสมัครไปยังคงใช้ Laravel ซึ่งเป็นเฟรมเวิร์ก PHP ที่ฉันเคยลองใช้เมื่อประมาณทศวรรษที่แล้ว เฟรมเวิร์กนี้ถือว่าดีทีเดียวในสมัยนั้น แต่ถ้ามีสิ่งหนึ่งที่ไม่เปลี่ยนแปลงทั้งในด้านเทคโนโลยีและแฟชั่น นั่นก็คือการเปลี่ยนแปลงและการนำรูปแบบและแนวคิดใหม่ๆ มาใช้อย่างต่อเนื่อง หากคุณเป็นโปรแกรมเมอร์ JavaScript คุณคงคุ้นเคยกับเรื่องตลกเก่าๆ นี้
โปรแกรมเมอร์ 1: "ฉันไม่ชอบเฟรมเวิร์ก JavaScript ใหม่นี้!"
โปรแกรมเมอร์ 2: “ไม่ต้องกังวล แค่รอสัก 6 เดือน ก็มีตัวใหม่มาแทนที่แล้ว!”
ด้วยความอยากรู้อยากเห็น ฉันจึงตัดสินใจลองดูว่าจะเกิดอะไรขึ้นเมื่อเรานำสิ่งเก่าและสิ่งใหม่มาทดสอบ แน่นอนว่าเว็บไซต์เต็มไปด้วยเกณฑ์มาตรฐานและข้อเรียกร้อง ซึ่งข้อเรียกร้องที่ได้รับความนิยมมากที่สุดน่าจะเป็น เกณฑ์มาตรฐานกรอบงานเว็บ TechEmpower ที่นี่ . เราจะไม่ทำอะไรที่ซับซ้อนเท่ากับวันนี้ แต่เราจะทำทุกอย่างให้เรียบง่ายและดี เพื่อที่บทความนี้จะได้ไม่กลายเป็น... สงครามและสันติภาพ , และคุณมีโอกาสเล็กน้อยที่จะตื่นอยู่เมื่ออ่านจบ ข้อควรระวังทั่วไปคือ วิธีนี้อาจไม่ได้ผลกับเครื่องของคุณ เวอร์ชันซอฟต์แวร์ที่แตกต่างกันอาจส่งผลต่อประสิทธิภาพการทำงาน และแมวของชเรอดิงเงอร์ก็กลายเป็นแมวซอมบี้ที่ครึ่งชีวิตครึ่งตายในเวลาเดียวกัน
สำหรับการทดสอบนี้ ฉันจะใช้แล็ปท็อปของฉันซึ่งมีโปรเซสเซอร์ i5 ขนาดเล็กที่ทำงานบน Manjaro Linux ดังที่แสดงที่นี่
โค้ดของเราจะมีสามงานง่าย ๆ สำหรับแต่ละคำขอ:
คุณอาจสงสัยว่าการทดสอบแบบนั้นเป็นการทดสอบที่โง่เขลาประเภทไหนกันแน่? หากคุณลองดูคำขอเครือข่ายสำหรับหน้านี้ คุณจะสังเกตเห็นว่ามีไฟล์ชื่อ sessionvars.js ที่ทำงานแบบเดียวกัน
คุณจะเห็นว่าหน้าเว็บในปัจจุบันเป็นสิ่งมีชีวิตที่ซับซ้อน และหนึ่งในงานที่พบเห็นบ่อยที่สุดคือการแคชหน้าเว็บที่ซับซ้อนเพื่อหลีกเลี่ยงการโหลดเกินบนเซิร์ฟเวอร์ฐานข้อมูล
หากเราทำการเรนเดอร์หน้าเว็บที่ซับซ้อนใหม่ทุกครั้งที่มีผู้ใช้ร้องขอ เราก็สามารถให้บริการผู้ใช้ได้เพียงประมาณ 600 รายต่อวินาทีเท่านั้น
แต่หากเราแคชเพจนี้เป็นไฟล์ HTML แบบคงที่ และปล่อยให้ Nginx โยนมันออกไปนอกหน้าต่างให้กับผู้ใช้โดยเร็ว เราก็จะสามารถให้บริการผู้ใช้ได้ 32,000 รายต่อวินาที เพิ่มประสิทธิภาพได้ถึง 50 เท่า
index.en.html แบบคงที่เป็นส่วนที่ทุกคนเข้าถึงได้ และจะส่งเฉพาะส่วนที่แตกต่างกันตามผู้ใช้เท่านั้นใน sessionvars.js ซึ่งไม่เพียงแต่ช่วยลดภาระของฐานข้อมูลและสร้างประสบการณ์ที่ดีขึ้นให้กับผู้ใช้ของเราเท่านั้น แต่ยังช่วยลดความน่าจะเป็นเชิงควอนตัมที่เซิร์ฟเวอร์ของเราจะหายไปเองเมื่อเกิดการโจมตีจากกลุ่มคลิงออนอีกด้วย
โค้ดที่ส่งคืนสำหรับแต่ละเฟรมเวิร์กจะมีข้อกำหนดง่ายๆ หนึ่งข้อ: แสดงให้ผู้ใช้เห็นว่าพวกเขารีเฟรชหน้ากี่ครั้งโดยพูดว่า "จำนวนเท่ากับ x" เพื่อให้ทุกอย่างง่ายขึ้น เราจะหลีกเลี่ยงคิว Redis, คอมโพเนนต์ Kubernetes หรือ AWS Lambdas ไปก่อน
ข้อมูลเซสชันของผู้ใช้แต่ละรายจะถูกบันทึกลงในฐานข้อมูล PostgreSQL
และตารางฐานข้อมูลนี้จะถูกตัดทอนก่อนการทดสอบแต่ละครั้ง
เรียบง่ายแต่มีประสิทธิภาพคือคติประจำใจของ Pafera... อยู่นอกช่วงเวลาที่มืดมนที่สุดอยู่แล้ว...
โอเค ตอนนี้เราก็เริ่มลงมือทำได้แล้ว เราจะข้ามขั้นตอนการตั้งค่าสำหรับ Laravel ไป เนื่องจากเป็นเพียงคำสั่ง composer และ artisan เท่านั้น
ก่อนอื่นเราจะตั้งค่าฐานข้อมูลของเราในไฟล์ .env
จากนั้นเราจะกำหนดเส้นทางสำรองเพียงเส้นทางเดียวที่ส่งคำขอทั้งหมดไปยังตัวควบคุมของเรา
และตั้งค่าตัวควบคุมให้แสดงจำนวน Laravel จะเก็บเซสชันไว้ในฐานข้อมูลตามค่าเริ่มต้น นอกจากนี้ยังจัดเตรียม session()
ฟังก์ชันในการเชื่อมต่อกับข้อมูลเซสชันของเรา ดังนั้นต้องใช้เพียงโค้ดสองสามบรรทัดในการแสดงผลหน้าของเรา
หลังจากตั้งค่า php-fpm และ Nginx แล้ว หน้าของเราก็ดูดีทีเดียว...
อย่างน้อยจนกว่าเราจะได้เห็นผลการทดสอบจริงๆ...
ไม่ใช่ว่าพิมพ์ผิด เครื่องทดสอบของเราได้เพิ่มความเร็วจาก 600 คำขอต่อวินาทีในการเรนเดอร์หน้าที่ซับซ้อน... เป็น 21 คำขอต่อวินาทีในการเรนเดอร์ "จำนวนคือ 1"
มีอะไรผิดพลาดเกิดขึ้นหรือเปล่า? การติดตั้ง PHP ของเรามีปัญหาหรือไม่? Nginx ทำงานช้าลงเมื่อเชื่อมต่อกับ php-fpm หรือไม่?
มาทำหน้านี้ใหม่ด้วยโค้ด PHP ล้วนๆ กัน
ตอนนี้เราได้ใช้โค้ด 98 บรรทัดในการทำสิ่งที่โค้ด 4 บรรทัด (และงานกำหนดค่ามากมาย) ใน Laravel ทำ (แน่นอนว่า ถ้าเราจัดการข้อผิดพลาดและส่งข้อความที่ผู้ใช้เห็นอย่างถูกต้อง จำนวนบรรทัดจะเพิ่มขึ้นเป็นสองเท่า) บางทีเราอาจส่งคำขอได้ถึง 30 รายการต่อวินาทีก็ได้?
ว้าว! ดูเหมือนว่าการติดตั้ง PHP ของเราจะไม่มีปัญหาอะไรเลยนะ เวอร์ชัน PHP ล้วนๆ จะส่งคำขอได้ 700 ครั้งต่อวินาที
หากไม่มีอะไรผิดปกติกับ PHP อาจเป็นเพราะเราตั้งค่า Laravel ผิดก็ได้
หลังจากค้นหาปัญหาเกี่ยวกับการกำหนดค่าและเคล็ดลับประสิทธิภาพบนเว็บแล้ว เทคนิคยอดนิยมสองประการคือการแคชข้อมูลการกำหนดค่าและกำหนดเส้นทางเพื่อหลีกเลี่ยงการประมวลผลข้อมูลสำหรับทุกคำขอ ดังนั้น เราจะนำคำแนะนำเหล่านั้นไปใช้และลองเคล็ดลับเหล่านี้
ทุกอย่างดูดีบนบรรทัดคำสั่ง มาทำการประเมินประสิทธิภาพใหม่กัน
ตอนนี้เราได้เพิ่มประสิทธิภาพการทำงานจาก 21.04 เป็น 28.80 คำขอต่อวินาที ซึ่งเพิ่มขึ้นอย่างมากเกือบ 37%! ซึ่งถือว่าน่าประทับใจมากสำหรับแพ็คเกจซอฟต์แวร์ใดๆ ยกเว้นข้อเท็จจริงที่ว่าเรายังทำคำขอได้เพียง 1/24 ของจำนวนคำขอในเวอร์ชัน PHP ล้วนๆ
หากคุณคิดว่าต้องมีบางอย่างผิดปกติกับการทดสอบนี้ คุณควรพูดคุยกับผู้เขียนเฟรมเวิร์ก Lucinda PHP ในผลการทดสอบของเขา เขาได้ Lucinda เอาชนะ Laravel เพิ่มขึ้น 36 เท่าสำหรับคำขอ HTML และ 90 เท่าสำหรับคำขอ JSON
หลังจากทดสอบบนเครื่องของตัวเองด้วย Apache และ Nginx แล้ว ฉันก็ไม่มีเหตุผลที่จะสงสัยเขา Laravel เป็นเพียง ที่ ช้า! PHP เองไม่ได้แย่ขนาดนั้น แต่เมื่อคุณเพิ่มการประมวลผลพิเศษทั้งหมดที่ Laravel เพิ่มให้กับแต่ละคำขอแล้ว ฉันพบว่ามันยากมากที่จะแนะนำ Laravel เป็นตัวเลือกในปี 2023
บัญชี PHP/Wordpress สำหรับ ประมาณ 40% ของเว็บไซต์ทั้งหมดบนเว็บ ทำให้เป็นกรอบงานที่โดดเด่นที่สุด อย่างไรก็ตาม ส่วนตัวแล้ว ฉันพบว่าความนิยมไม่ได้แปลว่ามีคุณภาพเสมอไป เช่นเดียวกับที่ฉันพบว่าตัวเองมีความต้องการอย่างควบคุมไม่ได้อย่างกะทันหันสำหรับอาหารรสเลิศที่พิเศษจาก ร้านอาหารที่ได้รับความนิยมมากที่สุดในโลก ... McDonald’s เนื่องจากเราได้ทดสอบโค้ด PHP ล้วนๆ แล้ว เราจะไม่ทดสอบ WordPress เอง เพราะสิ่งใดก็ตามที่เกี่ยวข้องกับ WordPress จะต้องต่ำกว่า 700 คำขอต่อวินาทีที่เราพบใน PHP ล้วนๆ
Django เป็นเฟรมเวิร์กยอดนิยมอีกตัวหนึ่งที่ได้รับความนิยมมายาวนาน หากคุณเคยใช้เฟรมเวิร์กนี้มาก่อน คุณคงจะจำอินเทอร์เฟซการจัดการฐานข้อมูลอันยอดเยี่ยมของมันได้เป็นอย่างดี รวมถึงความน่ารำคาญในการกำหนดค่าทุกอย่างให้เป็นไปตามที่ต้องการ มาดูกันว่า Django จะทำงานได้ดีแค่ไหนในปี 2023 โดยเฉพาะอย่างยิ่งเมื่อใช้กับอินเทอร์เฟซ ASGI ใหม่ที่เพิ่มเข้ามาในเวอร์ชัน 4.0
การตั้งค่า Django นั้นคล้ายคลึงกับการตั้งค่า Laravel มาก เนื่องจากทั้งสองอย่างนี้เกิดขึ้นในยุคที่สถาปัตยกรรม MVC มีสไตล์และถูกต้อง เราจะข้ามการกำหนดค่าที่น่าเบื่อและไปที่การตั้งค่ามุมมองโดยตรง
โค้ดสี่บรรทัดนั้นเหมือนกับเวอร์ชัน Laravel มาดูกันว่าจะทำงานได้อย่างไร
ไม่เลวเลยที่ 355 คำขอต่อวินาที มีประสิทธิภาพเพียงครึ่งเดียวของเวอร์ชัน PHP ล้วนๆ แต่ยังดีกว่าเวอร์ชัน Laravel ถึง 12 เท่า ดูเหมือนว่า Django กับ Laravel จะไม่มีอะไรเทียบได้เลย
นอกเหนือจากกรอบขนาดใหญ่ทั้งหมดรวมถึงอ่างล้างจานแล้ว ยังมีกรอบขนาดเล็กอีกเช่นกันที่เพียงแค่ตั้งค่าพื้นฐานบางส่วนในขณะที่ให้คุณจัดการส่วนที่เหลือได้ หนึ่งในกรอบที่ดีที่สุดที่จะใช้คือ Flask และ Quart ซึ่งเป็น ASGI กรอบงาน PaferaPy ถูกสร้างขึ้นบน Flask ดังนั้นฉันจึงคุ้นเคยเป็นอย่างดีว่าการทำสิ่งต่างๆ ให้เสร็จสิ้นในขณะที่ยังคงประสิทธิภาพการทำงานไว้นั้นง่ายดายเพียงใด
อย่างที่คุณเห็น สคริปต์ Flask นั้นสั้นกว่าสคริปต์ PHP ล้วนๆ ฉันพบว่าจากภาษาต่างๆ ที่ฉันเคยใช้ Python น่าจะเป็นภาษาที่แสดงออกถึงการกดแป้นพิมพ์ได้ดีที่สุด การไม่มีวงเล็บและวงเล็บเหลี่ยม การทำความเข้าใจรายการและพจนานุกรม และการบล็อกตามการย่อหน้าแทนการใช้เครื่องหมายเซมิโคลอนทำให้ Python ค่อนข้างเรียบง่ายแต่มีประสิทธิภาพในด้านความสามารถ
น่าเสียดายที่ Python เป็นภาษาสำหรับวัตถุประสงค์ทั่วไปที่ช้าที่สุด แม้ว่าจะมีการเขียนซอฟต์แวร์มากมายด้วยภาษานี้ก็ตาม จำนวนไลบรารี Python ที่มีอยู่นั้นมีมากกว่าภาษาที่คล้ายกันประมาณสี่เท่าและครอบคลุมโดเมนจำนวนมาก แต่ไม่มีใครพูดได้ว่า Python นั้นรวดเร็วหรือมีประสิทธิภาพนอกเหนือจากกลุ่มเฉพาะเช่น NumPy
มาดูกันว่าเวอร์ชัน Flask ของเราเปรียบเทียบกับเฟรมเวิร์กก่อนหน้าของเราได้อย่างไร
สคริปต์ Flask ของเรานั้นเร็วกว่าเวอร์ชัน PHP ล้วนของเราจริงๆ!
หากคุณรู้สึกแปลกใจกับเรื่องนี้ คุณควรตระหนักว่าแอป Flask ของเราดำเนินการเริ่มต้นและกำหนดค่าทั้งหมดเมื่อเราเริ่มต้นเซิร์ฟเวอร์ gunicorn ในขณะที่ PHP จะดำเนินการสคริปต์ใหม่ทุกครั้งที่มีคำขอใหม่เข้ามา ซึ่งเทียบได้กับ Flask ที่เป็นคนขับแท็กซี่หนุ่มที่กระตือรือร้นซึ่งสตาร์ทรถแล้วและกำลังรออยู่ข้างถนน ในขณะที่ PHP เป็นคนขับรถรุ่นเก่าที่อยู่ที่บ้านรอสายเรียกเข้าและขับรถมารับคุณในภายหลัง ในฐานะคนรุ่นเก่าและมาจากยุคที่ PHP เป็นการเปลี่ยนแปลงที่ยอดเยี่ยมสำหรับไฟล์ HTML และ SHTML ธรรมดา จึงค่อนข้างน่าเศร้าที่ต้องตระหนักว่าเวลาผ่านไปนานแค่ไหน แต่ความแตกต่างในการออกแบบทำให้ PHP แข่งขันกับเซิร์ฟเวอร์ Python, Java และ Node.js ได้ยาก เนื่องจากเซิร์ฟเวอร์เหล่านี้ยังคงอยู่ในหน่วยความจำและจัดการคำขอด้วยความคล่องตัวอย่างนักเล่นกล
Flask อาจเป็นเฟรมเวิร์กที่เร็วที่สุดของเราจนถึงตอนนี้ แต่จริงๆ แล้วมันเป็นซอฟต์แวร์ที่ค่อนข้างเก่า ชุมชน Python เปลี่ยนมาใช้เซิร์ฟเวอร์ ASGI แบบอะซิงโครนัสที่ใหม่กว่าเมื่อสองสามปีก่อน และแน่นอนว่าฉันเองก็เปลี่ยนตามพวกเขาด้วย
Pafera Framework เวอร์ชันใหม่ล่าสุด PaferaPyAsync มีพื้นฐานมาจาก Starlette แม้ว่าจะมี Flask เวอร์ชัน ASGI ที่เรียกว่า Quart แต่ความแตกต่างในด้านประสิทธิภาพระหว่าง Quart และ Starlette ก็เพียงพอสำหรับฉันที่จะรีเบสโค้ดของฉันโดยใช้ Starlette แทน
การเขียนโปรแกรมแบบอะซิงโครนัสอาจเป็นเรื่องน่ากลัวสำหรับใครหลายๆ คน แต่จริงๆ แล้วมันไม่ใช่แนวคิดที่ยากเลย ขอบคุณนักพัฒนา Node.js ที่ทำให้แนวคิดนี้แพร่หลายเมื่อกว่าทศวรรษที่แล้ว
เราเคยต่อสู้กับการทำงานพร้อมกันโดยใช้มัลติเธรด มัลติโพรเซสเซอร์ การคำนวณแบบกระจาย การเชื่อมโยงคำมั่นสัญญา และช่วงเวลาสนุกๆ มากมายที่ทำให้โปรแกรมเมอร์ผู้มากประสบการณ์จำนวนมากแก่ก่อนวัยและหมดแรง ตอนนี้เราเพียงแค่พิมพ์ async
ต่อหน้าฟังก์ชั่นของเราและ await
ไว้ข้างหน้าโค้ดใดๆ ที่อาจใช้เวลาดำเนินการนานพอสมควร โค้ดนี้มีความซับซ้อนมากกว่าโค้ดปกติ แต่ใช้งานได้น้อยกว่ามากเมื่อเทียบกับการต้องจัดการกับไพรเมทีฟการซิงโครไนซ์ การส่งข้อความ และการแก้ไขคำมั่นสัญญา
ไฟล์ Starlette ของเรามีลักษณะดังนี้:
ตามที่คุณเห็น มันค่อนข้างจะคัดลอกและวางจากสคริปต์ Flask ของเราโดยมีการเปลี่ยนแปลงเส้นทางเพียงเล็กน้อยเท่านั้น async/await
คำสำคัญ
การคัดลอกและวางโค้ดช่วยปรับปรุงเราได้มากเพียงใด?
เรามีแชมป์คนใหม่แล้ว สุภาพสตรีและสุภาพบุรุษ! สถิติสูงสุดก่อนหน้านี้ของเราคือเวอร์ชัน PHP ล้วนที่ 704 คำขอต่อวินาที ซึ่งต่อมาเวอร์ชัน Flask ก็แซงหน้าไปโดยที่ 1080 คำขอต่อวินาที สคริปต์ Starlette ของเราเอาชนะคู่แข่งก่อนหน้าทั้งหมดด้วย 4562 คำขอต่อวินาที ซึ่งหมายถึงการปรับปรุง 6 เท่าจาก PHP ล้วนและ 4 เท่าจาก Flask
หากคุณยังไม่ได้เปลี่ยนโค้ด WSGI Python ให้เป็น ASGI ตอนนี้อาจเป็นเวลาที่ดีที่จะเริ่มต้น
จนถึงตอนนี้ เราได้กล่าวถึงเฉพาะเฟรมเวิร์ก PHP และ Python เท่านั้น อย่างไรก็ตาม คนส่วนใหญ่ในโลกใช้ Java, DotNet, Node.js, Ruby on Rails และเทคโนโลยีอื่นๆ ที่คล้ายกันสำหรับเว็บไซต์ของตนเอง นี่ไม่ใช่ภาพรวมที่ครอบคลุมของระบบนิเวศและไบโอมทั้งหมดของโลก ดังนั้นเพื่อหลีกเลี่ยงการเขียนโปรแกรมที่เทียบเท่ากับเคมีอินทรีย์ เราจะเลือกเฉพาะเฟรมเวิร์กที่พิมพ์โค้ดได้ง่ายที่สุดเท่านั้น ซึ่ง Java ไม่ใช่แน่นอน
เว้นแต่คุณจะซ่อนตัวอยู่ใต้สำเนา K&R C หรือ Knuth ของคุณ ศิลปะแห่งการเขียนโปรแกรมคอมพิวเตอร์ ในช่วงสิบห้าปีที่ผ่านมา คุณคงเคยได้ยินเกี่ยวกับ Node.js มาบ้างแล้ว พวกเราที่อยู่มาตั้งแต่ยุคเริ่มแรกของ JavaScript ต่างก็รู้สึกหวาดกลัวหรือประหลาดใจอย่างเหลือเชื่อกับสถานะของ JavaScript ในปัจจุบัน แต่ก็ไม่อาจปฏิเสธได้ว่า JavaScript ได้กลายเป็นพลังที่ต้องนับถือทั้งในเซิร์ฟเวอร์และเบราว์เซอร์ เพราะตอนนี้เรามีเลขจำนวนเต็มดั้งเดิม 64 บิตในภาษาแล้ว! ซึ่งดีกว่าการที่ทุกอย่างถูกจัดเก็บในรูปแบบเลขทศนิยม 64 บิตมาก!
ExpressJS อาจเป็นเซิร์ฟเวอร์ Node.js ที่ใช้งานได้ง่ายที่สุด ดังนั้นเราจะสร้างแอป Node.js/ExpressJS ที่รวดเร็วและใช้งานง่ายเพื่อให้บริการเคาน์เตอร์ของเรา
จริงๆ แล้วโค้ดนี้เขียนได้ง่ายกว่าเวอร์ชัน Python ถึงแม้ว่า JavaScript ดั้งเดิมจะค่อนข้างซับซ้อนเมื่อแอพพลิเคชั่นมีขนาดใหญ่ขึ้น และความพยายามทั้งหมดที่จะแก้ไขสิ่งนี้ เช่น TypeScript ก็จะกลายเป็นโค้ดที่มีรายละเอียดมากขึ้นอย่างรวดเร็วเมื่อเทียบกับ Python
มาดูกันว่ามันจะมีประสิทธิภาพแค่ไหน!
คุณอาจเคยได้ยินนิทานพื้นบ้านโบราณ (เก่าแก่ตามมาตรฐานอินเทอร์เน็ตอยู่แล้ว...) เกี่ยวกับความเร็วของ Node.js และเรื่องราวเหล่านี้ส่วนใหญ่เป็นเรื่องจริงเนื่องมาจากผลงานอันน่าทึ่งที่ Google ได้ทำกับเอ็นจิ้น V8 JavaScript อย่างไรก็ตาม ในกรณีนี้ แม้ว่าแอปด่วนของเราจะทำงานได้ดีกว่าสคริปต์ Flask แต่ลักษณะเธรดเดียวของมันก็พ่ายแพ้ต่อกระบวนการอะซิงก์สี่กระบวนการที่ Starlette Knight ผู้กล่าวว่า "Ni!" ใช้
มาขอความช่วยเหลือเพิ่มเติมกันเถอะ!
โอเค ตอนนี้การต่อสู้แบบสี่ต่อสี่ก็สูสีแล้ว มาทดสอบประสิทธิภาพกัน!
แม้จะยังไม่ถึงระดับ Starlette แต่ก็ไม่เลวสำหรับการแฮ็ค JavaScript อย่างรวดเร็วภายใน 5 นาที จากการทดสอบของฉันเอง สคริปต์นี้ถูกจำกัดไว้เล็กน้อยในระดับอินเทอร์เฟซฐานข้อมูล เนื่องจาก node-postgres ไม่ได้มีประสิทธิภาพใกล้เคียงกับ psycopg สำหรับ Python การเปลี่ยนไปใช้ sqlite เป็นไดรเวอร์ฐานข้อมูลจะให้ผลลัพธ์มากกว่า 3,000 คำขอต่อวินาทีสำหรับโค้ด ExpressJS เดียวกัน
สิ่งสำคัญที่ต้องทราบคือแม้ความเร็วในการดำเนินการของ Python จะช้า แต่เฟรมเวิร์ก ASGI ก็ยังสามารถแข่งขันกับโซลูชัน Node.js ได้สำหรับเวิร์กโหลดบางประเภท
ตอนนี้ เรากำลังใกล้ถึงยอดเขาแล้ว โดยที่ภูเขาที่ฉันหมายถึงคือยอดคะแนนสูงสุดที่บันทึกไว้โดยทั้งหนูและมนุษย์
หากคุณลองดูเกณฑ์มาตรฐานเฟรมเวิร์กส่วนใหญ่ที่มีบนเว็บ คุณจะสังเกตเห็นว่ามีสองภาษาที่มักจะครองตลาดสูงสุด นั่นคือ C++ และ Rust ฉันทำงานกับ C++ มาตั้งแต่ยุค 90 และฉันมีเฟรมเวิร์ก Win32 C++ ของตัวเองก่อนที่ MFC/ATL จะเข้ามามีบทบาท ดังนั้นฉันจึงมีประสบการณ์กับภาษานี้มากพอสมควร การทำงานกับบางสิ่งบางอย่างเมื่อคุณรู้จักมันอยู่แล้วนั้นไม่สนุกเท่าไหร่ ดังนั้นเราจะทำเวอร์ชัน Rust แทน ;)
Rust ถือเป็นภาษาโปรแกรมที่ค่อนข้างใหม่ แต่สำหรับฉันแล้ว มันกลายเป็นสิ่งที่น่าสงสัยเมื่อ Linus Torvalds ประกาศว่าเขายอมรับ Rust เป็นภาษาโปรแกรมสำหรับเคอร์เนล Linux สำหรับโปรแกรมเมอร์รุ่นเก่าอย่างเรา นั่นก็เหมือนกับการบอกว่าสิ่งใหม่ในยุคฮิปปี้นี้จะกลายมาเป็นการแก้ไขรัฐธรรมนูญของสหรัฐอเมริกา
ในปัจจุบัน เมื่อคุณเป็นโปรแกรมเมอร์ที่มีประสบการณ์แล้ว คุณมักจะไม่รีบร้อนทำตามกระแสเหมือนกับคนรุ่นใหม่ๆ ไม่เช่นนั้น คุณอาจประสบปัญหาจากการเปลี่ยนแปลงอย่างรวดเร็วของภาษาหรือไลบรารี (ใครก็ตามที่เคยใช้ AngularJS เวอร์ชันแรกจะรู้ว่าฉันกำลังพูดถึงอะไร) Rust ยังคงอยู่ในระยะพัฒนาแบบทดลอง และผมพบว่าเป็นเรื่องตลกที่ตัวอย่างโค้ดจำนวนมากบนเว็บไม่สามารถคอมไพล์ด้วยแพ็คเกจเวอร์ชันปัจจุบันได้อีกต่อไป
อย่างไรก็ตาม ประสิทธิภาพที่แสดงโดยแอปพลิเคชัน Rust นั้นไม่สามารถปฏิเสธได้ หากคุณไม่เคยลอง ริปเกรป หรือ ค้นหา fd คุณควรลองใช้กับซอร์สโค้ดขนาดใหญ่ดู พวกมันมีให้ใช้งานในระบบปฏิบัติการ Linux ส่วนใหญ่ได้จากตัวจัดการแพ็คเกจเท่านั้น คุณกำลังแลกเปลี่ยนความเยิ่นเย้อเพื่อประสิทธิภาพด้วย Rust... มาก ของความเยิ่นเย้อสำหรับ มาก ของประสิทธิภาพการทำงาน
โค้ดทั้งหมดของ Rust นั้นค่อนข้างใหญ่ ดังนั้นเราจะดูเฉพาะตัวจัดการที่เกี่ยวข้องที่นี่:
มันซับซ้อนกว่าเวอร์ชัน Python/Node.js มาก...
และมีประสิทธิภาพมากกว่าเดิมมาก!
เซิร์ฟเวอร์ Rust ของเราซึ่งใช้ Actix/deadpool_postgres เอาชนะแชมป์เก่าอย่าง Starlette ได้อย่างง่ายดายด้วยคะแนน +125%, ExpressJS 362% และ PHP ล้วนๆ 1366% (ผมจะทิ้งคะแนนเดลต้าของประสิทธิภาพไว้กับเวอร์ชัน Laravel เพื่อเป็นการฝึกฝนสำหรับผู้อ่าน)
ฉันพบว่าการเรียนรู้ภาษา Rust นั้นยากกว่าภาษาอื่น ๆ มาก เนื่องจากมีปัญหาต่าง ๆ มากมายมากกว่าภาษาอื่น ๆ ที่ฉันเคยเห็นนอกเหนือจาก 6502 Assembly แต่ถ้าเซิร์ฟเวอร์ Rust ของคุณสามารถรองรับผู้ใช้ได้มากกว่าเซิร์ฟเวอร์ PHP ถึง 14 เท่า ก็อาจมีบางอย่างที่คุณจะได้รับจากการเปลี่ยนเทคโนโลยีก็ได้ นั่นคือเหตุผลที่ Pafera Framework เวอร์ชันถัดไปจะใช้ Rust เป็นพื้นฐาน การเรียนรู้จะเร็วกว่าภาษาสคริปต์มาก แต่ประสิทธิภาพก็คุ้มค่า หากคุณไม่สามารถสละเวลาเพื่อเรียนรู้ Rust ได้ การใช้ Starlette หรือ Node.js เป็นพื้นฐานสำหรับเทคโนโลยีของคุณก็ไม่ใช่การตัดสินใจที่แย่เช่นกัน
ในช่วงยี่สิบปีที่ผ่านมา เราได้เปลี่ยนจากเว็บไซต์โฮสติ้งแบบคงที่ราคาถูกมาเป็นโฮสติ้งแบบแชร์พร้อมสแต็ก LAMP ไปจนถึงการเช่า VPS ให้กับ AWS, Azure และบริการคลาวด์อื่นๆ ปัจจุบัน บริษัทต่างๆ จำนวนมากพอใจกับการตัดสินใจออกแบบโดยพิจารณาจากผู้ที่สามารถหาได้ซึ่งมีให้บริการหรือราคาถูกที่สุด เนื่องจากการถือกำเนิดของบริการคลาวด์ที่สะดวกสบายทำให้การเพิ่มฮาร์ดแวร์ให้กับเซิร์ฟเวอร์และแอปพลิเคชันที่ทำงานช้าเป็นเรื่องง่าย ซึ่งทำให้บริษัทเหล่านี้ได้รับผลกำไรในระยะสั้นจำนวนมากโดยแลกมากับหนี้ทางเทคนิคในระยะยาว
70 ปีที่แล้ว มีการแข่งขันทางอวกาศครั้งใหญ่ระหว่างสหภาพโซเวียตและสหรัฐอเมริกา โซเวียตเป็นฝ่ายชนะในช่วงแรกๆ เกือบทั้งหมด พวกเขามีดาวเทียมดวงแรกในสปุตนิก สุนัขตัวแรกในอวกาศในไลก้า ยานอวกาศลำแรกบนดวงจันทร์ในลูน่า 2 ผู้ชายและผู้หญิงคนแรกในอวกาศในยูริ กาการินและวาเลนตินา เทเรชโควา และอื่นๆ อีกมากมาย...
แต่พวกเขาค่อยๆ สะสมหนี้ทางเทคนิค
แม้ว่าโซเวียตจะเป็นฝ่ายได้เปรียบในความสำเร็จเหล่านี้ แต่กระบวนการทางวิศวกรรมและเป้าหมายของพวกเขากลับทำให้พวกเขามุ่งเน้นไปที่ความท้าทายในระยะสั้นมากกว่าความเป็นไปได้ในระยะยาว พวกเขาชนะทุกครั้งที่กระโดด แต่พวกเขาก็เหนื่อยและช้าลงในขณะที่คู่ต่อสู้ยังคงก้าวเดินอย่างต่อเนื่องเพื่อไปสู่เส้นชัย
เมื่อนีล อาร์มสตรองก้าวขึ้นสู่ดวงจันทร์ในประวัติศาสตร์ทางโทรทัศน์ถ่ายทอดสด ชาวอเมริกันก็ก้าวขึ้นมาเป็นผู้นำ และรักษาตำแหน่งผู้นำไว้ได้ในขณะที่รายการของสหภาพโซเวียตล้มเหลว ซึ่งไม่ต่างจากบริษัทต่างๆ ในปัจจุบันที่มุ่งเน้นไปที่สิ่งที่ยิ่งใหญ่ต่อไป ผลตอบแทนครั้งใหญ่ครั้งต่อไป หรือเทคโนโลยีที่ยิ่งใหญ่ต่อไป แต่ล้มเหลวในการพัฒนาพฤติกรรมและกลยุทธ์ที่เหมาะสมในระยะยาว
การเป็นผู้นำในตลาดไม่ได้หมายความว่าคุณจะกลายเป็นผู้เล่นที่มีอำนาจเหนือตลาดนั้น ในทางกลับกัน การใช้เวลาทำสิ่งต่างๆ อย่างถูกต้องไม่ได้รับประกันความสำเร็จ แต่จะเพิ่มโอกาสในการประสบความสำเร็จในระยะยาวอย่างแน่นอน หากคุณเป็นผู้นำด้านเทคนิคของบริษัท ให้เลือกแนวทางและเครื่องมือที่เหมาะสมกับปริมาณงานของคุณ อย่าปล่อยให้ความนิยมมาแทนที่ประสิทธิภาพและประสิทธิผล
ต้องการดาวน์โหลดไฟล์ 7z ที่มีสคริปต์ Rust, ExpressJS, Flask, Starlette และ Pure PHP หรือไม่
เกี่ยวกับผู้เขียน |
|
![]() |
จิมเริ่มเขียนโปรแกรมมาตั้งแต่ที่เขาได้รับ IBM PS/2 เมื่อช่วงยุค 90 จนถึงทุกวันนี้ เขายังคงชอบเขียน HTML และ SQL ด้วยมือ และมุ่งเน้นที่ประสิทธิภาพและความถูกต้องในการทำงานของเขา |