ปัจจุบันเว็บแอปพลิเคชันถูกนำมาใช้ทุกที่ และในบรรดาโปรโตคอลการขนส่งทั้งหมด HTTP ก็ครองส่วนแบ่งสูงสุด เมื่อศึกษาความแตกต่างของการพัฒนาเว็บแอปพลิเคชัน คนส่วนใหญ่ให้ความสนใจน้อยมากกับระบบปฏิบัติการที่แอปพลิเคชันเหล่านี้ทำงานจริง การแยกฝ่ายพัฒนา (Dev) และฝ่ายปฏิบัติการ (Ops) มีแต่ทำให้สถานการณ์แย่ลงเท่านั้น แต่ด้วยวัฒนธรรม DevOps ที่เพิ่มขึ้น นักพัฒนาต้องรับผิดชอบในการใช้งานแอปพลิเคชันของตนในระบบคลาวด์ ดังนั้นจึงมีประโยชน์มากสำหรับพวกเขาในการทำความคุ้นเคยกับแบ็กเอนด์ของระบบปฏิบัติการอย่างละเอียด สิ่งนี้มีประโยชน์อย่างยิ่งหากคุณพยายามปรับใช้ระบบสำหรับการเชื่อมต่อพร้อมกันนับพันหรือหลายหมื่นครั้ง
ข้อจำกัดในบริการเว็บนั้นคล้ายคลึงกับข้อจำกัดในแอปพลิเคชันอื่นๆ มาก ไม่ว่าจะเป็นโหลดบาลานเซอร์หรือเซิร์ฟเวอร์ฐานข้อมูล แอปพลิเคชันทั้งหมดเหล่านี้มีปัญหาคล้ายกันในสภาพแวดล้อมที่มีประสิทธิภาพสูง การทำความเข้าใจข้อจำกัดพื้นฐานเหล่านี้และวิธีเอาชนะโดยทั่วไปจะช่วยให้คุณประเมินประสิทธิภาพและความสามารถในการปรับขนาดของเว็บแอปพลิเคชันของคุณได้
ฉันกำลังเขียนบทความชุดนี้เพื่อตอบคำถามจากนักพัฒนารุ่นเยาว์ที่ต้องการเป็นสถาปนิกระบบที่มีข้อมูลครบถ้วน เป็นไปไม่ได้ที่จะเข้าใจเทคนิคการเพิ่มประสิทธิภาพแอปพลิเคชัน Linux อย่างชัดเจนโดยไม่ต้องเจาะลึกถึงพื้นฐานของวิธีการทำงานในระดับระบบปฏิบัติการ แม้ว่าจะมีแอปพลิเคชันหลายประเภท แต่ในชุดนี้ ฉันต้องการสำรวจแอปพลิเคชันบนเว็บมากกว่าแอปพลิเคชันบนเดสก์ท็อป เช่น เบราว์เซอร์หรือโปรแกรมแก้ไขข้อความ เนื้อหานี้มีไว้สำหรับนักพัฒนาและสถาปนิกที่ต้องการทำความเข้าใจวิธีการทำงานของโปรแกรม Linux หรือ Unix และวิธีจัดโครงสร้างโปรแกรมให้มีประสิทธิภาพสูง
ลินุกซ์ก็คือ ห้องเซิร์ฟเวอร์ ระบบปฏิบัติการ และบ่อยครั้งที่แอปพลิเคชันของคุณทำงานบนระบบปฏิบัติการนี้ แม้ว่าฉันจะพูดว่า "Linux" แต่โดยส่วนใหญ่คุณสามารถสรุปได้อย่างปลอดภัยว่าฉันหมายถึงระบบปฏิบัติการที่คล้ายกับ Unix ทั้งหมดโดยทั่วไป อย่างไรก็ตาม ฉันยังไม่ได้ทดสอบโค้ดที่แนบมากับระบบอื่น ดังนั้น หากคุณสนใจ FreeBSD หรือ OpenBSD ผลลัพธ์ของคุณอาจแตกต่างกันไป เมื่อฉันลองทำบางอย่างเฉพาะสำหรับ Linux ฉันจะชี้ให้เห็น
แม้ว่าคุณสามารถใช้ความรู้นี้เพื่อสร้างแอปตั้งแต่เริ่มต้นและจะได้รับการปรับให้เหมาะสมที่สุด แต่ก็ไม่ควรทำเช่นนั้น หากคุณเขียนเว็บเซิร์ฟเวอร์ใหม่ใน C หรือ C++ สำหรับแอปพลิเคชันทางธุรกิจขององค์กรของคุณ นี่อาจเป็นวันสุดท้ายในการทำงานของคุณ อย่างไรก็ตาม การทราบโครงสร้างของแอปพลิเคชันเหล่านี้จะช่วยในการเลือกโปรแกรมที่มีอยู่ คุณจะสามารถเปรียบเทียบระบบตามกระบวนการกับระบบตามเธรดและระบบตามเหตุการณ์ได้ คุณจะเข้าใจและเข้าใจว่าทำไม Nginx จึงทำงานได้ดีกว่า Apache httpd เหตุใดแอปพลิเคชัน Python ที่ใช้ Tornado จึงสามารถให้บริการผู้ใช้ได้มากกว่าเมื่อเปรียบเทียบกับแอปพลิเคชัน Python ที่ใช้ Django
ZeroHTTPd: เครื่องมือการเรียนรู้
เป็นเว็บเซิร์ฟเวอร์ที่ฉันเขียนตั้งแต่ต้นด้วยภาษา C เพื่อเป็นเครื่องมือในการสอน ไม่มีการพึ่งพาภายนอก รวมถึงการเข้าถึง Redis เราดำเนินการขั้นตอน Redis ของเราเอง ดูด้านล่างสำหรับรายละเอียดเพิ่มเติม
แม้ว่าเราจะพูดคุยกันถึงทฤษฎีในวงกว้าง แต่ก็ไม่มีอะไรดีไปกว่าการเขียนโค้ด การรันมัน และการเปรียบเทียบสถาปัตยกรรมเซิร์ฟเวอร์ทั้งหมดด้วยกัน นี่เป็นวิธีที่ชัดเจนที่สุด ดังนั้น เราจะเขียนเว็บเซิร์ฟเวอร์ ZeroHTTPd แบบธรรมดาโดยใช้แต่ละรุ่น: ตามกระบวนการ ตามเธรด และตามเหตุการณ์ มาดูเซิร์ฟเวอร์แต่ละเครื่องกันและดูว่าพวกเขาทำงานเป็นอย่างไรบ้างเมื่อเปรียบเทียบกัน ZeroHTTPd ถูกนำไปใช้ในไฟล์ C เดียว เซิร์ฟเวอร์ตามเหตุการณ์ประกอบด้วย ซึ่งเป็นการใช้ตารางแฮชที่ยอดเยี่ยมที่มาในไฟล์ส่วนหัวเดียว ในกรณีอื่นๆ จะไม่มีการพึ่งพา เพื่อไม่ให้โครงการซับซ้อน
มีความคิดเห็นมากมายในโค้ดเพื่อช่วยให้คุณเข้าใจ เนื่องจากเป็นเว็บเซิร์ฟเวอร์ที่เรียบง่ายโดยใช้โค้ดเพียงไม่กี่บรรทัด ZeroHTTPd จึงเป็นเฟรมเวิร์กขั้นต่ำสำหรับการพัฒนาเว็บ มีฟังก์ชันการทำงานที่จำกัด แต่สามารถให้บริการไฟล์คงที่และหน้า "ไดนามิก" ที่เรียบง่ายได้ ฉันต้องบอกว่า ZeroHTTPd นั้นดีสำหรับการเรียนรู้วิธีสร้างแอปพลิเคชั่น Linux ประสิทธิภาพสูง โดยทั่วไปแล้ว บริการบนเว็บส่วนใหญ่จะรอคำขอ ตรวจสอบและดำเนินการ นี่คือสิ่งที่ ZeroHTTPd จะทำ นี่เป็นเครื่องมือสำหรับการเรียนรู้ ไม่ใช่การผลิต การจัดการข้อผิดพลาดทำได้ไม่ดีนักและไม่น่าจะมีแนวปฏิบัติด้านความปลอดภัยที่ดีที่สุด (โอ้ ใช่แล้ว ฉันใช้แล้ว strcpy) หรือกลเม็ดอันชาญฉลาดของภาษา C แต่ฉันหวังว่ามันจะทำงานได้ดี
หน้าแรกของ ZeroHTTPd สามารถส่งออกไฟล์ประเภทต่าง ๆ รวมถึงรูปภาพ
ใบสมัครสมุดเยี่ยม
เว็บแอปพลิเคชันสมัยใหม่มักไม่ได้จำกัดอยู่เพียงไฟล์คงที่ มีการโต้ตอบที่ซับซ้อนกับฐานข้อมูล แคช ฯลฯ ต่างๆ ดังนั้นเราจะสร้างเว็บแอปพลิเคชันง่ายๆ ที่เรียกว่า "สมุดเยี่ยม" ซึ่งผู้เยี่ยมชมจะทิ้งรายการไว้ใต้ชื่อของพวกเขา สมุดเยี่ยมจะจัดเก็บรายการที่เหลือไว้ก่อนหน้านี้ นอกจากนี้ยังมีเคาน์เตอร์ผู้เยี่ยมชมที่ด้านล่างของหน้า
เว็บแอปพลิเคชัน "สมุดเยี่ยม" ZeroHTTPd
รายการเคาน์เตอร์ผู้เยี่ยมชมและสมุดเยี่ยมจะถูกจัดเก็บไว้ใน Redis สำหรับการสื่อสารกับ Redis จะมีการนำขั้นตอนของตัวเองไปใช้ โดยไม่ได้ขึ้นอยู่กับไลบรารีภายนอก ฉันไม่ใช่แฟนตัวยงของการเปิดตัวโค้ด homebrew เมื่อมีโซลูชันที่เปิดเผยต่อสาธารณะและผ่านการทดสอบอย่างดี แต่วัตถุประสงค์ของ ZeroHTTPd คือเพื่อศึกษาประสิทธิภาพของ Linux และการเข้าถึงบริการภายนอก ในขณะที่การให้บริการคำขอ HTTP มีผลกระทบต่อประสิทธิภาพที่ร้ายแรง เราต้องควบคุมการสื่อสารกับ Redis อย่างสมบูรณ์ในสถาปัตยกรรมเซิร์ฟเวอร์แต่ละตัวของเรา ในบางสถาปัตยกรรมเราใช้การบล็อกการโทร ในบางสถาปัตยกรรมเราใช้ขั้นตอนตามเหตุการณ์ การใช้ไลบรารีไคลเอ็นต์ Redis ภายนอกจะไม่ให้การควบคุมนี้ นอกจากนี้ ไคลเอนต์ Redis ตัวน้อยของเรายังทำหน้าที่เพียงไม่กี่อย่างเท่านั้น (รับ การตั้งค่า และการเพิ่มคีย์ การรับและผนวกเข้ากับอาร์เรย์) นอกจากนี้ โปรโตคอล Redis ยังสง่างามและเรียบง่ายอย่างยิ่ง คุณไม่จำเป็นต้องสอนมันเป็นพิเศษด้วยซ้ำ ความจริงที่ว่าโปรโตคอลทำงานทั้งหมดโดยใช้โค้ดประมาณร้อยบรรทัดแสดงให้เห็นว่าความคิดนั้นดีเพียงใด
รูปภาพต่อไปนี้แสดงสิ่งที่แอปพลิเคชันทำเมื่อไคลเอนต์ (เบราว์เซอร์) ร้องขอ /guestbookURL.
แอปพลิเคชันสมุดเยี่ยมทำงานอย่างไร
เมื่อจำเป็นต้องออกหน้าสมุดเยี่ยมชม มีการเรียกระบบไฟล์หนึ่งครั้งเพื่ออ่านเทมเพลตลงในหน่วยความจำ และการเรียกเครือข่ายสามครั้งไปยัง Redis ไฟล์เทมเพลตประกอบด้วยเนื้อหา HTML ส่วนใหญ่สำหรับหน้าในภาพหน้าจอด้านบน นอกจากนี้ยังมีตัวยึดตำแหน่งพิเศษสำหรับส่วนไดนามิกของเนื้อหา: โพสต์และตัวนับผู้เยี่ยมชม เราได้รับจาก Redis แทรกลงในเพจและจัดเตรียมเนื้อหาที่มีรูปแบบครบถ้วนให้กับลูกค้า สามารถหลีกเลี่ยงการเรียก Redis ครั้งที่สามได้เนื่องจาก Redis จะส่งกลับค่าคีย์ใหม่เมื่อเพิ่มขึ้น อย่างไรก็ตาม สำหรับเซิร์ฟเวอร์ของเราซึ่งมีสถาปัตยกรรมตามเหตุการณ์แบบอะซิงโครนัส การโทรผ่านเครือข่ายจำนวนมากถือเป็นการทดสอบที่ดีสำหรับจุดประสงค์ในการเรียนรู้ ดังนั้นเราจึงละทิ้งค่าตอบแทน Redis ของจำนวนผู้เยี่ยมชมและสอบถามด้วยการโทรแยกต่างหาก
สถาปัตยกรรมเซิร์ฟเวอร์ ZeroHTTPd
เรากำลังสร้าง ZeroHTTPd เจ็ดเวอร์ชันที่มีฟังก์ชันการทำงานเหมือนกัน แต่มีสถาปัตยกรรมที่แตกต่างกัน:
- วนซ้ำ
- เซิร์ฟเวอร์ Fork (หนึ่งกระบวนการลูกต่อคำขอ)
- เซิร์ฟเวอร์ Pre-fork (การฟอร์กกระบวนการล่วงหน้า)
- เซิร์ฟเวอร์ที่มีเธรดการดำเนินการ (หนึ่งเธรดต่อคำขอ)
- เซิร์ฟเวอร์ที่มีการสร้างเธรดล่วงหน้า
- ตามสถาปัตยกรรม
poll() - ตามสถาปัตยกรรม
epoll
เราวัดประสิทธิภาพของแต่ละสถาปัตยกรรมโดยการโหลดเซิร์ฟเวอร์ด้วยคำขอ HTTP แต่เมื่อเปรียบเทียบสถาปัตยกรรมแบบขนานสูง จำนวนคำค้นหาก็เพิ่มขึ้น เราทดสอบสามครั้งและคำนวณค่าเฉลี่ย
วิธีการทดสอบ
การตั้งค่าการทดสอบโหลด ZeroHTTPd
สิ่งสำคัญคือเมื่อทำการทดสอบ ส่วนประกอบทั้งหมดจะไม่ทำงานบนเครื่องเดียวกัน ในกรณีนี้ ระบบปฏิบัติการจะมีค่าใช้จ่ายในการกำหนดเวลาเพิ่มเติมเนื่องจากส่วนประกอบต่างๆ แย่งชิง CPU การวัดค่าใช้จ่ายระบบปฏิบัติการของสถาปัตยกรรมเซิร์ฟเวอร์แต่ละตัวที่เลือกเป็นหนึ่งในเป้าหมายที่สำคัญที่สุดของแบบฝึกหัดนี้ การเพิ่มตัวแปรเข้าไปจะส่งผลเสียต่อกระบวนการ ดังนั้นการตั้งค่าในภาพด้านบนจึงใช้งานได้ดีที่สุด
แต่ละเซิร์ฟเวอร์เหล่านี้ทำอะไร?
- load.unixism.net: นี่คือที่ที่เราดำเนินการ
ab, ยูทิลิตี้ Apache Benchmark มันสร้างภาระที่จำเป็นในการทดสอบสถาปัตยกรรมเซิร์ฟเวอร์ของเรา - nginx.unixism.net: บางครั้งเราต้องการเรียกใช้โปรแกรมเซิร์ฟเวอร์มากกว่าหนึ่งอินสแตนซ์ ในการทำเช่นนี้เซิร์ฟเวอร์ Nginx ที่มีการตั้งค่าที่เหมาะสมจะทำงานเป็นโหลดบาลานเซอร์ที่มาจาก ab ไปยังกระบวนการเซิร์ฟเวอร์ของเรา
- zerohttpd.unixism.net: ที่นี่เรารันโปรแกรมเซิร์ฟเวอร์ของเราบนสถาปัตยกรรมที่แตกต่างกันเจ็ดแบบ ทีละตัว
- redis.unixism.net: เซิร์ฟเวอร์นี้รัน Redis daemon ซึ่งจัดเก็บรายการสมุดเยี่ยมและตัวนับผู้เยี่ยมชม
เซิร์ฟเวอร์ทั้งหมดทำงานบนแกนประมวลผลเดียวกัน แนวคิดคือการประเมินประสิทธิภาพสูงสุดของแต่ละสถาปัตยกรรม เนื่องจากโปรแกรมเซิร์ฟเวอร์ทั้งหมดได้รับการทดสอบบนฮาร์ดแวร์เดียวกัน นี่เป็นพื้นฐานสำหรับการเปรียบเทียบ การตั้งค่าการทดสอบของฉันประกอบด้วยเซิร์ฟเวอร์เสมือนที่เช่าจาก Digital Ocean
เรากำลังวัดอะไร?
คุณสามารถวัดตัวชี้วัดต่างๆ ได้ เราประเมินประสิทธิภาพของแต่ละสถาปัตยกรรมในการกำหนดค่าที่กำหนดโดยการโหลดเซิร์ฟเวอร์พร้อมกับคำขอในระดับความขนานที่แตกต่างกัน: โหลดเพิ่มขึ้นจาก 20 ถึง 15 ผู้ใช้พร้อมกัน
ผลการทดสอบ
แผนภูมิต่อไปนี้แสดงประสิทธิภาพของเซิร์ฟเวอร์บนสถาปัตยกรรมที่แตกต่างกันในระดับความขนานที่แตกต่างกัน แกน y คือจำนวนคำขอต่อวินาที แกน x คือการเชื่อมต่อแบบขนาน
ด้านล่างเป็นตารางพร้อมผลลัพธ์
คำขอต่อวินาที
ความเท่าเทียมกัน
วนซ้ำ
ส้อม
ก่อนส้อม
สตรีมมิ่ง
ก่อนสตรีมมิ่ง
มา
โพล
20
7
112
2100
1800
2250
1900
2050
50
7
190
2200
1700
2200
2000
2000
100
7
245
2200
1700
2200
2150
2100
200
7
330
2300
1750
2300
2200
2100
300
-
380
2200
1800
2400
2250
2150
400
-
410
2200
1750
2600
2000
2000
500
-
440
2300
1850
2700
1900
2212
600
-
460
2400
1800
2500
1700
2519
700
-
460
2400
1600
2490
1550
2607
800
-
460
2400
1600
2540
1400
2553
900
-
460
2300
1600
2472
1200
2567
1000
-
475
2300
1700
2485
1150
2439
1500
-
490
2400
1550
2620
900
2479
2000
-
350
2400
1400
2396
550
2200
2500
-
280
2100
1300
2453
490
2262
3000
-
280
1900
1250
2502
การแพร่กระจายครั้งใหญ่
2138
5000
-
การแพร่กระจายครั้งใหญ่
1600
1100
2519
-
2235
8000
-
-
1200
การแพร่กระจายครั้งใหญ่
2451
-
2100
10
-
-
การแพร่กระจายครั้งใหญ่
-
2200
-
2200
11
-
-
-
-
2200
-
2122
12
-
-
-
-
970
-
1958
13
-
-
-
-
730
-
1897
14
-
-
-
-
590
-
1466
15
-
-
-
-
532
-
1281
จากกราฟและตารางจะเห็นได้ว่าคำขอพร้อมกันมากกว่า 8000 รายการเรามีผู้เล่นเหลือเพียงสองคน: pre-fork และ epoll เมื่อโหลดเพิ่มขึ้น เซิร์ฟเวอร์แบบสำรวจความคิดเห็นจะทำงานได้แย่กว่าเซิร์ฟเวอร์แบบสตรีมมิ่ง สถาปัตยกรรมก่อนการสร้างเธรดเป็นคู่แข่งที่คุ้มค่าสำหรับ epoll ซึ่งเป็นเครื่องพิสูจน์ว่าเคอร์เนล Linux กำหนดเวลาเธรดจำนวนมากได้ดีเพียงใด
ซอร์สโค้ด ZeroHTTPd
ซอร์สโค้ด ZeroHTTPd . มีไดเร็กทอรีแยกต่างหากสำหรับแต่ละสถาปัตยกรรม
ZeroHTTPd │ ├── 01_iterative │ ├── main.c ├── 02_forking │ ├── main.c ├── 03_preforking │ ├── main.c ├── 04_ เธรด │ ├── main.c ├── 05_prethreading │ ├── main.c ├── 06_poll │ ├── main.c ├── 07_epoll │ └── main.c ├── Makefile ├── สาธารณะ │ ├── ดัชนี .html │ └── tux . png └── เทมเพลต └── สมุดเยี่ยม └── index.html
นอกเหนือจากเจ็ดไดเรกทอรีสำหรับสถาปัตยกรรมทั้งหมดแล้ว ยังมีอีกสองไดเรกทอรีในไดเรกทอรีระดับบนสุด: สาธารณะและเทมเพลต ไฟล์แรกประกอบด้วยไฟล์ index.html และรูปภาพจากภาพหน้าจอแรก คุณสามารถวางไฟล์และโฟลเดอร์อื่นๆ ไว้ที่นั่นได้ และ ZeroHTTPd ควรให้บริการไฟล์คงที่เหล่านั้นโดยไม่มีปัญหาใดๆ หากเส้นทางในเบราว์เซอร์ตรงกับเส้นทางในโฟลเดอร์สาธารณะ ZeroHTTPd จะค้นหาไฟล์ index.html ในไดเร็กทอรีนี้ เนื้อหาสำหรับสมุดเยี่ยมจะถูกสร้างขึ้นแบบไดนามิก มีเพียงหน้าแรกเท่านั้น และเนื้อหาจะขึ้นอยู่กับไฟล์ 'templates/guestbook/index.html' ZeroHTTPd เพิ่มหน้าไดนามิกสำหรับส่วนขยายได้อย่างง่ายดาย แนวคิดก็คือผู้ใช้สามารถเพิ่มเทมเพลตลงในไดเร็กทอรีนี้และขยาย ZeroHTTPd ได้ตามต้องการ
หากต้องการสร้างเซิร์ฟเวอร์ทั้งเจ็ด ให้รัน make all จากไดเร็กทอรีระดับบนสุด - และบิลด์ทั้งหมดจะปรากฏในไดเร็กทอรีนี้ ไฟล์ปฏิบัติการจะค้นหาไดเร็กทอรีสาธารณะและไดเร็กทอรีเทมเพลตในไดเร็กทอรีที่เรียกใช้งาน
ลินุกซ์ API
คุณไม่จำเป็นต้องเชี่ยวชาญ Linux API เป็นอย่างดีเพื่อทำความเข้าใจข้อมูลในชุดบทความนี้ อย่างไรก็ตาม ฉันขอแนะนำให้อ่านเพิ่มเติมในหัวข้อนี้ มีแหล่งข้อมูลอ้างอิงมากมายบนอินเทอร์เน็ต แม้ว่าเราจะกล่าวถึง Linux API หลายประเภท แต่เราจะมุ่งเน้นไปที่กระบวนการ เธรด เหตุการณ์ และสแต็กเครือข่ายเป็นหลัก นอกจากหนังสือและบทความเกี่ยวกับ Linux API แล้ว ฉันยังแนะนำให้อ่านมานาสำหรับการเรียกระบบและฟังก์ชันไลบรารีที่ใช้อีกด้วย
ประสิทธิภาพและความสามารถในการขยายขนาด
หมายเหตุประการหนึ่งเกี่ยวกับประสิทธิภาพและความสามารถในการปรับขนาด ตามทฤษฎีแล้ว ไม่มีความเชื่อมโยงระหว่างกัน คุณสามารถมีบริการเว็บที่ทำงานได้ดีมาก โดยมีเวลาตอบสนองเพียงไม่กี่มิลลิวินาที แต่ไม่ได้ปรับขนาดเลย ในทำนองเดียวกัน อาจมีเว็บแอปพลิเคชันที่มีประสิทธิภาพต่ำซึ่งใช้เวลาตอบสนองไม่กี่วินาที แต่จะปรับขนาดเป็นสิบเพื่อรองรับผู้ใช้นับหมื่นพร้อมกัน อย่างไรก็ตาม การผสมผสานระหว่างประสิทธิภาพสูงและความสามารถในการขยายขนาดเป็นการผสมผสานที่ทรงพลังมาก โดยทั่วไปแอปพลิเคชันประสิทธิภาพสูงจะใช้ทรัพยากรเท่าที่จำเป็น จึงให้บริการผู้ใช้พร้อมกันบนเซิร์ฟเวอร์ได้มากขึ้น ซึ่งช่วยลดต้นทุน
งาน CPU และ I/O
สุดท้ายนี้ ในการคำนวณมักจะมีงานที่เป็นไปได้สองประเภทเสมอ: สำหรับ I/O และ CPU การรับคำขอทางอินเทอร์เน็ต (I/O เครือข่าย) การให้บริการไฟล์ (เครือข่ายและ I/O ดิสก์) การสื่อสารกับฐานข้อมูล (I/O เครือข่ายและดิสก์) ถือเป็นกิจกรรม I/O ทั้งหมด การสืบค้นฐานข้อมูลบางรายการอาจใช้ CPU มากเล็กน้อย (การเรียงลำดับ การหาผลลัพธ์โดยเฉลี่ยล้านรายการ ฯลฯ) เว็บแอปพลิเคชันส่วนใหญ่ถูกจำกัดด้วย I/O สูงสุดที่เป็นไปได้ และแทบไม่ได้ใช้โปรเซสเซอร์อย่างเต็มประสิทธิภาพ เมื่อคุณเห็นว่างาน I/O บางอย่างใช้ CPU จำนวนมาก เป็นไปได้มากว่าอาจเป็นสัญญาณของสถาปัตยกรรมแอปพลิเคชันที่ไม่ดี ซึ่งอาจหมายความว่าทรัพยากร CPU สูญเปล่าไปกับการจัดการกระบวนการและการสลับบริบท และไม่มีประโยชน์เลย หากคุณกำลังทำอะไรบางอย่าง เช่น การประมวลผลภาพ การแปลงไฟล์เสียง หรือการเรียนรู้ของเครื่อง แอปพลิเคชันต้องใช้ทรัพยากร CPU ที่ทรงพลัง แต่สำหรับการใช้งานส่วนใหญ่จะไม่เป็นเช่นนั้น
เรียนรู้เพิ่มเติมเกี่ยวกับสถาปัตยกรรมเซิร์ฟเวอร์
ที่มา: will.com