Apache Bench - คู่มือฉบับย่อ

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

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

ต้องการเครื่องมือทดสอบการโหลด

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

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

Apache Bench คืออะไร?

Apache Bench (ab) เป็นเครื่องมือจากองค์กร Apache สำหรับการเปรียบเทียบเว็บเซิร์ฟเวอร์ Hypertext Transfer Protocol (HTTP) แม้ว่าจะได้รับการออกแบบมาเพื่อวัดประสิทธิภาพของเว็บเซิร์ฟเวอร์ Apache แต่ก็ยังสามารถใช้ทดสอบเว็บเซิร์ฟเวอร์อื่น ๆ ที่ดีไม่แพ้กัน ด้วยเครื่องมือนี้คุณสามารถทราบได้อย่างรวดเร็วว่าเว็บเซิร์ฟเวอร์ของคุณสามารถให้บริการได้กี่คำขอต่อวินาที

คุณสมบัติของ Apache Bench

ให้เราดูคุณสมบัติที่สำคัญและข้อ จำกัด ของ Apache Bench คุณสมบัติและข้อ จำกัด แสดงอยู่ด้านล่าง -

• ในฐานะที่เป็นซอฟต์แวร์โอเพ่นซอร์สจึงสามารถใช้ได้อย่างอิสระ

• มันเป็นโปรแกรมคอมพิวเตอร์บรรทัดคำสั่งง่ายๆ

• เป็นเครื่องมือที่ไม่ขึ้นกับแพลตฟอร์ม หมายความว่าสามารถเรียกใช้บน Linux / Unix หรือบนเซิร์ฟเวอร์ Windows ได้ดีพอ ๆ กัน

• สามารถทำการทดสอบโหลดและประสิทธิภาพสำหรับเว็บเซิร์ฟเวอร์เท่านั้น - HTTP หรือ HTTPS

• ไม่สามารถขยายได้

Apache Bench ใช้เธรดระบบปฏิบัติการเดียวโดยไม่คำนึงถึงระดับการทำงานพร้อมกัน (ระบุโดยแฟล็ก -c) ดังนั้นเมื่อเปรียบเทียบเซิร์ฟเวอร์ความจุสูง Apache Bench อินสแตนซ์เดียวอาจเป็นปัญหาคอขวดได้ เพื่อให้ URL เป้าหมายอิ่มตัวอย่างสมบูรณ์ควรใช้อินสแตนซ์เพิ่มเติมของ Apache Bench ควบคู่กันไปจะดีกว่าหากเซิร์ฟเวอร์ของคุณมีแกนประมวลผลหลายตัว

ข้อควรระวัง

คุณต้องทราบว่าไม่มีคำสั่งใด ๆ ใน Apache Bench ที่จะเพิ่มการทำงานพร้อมกันในช่วงเวลาใดช่วงเวลาหนึ่งขณะทำการทดสอบ ดังนั้นการรันการทดสอบโหลดโดยใช้ ab จึงเทียบเท่ากับการโจมตีแบบปฏิเสธการให้บริการ (DOS) ขอแนะนำให้คุณแจ้งและรับการอนุญาตล่วงหน้าจากผู้ให้บริการ VPS ของคุณหากคุณกำลังจะทำการทดสอบงานหนักเป็นเวลานาน พวกเขาจะจัดสรรช่วงเวลาที่เหมาะสมให้คุณหรือเปลี่ยนโหนดของคุณสำหรับงานทดสอบโหลด

ประการที่สองหากคุณกำลังทดสอบเว็บไซต์ของบุคคลที่สามอย่างต่อเนื่องและเป็นเวลานานเพียงเพื่อเรียนรู้ Apache Bench จาก VPS ของคุณ (ซึ่งกลายเป็นโหนดทดสอบ) มีความเป็นไปได้จากระยะไกลที่ IP สาธารณะ VPS ของคุณอาจถูกบล็อกโดยเว็บไซต์ของบุคคลที่สาม ถาวร ในกรณีนี้คุณจะไม่สามารถเชื่อมต่อกับเว็บไซต์นั้นด้วย IP เดียวกันได้ แต่ถ้าคุณต้องการเชื่อมต่อกับเว็บไซต์จริงๆในอนาคตทางออกเดียวคือคุยกับผู้ดูแลระบบของเว็บไซต์เป้าหมายหรือสร้างอินสแตนซ์ใหม่ของเซิร์ฟเวอร์ด้วย IP อื่นด้วยความช่วยเหลือจากผู้ให้บริการ VPS ของคุณ

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

ในบทนี้เราจะแนะนำวิธีตั้งค่าสภาพแวดล้อมสำหรับ Apache Bench บน VPS ของคุณ

ความต้องการของระบบ

• Memory - 128 ล้านบาท

• Disk Space - ไม่มีข้อกำหนดขั้นต่ำ

• Operating System - ไม่มีข้อกำหนดขั้นต่ำ

การติดตั้ง Apache Bench

Apache Bench เป็นแอปพลิเคชันแบบสแตนด์อะโลนและไม่มีการพึ่งพาการติดตั้งเว็บเซิร์ฟเวอร์ Apache ต่อไปนี้เป็นกระบวนการสองขั้นตอนในการติดตั้ง Apache Bench

Step 1 - อัปเดตฐานข้อมูลแพ็คเกจ

# apt-get update

โปรดทราบว่าสัญลักษณ์ # ก่อนคำสั่งเทอร์มินัลหมายความว่าผู้ใช้รูทกำลังออกคำสั่งนั้น

Step 2 - ติดตั้งแพ็คเกจ apache2 utils เพื่อเข้าถึง Apache Bench

# apt-get install apache2-utils

ตอนนี้ติดตั้ง Apache Bench แล้ว หากคุณต้องการทดสอบเว็บแอปพลิเคชันที่โฮสต์บน VPS เดียวกันก็เพียงพอที่จะติดตั้งเว็บเซิร์ฟเวอร์ Apache เท่านั้น -

# apt-get install apache2

ในฐานะยูทิลิตี้ Apache Apache Bench จะถูกติดตั้งโดยอัตโนมัติเมื่อติดตั้งเว็บเซิร์ฟเวอร์ Apache

การตรวจสอบการติดตั้ง Apache Bench

ตอนนี้ให้เราดูวิธีตรวจสอบการติดตั้ง Apache Bench รหัสต่อไปนี้จะช่วยตรวจสอบการติดตั้ง -

# ab -V

Output

This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

เมื่อคุณเห็นเอาต์พุตเทอร์มินัลด้านบนหมายความว่าคุณติดตั้ง Apache Bench สำเร็จแล้ว

การสร้างผู้ใช้ Sudo ที่มีสิทธิ์

จากมุมมองด้านความปลอดภัยถือว่าเป็นแนวทางปฏิบัติที่ดีสำหรับผู้ดูแลระบบในการสร้างผู้ใช้ sudo แทนที่จะทำงานเป็นรูท เราจะสร้างผู้ใช้ทดสอบชื่อการทดสอบเพื่อจุดประสงค์ -

# useradd -m -d /home/test -g sudo test

ให้เราตั้งรหัสผ่านสำหรับผู้ใช้ใหม่ -

# passwd test

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

Output

Enter new UNIX password:
Retype new UNIX password:   
passwd: password updated successfully

ทดสอบเว็บไซต์ Apache.org

ในส่วนนี้เราจะทดสอบเว็บไซต์ Apache.org ให้เราเปลี่ยนไปใช้การทดสอบผู้ใช้ sudo ก่อน -

# su test

ในการเริ่มต้นเราจะทดสอบเว็บไซต์ขององค์กร Apache https://www.apache.org/. ก่อนอื่นเราจะเรียกใช้คำสั่งจากนั้นทำความเข้าใจกับผลลัพธ์ -

$ ab -n 100 -c 10 https://www.apache.org/

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

และ -cคือการเกิดขึ้นพร้อมกันและหมายถึงจำนวนคำขอหลายรายการที่จะดำเนินการในแต่ละครั้ง ดีฟอลต์คือหนึ่งคำขอในแต่ละครั้ง

ดังนั้นในการทดสอบนี้ Apache Bench จะส่งคำขอ 100 คำขอพร้อมกัน 10 ไปยังเซิร์ฟเวอร์ขององค์กร Apache

Output

This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking www.apache.org (be patient).....done

Server Software:        Apache/2.4.7
Server Hostname:        www.apache.org
Server Port:            443
SSL/TLS Protocol:       TLSv1.2,ECDHE-RSA-AES256-GCM-SHA384,2048,256

Document Path:          /
Document Length:        58769 bytes

Concurrency Level:      10
Time taken for tests:   1.004 seconds
Complete requests:      100
Failed requests:        0
Total transferred:      5911100 bytes
HTML transferred:       5876900 bytes
Requests per second:    99.56 [#/sec] (mean)
Time per request:       100.444 [ms] (mean)
Time per request:       10.044 [ms] (mean, across all concurrent requests)
Transfer rate:          5747.06 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       39   46  30.9     41     263
Processing:    37   40  21.7     38     255
Waiting:       12   15  21.7     13     230
Total:         77   86  37.5     79     301

Percentage of the requests served within a certain time (ms)
  50%     79
  66%     79
  75%     80
  80%     80
  90%     82
  95%     84
  98%    296
  99%    301
 100%    301 (longest request)

หลังจากเรียกใช้การทดสอบครั้งแรกของเรามันจะง่ายต่อการจดจำรูปแบบการใช้งานสำหรับคำสั่งนี้ซึ่งมีดังนี้ -

# ab [options .....]  URL

ที่ไหน

• ab - คำสั่ง Apache Bench

• options - แฟล็กสำหรับงานเฉพาะที่เราต้องการดำเนินการ

• URL - url เส้นทางที่เราต้องการทดสอบ

ทำความเข้าใจเกี่ยวกับค่าผลลัพธ์

เราจำเป็นต้องเข้าใจเมตริกต่างๆเพื่อทำความเข้าใจค่าเอาต์พุตต่างๆที่ส่งคืนโดย ab นี่คือรายการ -

• Server Software - เป็นชื่อของเว็บเซิร์ฟเวอร์ที่ส่งคืนในส่วนหัว HTTP ของการส่งคืนครั้งแรกที่สำเร็จ

• Server Hostname - เป็น DNS หรือที่อยู่ IP ที่ระบุในบรรทัดคำสั่ง

• Server Port- เป็นพอร์ตที่ ab กำลังเชื่อมต่อ หากไม่มีการกำหนดพอร์ตในบรรทัดคำสั่งค่านี้จะเป็น 80 สำหรับ http และ 443 สำหรับ https

• SSL/TLS Protocol- นี่คือพารามิเตอร์โปรโตคอลที่เจรจาระหว่างไคลเอนต์และเซิร์ฟเวอร์ สิ่งนี้จะถูกพิมพ์เมื่อใช้ SSL เท่านั้น

• Document Path - นี่คือ URI คำขอที่แยกวิเคราะห์จากสตริงบรรทัดคำสั่ง

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

• Concurrency Level - นี่คือจำนวนไคลเอนต์พร้อมกัน (เทียบเท่ากับเว็บเบราว์เซอร์) ที่ใช้ระหว่างการทดสอบ

• Time Taken for Tests - นี่คือเวลาที่ใช้ตั้งแต่วินาทีที่สร้างการเชื่อมต่อซ็อกเก็ตแรกจนถึงช่วงเวลาที่ได้รับการตอบกลับล่าสุด

• Complete Requests - จำนวนคำตอบที่ประสบความสำเร็จที่ได้รับ

• Failed Requests- จำนวนคำขอที่ถือว่าล้มเหลว หากจำนวนมากกว่าศูนย์จะมีการพิมพ์อีกบรรทัดเพื่อแสดงจำนวนคำขอที่ล้มเหลวเนื่องจากการเชื่อมต่อการอ่านความยาวของเนื้อหาไม่ถูกต้องหรือข้อยกเว้น

• Total Transferred- จำนวนไบต์ทั้งหมดที่ได้รับจากเซิร์ฟเวอร์ ตัวเลขนี้เป็นจำนวนไบต์ที่ส่งผ่านสาย

• HTML Transferred- จำนวนไบต์เอกสารทั้งหมดที่ได้รับจากเซิร์ฟเวอร์ จำนวนนี้ไม่รวมไบต์ที่ได้รับในส่วนหัว HTTP

• Requests per second- นี่คือจำนวนคำขอต่อวินาที ค่านี้เป็นผลมาจากการหารจำนวนคำขอด้วยเวลาทั้งหมดที่ดำเนินการ

• Time per request- เวลาเฉลี่ยที่ใช้ต่อคำขอ ค่าแรกคำนวณด้วยสูตรพร้อมกัน * เวลาถ่าย * 1000 / เสร็จสิ้นในขณะที่ค่าที่สองคำนวณด้วยสูตรเวลาถ่าย * 1000 / เสร็จสิ้น

• Transfer rate - อัตราการถ่ายโอนที่คำนวณโดยสูตร totalread / 1024 / Timetaken

การวิเคราะห์ผลการทดสอบโหลดอย่างรวดเร็ว

เมื่อได้เรียนรู้เกี่ยวกับส่วนหัวของค่าเอาต์พุตจากคำสั่ง ab แล้วให้เราลองวิเคราะห์และทำความเข้าใจค่าเอาต์พุตสำหรับการทดสอบเริ่มต้นของเรา -

• องค์กร Apache ใช้ซอฟต์แวร์เซิร์ฟเวอร์เว็บของตนเอง - Apache (เวอร์ชัน 2.4.7)

• เซิร์ฟเวอร์กำลังฟังบนพอร์ต 443 เนื่องจาก https หากเป็น http มันจะเป็น 80 (ค่าเริ่มต้น)

• ข้อมูลทั้งหมดที่ถ่ายโอนคือ 58769 ไบต์สำหรับ 100 คำขอ

• การทดสอบเสร็จสิ้นใน 1.004 วินาที ไม่มีคำขอที่ล้มเหลว

• คำขอต่อวินาที - 99.56 นี่ถือว่าเป็นเลขที่ดีงาม

• เวลาต่อคำขอ - 100.444 ms (สำหรับ 10 คำขอพร้อมกัน) สำหรับคำขอทั้งหมดคือ 100.444 ms / 10 = 10.044 ms

• อัตราการถ่ายโอน - รับ 1338.39 [Kbytes / วินาที]

• ในสถิติเวลาในการเชื่อมต่อคุณสามารถสังเกตได้ว่าคำขอจำนวนมากต้องรอสองสามวินาที อาจเป็นเพราะเว็บเซิร์ฟเวอร์ apache ส่งคำขอในคิวรอ

ในการทดสอบครั้งแรกของเราเราได้ทดสอบแอปพลิเคชัน (เช่น www.apache.org) ที่โฮสต์บนเซิร์ฟเวอร์อื่น ในส่วนต่อไปของบทช่วยสอนเราจะทดสอบตัวอย่างเว็บแอปพลิเคชันของเราที่โฮสต์บนเซิร์ฟเวอร์เดียวกันซึ่งเราจะทำการทดสอบ ab เพื่อความสะดวกในการเรียนรู้และการสาธิต ตามหลักการแล้วโหนดโฮสต์และโหนดทดสอบควรแตกต่างกันเพื่อการวัดที่แม่นยำ

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

การพล็อตเอาต์พุตของ Apache Bench

ในที่นี้เราจะวางแผนผลลัพธ์ที่เกี่ยวข้องเพื่อดูว่าเซิร์ฟเวอร์ใช้เวลาเท่าใดเมื่อจำนวนคำขอเพิ่มขึ้น สำหรับสิ่งนั้นเราจะเพิ่มไฟล์-g ตัวเลือกในคำสั่งก่อนหน้าตามด้วยชื่อไฟล์ (ที่นี่ out.data) ซึ่งข้อมูลเอาต์พุต ab จะถูกบันทึก -

$ ab -n 100 -c 10 -g out.data https://www.apache.org/

ให้เราดูไฟล์ out.data ก่อนที่เราจะสร้างพล็อต -

$ less out.data

Output

starttime       seconds ctime   dtime   ttime   wait
Tue May 30 12:11:37 2017        1496160697      40      38      77      13
Tue May 30 12:11:37 2017        1496160697      42      38      79      13
Tue May 30 12:11:37 2017        1496160697      41      38      80      13
...

ตอนนี้ให้เราเข้าใจส่วนหัวคอลัมน์ในไฟล์ out.data ไฟล์ -

• starttime - นี่คือวันที่และเวลาที่เริ่มการโทร

• seconds - เหมือนกับเวลาเริ่มต้น แต่ในรูปแบบการประทับเวลา Unix (วันที่ -d @ 1496160697 ส่งกลับเอาต์พุตเวลาเริ่มต้น)

• ctime - นี่คือเวลาเชื่อมต่อ

• dtime - นี่คือเวลาดำเนินการ

• ttime - นี่คือเวลาทั้งหมด (คือผลรวมของ ctime และ dtime, ttime ทางคณิตศาสตร์ = ctime + dtime)

• wait - นี่คือเวลารอคอย

สำหรับการมองเห็นภาพว่ารายการต่างๆเหล่านี้เกี่ยวข้องกันอย่างไรให้ดูที่ภาพต่อไปนี้ -

หากเรากำลังทำงานบนเทอร์มินัลหรือในที่ที่ไม่มีกราฟิก gnuplotเป็นตัวเลือกที่ยอดเยี่ยม เราจะทำความเข้าใจได้อย่างรวดเร็วโดยทำตามขั้นตอนต่อไปนี้

ให้เราติดตั้งและเปิด gnuplot -

$ sudo apt-get install gnuplot  
$ gnuplot

Output

G N U P L O T
Version 4.6 patchlevel 6    last modified September 2014
Build System: Linux x86_64

Copyright (C) 1986-1993, 1998, 2004, 2007-2014
Thomas Williams, Colin Kelley and many others

gnuplot home:     http://www.gnuplot.info
faq, bugs, etc:   type "help FAQ"
immediate help:   type "help"  (plot window: hit 'h')

Terminal type set to 'qt'
gnuplot>

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

gnuplot> set terminal dumb

Output

Terminal type set to 'dumb'
Options are 'feed  size 79, 24'

เนื่องจากเทอร์มินัล gnuplot ของเราพร้อมสำหรับการลงจุด ASCII แล้วให้เราพล็อตข้อมูลจากไฟล์ out.data ไฟล์ -

gnuplot> plot "out.data" using 9  w l

Output

1400 ++-----+------+-----+------+------+------+------+-----+------+-----++
       +      +      +     +      +      +      +"out.data" using 9 ****** +
       |                                                                   |
  1200 ++                       ********************************************
       |     *******************                                           |
  1000 ++    *                                                            ++
       |     *                                                             |
       |     *                                                             |
   800 ++   *                                                             ++
       |    *                                                              |
       |    *                                                              |
   600 ++   *                                                             ++
       |    *                                                              |
       |    *                                                              |
   400 ++   *                                                             ++
       |    *                                                              |
   200 ++   *                                                             ++
       |    *                                                              |
       +****  +      +     +      +      +      +      +     +      +      +
     0 ++-----+------+-----+------+------+------+------+-----+------+-----++
       0      10     20    30     40     50     60     70    80     90    100

เราได้วางแผน ttime เวลาทั้งหมด (เป็นมิลลิวินาที) จากคอลัมน์ 9 ตามจำนวนคำขอ เราสามารถสังเกตเห็นว่าสำหรับการร้องขอสิบเริ่มต้นเวลาทั้งหมดอยู่ในเกือบ 100 มิลลิวินาที 30 คำขอถัดไป (ตั้งแต่ 10 ^{ปีบริบูรณ์}ถึง 40 ^{ปีบริบูรณ์} ) ก็เพิ่มขึ้นถึง 1100 มิลลิวินาทีและอื่น ๆ พล็อตของคุณต้องแตกต่างกันขึ้นอยู่กับout.data.

ในบทที่แล้วเราได้ทำความเข้าใจเกี่ยวกับการใช้งานพื้นฐานของ Apache Bench เพื่อทดสอบเว็บไซต์ของบุคคลที่สาม ในส่วนนี้เราจะใช้เครื่องมือนี้เพื่อทดสอบเว็บแอปพลิเคชันบนเซิร์ฟเวอร์ของเราเอง เพื่อให้บทช่วยสอนมีอยู่ในตัวเราได้เลือกที่จะติดตั้งแอปพลิเคชัน python เพื่อจุดประสงค์ในการสาธิต คุณสามารถเลือกภาษาอื่น ๆ เช่น PHP หรือ Ruby ขึ้นอยู่กับระดับความเชี่ยวชาญของคุณ

การติดตั้ง Python

โดยทั่วไป Python ถูกติดตั้งโดยค่าเริ่มต้นบนเซิร์ฟเวอร์ Linux

การติดตั้ง Bottle Framework และการสร้างแอปพลิเคชันอย่างง่าย

Bottle เป็นไมโครเฟรมเวิร์กที่เขียนด้วย python สำหรับสร้างเว็บแอปพลิเคชันและ pip ​​เป็นตัวจัดการแพ็คเกจหลาม พิมพ์คำสั่งต่อไปนี้ในเทอร์มินัลเพื่อติดตั้ง Bottle -

$ sudo apt-get install python-pip
$ sudo pip install bottle

ให้เราสร้างแอปพลิเคชั่นขวดเล็ก ๆ สร้างไดเร็กทอรีและย้ายเข้าไปข้างใน -

$ mkdir webapp
$ cd webapp

เราจะสร้างสคริปต์ python ใหม่ app.pyภายในไดเรกทอรี webapp -

$ vim app.py

ตอนนี้เขียนโค้ดต่อไปนี้ในไฟล์ app.py -

from bottle import Bottle, run

app = Bottle()

@app.route('/')
@app.route('/hello')
def hello():
   return "Hello World!"

run(app, host = 'localhost', port = 8080)

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

$ python app.py

Output

Bottle v0.12.7 server starting up (using WSGIRefServer())...
Listening on http://localhost:8080/
Hit Ctrl-C to quit.

ผลลัพธ์นี้แสดงให้เห็นว่าแอปพลิเคชันของเรากำลังทำงานบนเครื่องท้องถิ่นที่โฮสต์ http://localhost และฟังบนพอร์ต 8080.

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

$ lynx http://localhost:8080/

Lynx เป็นเบราว์เซอร์บรรทัดคำสั่งและโดยปกติจะติดตั้งเป็นค่าเริ่มต้นในการกระจาย Linux ต่างๆเช่น Debian และ Ubuntu หากคุณเห็นผลลัพธ์ต่อไปนี้แสดงว่าแอปของคุณทำงานได้ดี

Output

หากคุณเห็นผลลัพธ์ข้างต้นแสดงว่าแอปพลิเคชันของเราพร้อมใช้งานและพร้อมสำหรับการทดสอบ

การทดสอบแอปพลิเคชันกับเว็บเซิร์ฟเวอร์พัฒนาการ

โปรดทราบว่ามีข้อผิดพลาดใน ab และไม่สามารถทดสอบแอปพลิเคชันบน localhost ได้ ดังนั้นเราจะเปลี่ยนโฮสต์จาก localhost เป็น 127.0.0.1 ในไฟล์ app.py ดังนั้นไฟล์จะเปลี่ยนเป็นดังต่อไปนี้ -

from bottle import Bottle, run

app = Bottle()

@app.route('/')
@app.route('/hello')
def hello():
   return "Hello World!"

run(app, host = '127.0.0.1', port = 8080)

ตอนนี้ให้เราทดสอบแอพของเราโดยพิมพ์คำสั่งต่อไปนี้บนเทอร์มินัลเดียวกับที่รันคำสั่ง lynx -

$ ab -n 100 -c 10  http://127.0.0.1:8080/hello

Output

This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient).....done


Server Software:        WSGIServer/0.1
Server Hostname:        127.0.0.1
Server Port:            8080

Document Path:          /hello
Document Length:        12 bytes

Concurrency Level:      10
Time taken for tests:   0.203 seconds
Complete requests:      100
Failed requests:        0
Total transferred:      16500 bytes
HTML transferred:       1200 bytes
Requests per second:    493.78 [#/sec] (mean)
Time per request:       20.252 [ms] (mean)
Time per request:       2.025 [ms] (mean, across all concurrent requests)
Transfer rate:          79.56 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.1      0       0
Processing:     1    6  28.2      2     202
Waiting:        1    6  28.2      2     202
Total:          1    6  28.2      2     202

Percentage of the requests served within a certain time (ms)
  50%      2
  66%      2
  75%      2
  80%      2
  90%      2
  95%      2
  98%    202
  99%    202
 100%    202 (longest request)

ในขณะที่เอาต์พุตบนเทอร์มินัลแรกจะเป็น (100 เท่า) ดังนี้ -

...
127.0.0.1 - - [10/Jun/2017 04:30:26] "GET /hello HTTP/1.0" 200 12
127.0.0.1 - - [10/Jun/2017 04:30:26] "GET /hello HTTP/1.0" 200 12
127.0.0.1 - - [10/Jun/2017 04:30:26] "GET /hello HTTP/1.0" 200 12   
...

คุณสามารถสังเกตได้ว่าค่าต่างๆของผลลัพธ์ ab มีการเปลี่ยนแปลงอย่างไรเมื่อเทียบกับการทดสอบเบื้องต้น

การทดสอบแอปพลิเคชันกับเว็บเซิร์ฟเวอร์แบบมัลติเธรด

ในการทดสอบ ab ก่อนหน้านี้เราได้ใช้เว็บเซิร์ฟเวอร์เริ่มต้นที่รวมอยู่ในกรอบงาน Bottle

ตอนนี้เราจะเปลี่ยนเว็บเซิร์ฟเวอร์เริ่มต้นแบบเธรดเดียวด้วยมัลติเธรด ดังนั้นให้เราติดตั้งไลบรารีเว็บเซิร์ฟเวอร์แบบมัลติเธรดเช่นcherrypy หรือ gunicornและบอกให้ Bottle ใช้ เราได้เลือก gunicorn เพื่อการสาธิตที่นี่ (คุณสามารถเลือกอันอื่นได้เช่นกัน) -

$  sudo apt-get install gunicorn

และแก้ไขไฟล์นั่นคือการเปลี่ยนจากเว็บเซิร์ฟเวอร์เริ่มต้นเป็น gunicorn -

...
run(server = 'gunicorn'...)
...

ให้เราทดสอบแอปในเทอร์มินัลที่สอง

$ ab -n 100 -c 10  http://127.0.0.1:8080/hello

Output

This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient).....done


Server Software:        gunicorn/19.0.0
Server Hostname:        127.0.0.1
Server Port:            8080

Document Path:          /hello
Document Length:        12 bytes

Concurrency Level:      10
Time taken for tests:   0.031 seconds
Complete requests:      100
Failed requests:        0
Total transferred:      17200 bytes
HTML transferred:       1200 bytes
Requests per second:    3252.77 [#/sec] (mean)
Time per request:       3.074 [ms] (mean)
Time per request:       0.307 [ms] (mean, across all concurrent requests)
Transfer rate:          546.36 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    1   0.9      0       4
Processing:     1    2   0.7      3       4
Waiting:        0    2   0.8      2       3
Total:          2    3   0.6      3       5
WARNING: The median and mean for the initial connection time are not within a normal
        deviation These results are probably not that reliable.
WARNING: The median and mean for the processing time are not within a normal deviation
        These results are probably not that reliable.

Percentage of the requests served within a certain time (ms)
  50%      3
  66%      3
  75%      3
  80%      3
  90%      4
  95%      5
  98%      5
  99%      5
 100%      5 (longest request)

สังเกตว่าคำขอต่อวินาทีเพิ่มขึ้นจาก 493 เป็น 3252 ได้อย่างไรหมายความว่า gunicorn เหมาะสำหรับเป็นเซิร์ฟเวอร์ที่ใช้งานจริงสำหรับแอป python

ในบทนี้เราจะเรียนรู้วิธีทดสอบ URL หลายรายการพร้อมกัน ด้วยเหตุนี้เราจะต้องแก้ไขไฟล์แอปพลิเคชันของเรา app.py เพื่อรวม URL สองรายการ -

from bottle import Bottle, run

app = Bottle()

@app.route('/')
@app.route('/hello1')
def hello():
   return "Hello World! It is first URL."

@app.route('/hello2')
def hello():
   return "Hello World! It is second URL."

run(app,server = 'gunicorn',host = '127.0.0.1', port = 8080)

การสร้าง Simple Shell Script

คุณสามารถทำได้โดยการสร้างเชลล์สคริปต์โดยมีการเรียก ab หลาย ๆ สร้างไฟล์ test.sh และเพิ่มบรรทัดต่อไปนี้ -

ab -n 100 -c 10 http://127.0.0.1:8080/hello1 
ab -n 100 -c 10 http://127.0.0.1:8080/hello2

เมื่อคุณเพิ่มบรรทัดด้านบนแล้วให้บันทึกและปิดไฟล์ ทำให้ไฟล์ปฏิบัติการได้ -

chmod u+x test.sh

ตอนนี้ให้เราเรียกใช้สคริปต์ -

./test.sh

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

เอาต์พุต

.
.
.
Document Path:          /hello1
Document Length:        732 bytes

Concurrency Level:      10
Time taken for tests:   0.040 seconds
Complete requests:      100
Failed requests:        0
Non-2xx responses:      100
Total transferred:      90000 bytes
HTML transferred:       73200 bytes
Requests per second:    2496.13 [#/sec] (mean)
Time per request:       4.006 [ms] (mean)
Time per request:       0.401 [ms] (mean, across all concurrent requests)
Transfer rate:          2193.87 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.8      0       3
Processing:     1    3   1.0      4       5
Waiting:        0    3   1.2      4       4
Total:          1    4   0.6      4       5
WARNING: The median and mean for the processing time are not within a normal deviation
        These results are probably not that reliable.
.
.
.

เชลล์สคริปต์เพื่อบันทึกเอาต์พุต Apache Bench ไปยังไฟล์

คุณสามารถบันทึก Apache Bench Output ลงในไฟล์ได้โดยสร้างเชลล์สคริปต์พร้อมกับการเรียก ab หลาย ๆ ในตอนท้ายของแต่ละบรรทัดให้วางไฟล์&;สิ่งนี้ทำให้คำสั่งทำงานในพื้นหลังและให้คำสั่งถัดไปเริ่มดำเนินการ คุณจะต้องเปลี่ยนทิศทางผลลัพธ์ไปยังไฟล์สำหรับแต่ละ URL โดยใช้ <filename> ตัวอย่างเช่นไฟล์ test.sh ของเราจะมีลักษณะดังต่อไปนี้หลังจากแก้ไข -

$ ab -n 100 -c 10 http://127.0.0.1:8080/hello1 > test1.txt &
$ ab -n 100 -c 10 http://127.0.0.1:8080/hello2 > test2.txt &

ที่นี่ test1.txt และ test2.txt เป็นไฟล์สำหรับบันทึกข้อมูลผลลัพธ์

คุณสามารถตรวจสอบว่าสคริปต์ด้านบนได้สร้างไฟล์สองไฟล์คือ test1.txt และ test2.txt ซึ่งมีเอาต์พุต ab สำหรับ URL ที่เกี่ยวข้อง -

$ ls -l

เอาต์พุต

...
-rw-r--r-- 1 root root  5225 May 30 12:11 out.data
-rwxr--r-- 1 root root   118 Jun 10 12:24 test.sh
-rw-r--r-- 1 root root  1291 Jun 10 12:31 test1.txt
-rwxr--r-- 1 root root    91 Jun 10 13:22 test2.sh
-rw-r--r-- 1 root root  1291 Jun 10 12:31 test2.txt
...

สถานการณ์เฝ้าระวัง

ในขณะที่ใช้ ab คุณควรระวังการทดสอบที่ล้มเหลวโดยไม่มีคำเตือน ตัวอย่างเช่นหากคุณตรวจสอบ URL ผิดคุณอาจได้รับสิ่งที่คล้ายกับข้อความต่อไปนี้ (เราตั้งใจเปลี่ยนพอร์ตที่นี่)

$ ab -l -r -n 100 -c 10 -k -H "Accept-Encoding: gzip, deflate"  http://127.0.0.1:805/

เอาต์พุต

This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient).....done

Server Software:
Server Hostname:        127.0.0.1
Server Port:            805

Document Path:          /
Document Length:        Variable

Concurrency Level:      10
Time taken for tests:   0.002 seconds
Complete requests:      100
Failed requests:        150
   (Connect: 0, Receive: 100, Length: 0, Exceptions: 50)
Keep-Alive requests:    0
Total transferred:      0 bytes
HTML transferred:       0 bytes
Requests per second:    44984.26 [#/sec] (mean)
Time per request:       0.222 [ms] (mean)
Time per request:       0.022 [ms] (mean, across all concurrent requests)
Transfer rate:          0.00 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       0
Processing:     0    0   0.2      0       0
Waiting:        0    0   0.0      0       0
Total:          0    0   0.2      0       0

Percentage of the requests served within a certain time (ms)
  50%      0
  66%      0
  75%      0
  80%      0
  90%      0
  95%      0
  98%      0
  99%      0
 100%      0 (longest request)

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

ระดับการทำงานพร้อมกันและจำนวนคำขอทั้งหมด

ระดับการทำงานพร้อมกันควรต่ำกว่าจำนวนคำขอทั้งหมด

$ ab -l -r -n 30 -c 80 -k -H "Accept-Encoding: gzip, deflate"  http://127.0.0.1:8000/

Output

ab: Cannot use concurrency level greater than total number of requests
Usage: ab [options] [http[s]://]hostname[:port]/path

การใช้ธง

ในส่วนนี้เราจะอธิบายการใช้แฟล็กที่สำคัญกับคำสั่ง ab เราจะใช้เงื่อนไขตัวเลือกและแฟล็กสลับกัน

Verbose -v

สามารถใช้อ็อพชัน verbose เพื่อวิเคราะห์และดีบักหากมีคำขอที่ล้มเหลวหลายรายการ ข้อบ่งชี้ทั่วไปของความล้มเหลวของการทดสอบโหลดคือการทดสอบเสร็จสิ้นเร็วมากและให้ตัวเลขที่ดีสำหรับการร้องขอต่อวินาที แต่มันจะเป็นเกณฑ์มาตรฐานที่ผิด ในการระบุความสำเร็จหรือความล้มเหลวคุณสามารถใช้ไฟล์-v 2ตัวเลือกซึ่งจะถ่ายโอนเนื้อหาและส่วนหัวของการตอบสนองแต่ละรายการไปยังเอาต์พุตเทอร์มินัล คำสั่งต่อไปนี้แสดงถึงกรณีการใช้งาน -

$ ab -n 1 -v 2 http://www.generic-example-URL.com/

Output

LOG: header received:
HTTP/1.0 200 OK
…
Content-Length: 2548687

แน่นอนว่าหากคุณกำลังทดสอบการตอบสนองของตัวแปรหรือส่งคืนรหัส HTTP ที่ไม่ใช่ 200 ในกรณีที่เกิดข้อผิดพลาดใด ๆ คุณควรละเว้นการตรวจสอบความยาวด้วย -lตัวเลือก อีกไม่นานเราจะเห็น HTTP ที่ไม่ใช่ 200 เมื่อเราจะเปิดตัวแอปพลิเคชัน web2py ในบทต่อ ๆ ไป

รักษาชีวิต -k

เมื่อไคลเอนต์ส่งคำขอ HTTP การเชื่อมต่อจะถูกสร้างขึ้นไปยังเซิร์ฟเวอร์เซิร์ฟเวอร์จะส่งการตอบสนองและการเชื่อมต่อจะถูกปิดหลังจากที่ส่งคำขอแล้ว วงจรนี้ดำเนินต่อไปตามคำขอแต่ละรายการ อย่างไรก็ตามด้วยการตั้งค่า keep-alive (หรือที่เรียกว่าการเชื่อมต่อแบบต่อเนื่อง) ไคลเอ็นต์จะรักษาการเชื่อมต่อ TCP พื้นฐานไว้เพื่ออำนวยความสะดวกในการร้องขอและการตอบกลับหลายรายการ ซึ่งจะช่วยลดเวลาในการเริ่มต้นการเชื่อมต่อที่ช้าและเสียค่าใช้จ่ายซึ่งอาจมีอยู่

ความยาวเอกสารแปรผัน -l

หากหน้าเว็บมีความยาวผันแปรคุณควรใช้ตัวเลือกนี้ -l. Apache Bench ไม่รายงานข้อผิดพลาดหากความยาวของคำตอบไม่คงที่ สิ่งนี้มีประโยชน์สำหรับไดนามิกเพจ

การใช้ตัวเลือก -r

วิธีบังคับไม่ให้ ab ออกจากการได้รับข้อผิดพลาด? คุณควรใช้ตัวเลือก-r. หากไม่มีตัวเลือกนี้การทดสอบของคุณอาจพังทันทีที่คำขอใด ๆ เกิดข้อผิดพลาดของซ็อกเก็ต อย่างไรก็ตามด้วยตัวเลือกนี้ข้อผิดพลาดจะถูกรายงานในหัวข้อข้อผิดพลาดที่ล้มเหลว แต่การทดสอบจะดำเนินต่อไปจนจบ

การใช้ตัวเลือก -H

ตัวเลือกนี้ใช้เพื่อเพิ่มบรรทัดส่วนหัวโดยพลการ โดยทั่วไปอาร์กิวเมนต์จะอยู่ในรูปแบบของบรรทัดส่วนหัวที่ถูกต้องซึ่งมีคู่ค่าฟิลด์ที่คั่นด้วยโคลอน (กล่าวคือ“ ยอมรับการเข้ารหัส: zip / zop; 8 บิต”)

การใช้ตัวเลือก -C

ในส่วนต่อไปนี้เราจะเรียนรู้โดยละเอียดเกี่ยวกับวิธีการใช้ตัวเลือกข้างต้นร่วมกับตัวเลือกในการใช้ค่าคุกกี้นั่นคือ -Cตัวเลือก โดยทั่วไปตัวเลือก -C จะอยู่ในรูปของไฟล์name = valueคู่. ฟิลด์นี้สามารถทำซ้ำได้

การใช้ Session Cookie กับ Apache Bench

เพื่อให้เข้าใจวิธีใช้คุกกี้กับ Apache Bench เราจำเป็นต้องมีหน้าเว็บที่พยายามตั้งค่าคุกกี้ ตัวอย่างที่ดีมากคือแอปพลิเคชัน web2py ซึ่งเป็นเฟรมเวิร์กเว็บหลาม

การติดตั้ง web2py

เรากำลังจะติดตั้ง web2py app python อื่นอย่างรวดเร็ว คุณสามารถอ่านเพิ่มเติมเกี่ยวกับวิธีการที่จะใช้ในweb2py กรอบภาพรวม

โดยทั่วไปแล้ว Python จะถูกติดตั้งโดยค่าเริ่มต้นบนเซิร์ฟเวอร์ Ubuntu และ Debian ดังนั้นจึงมีคุณสมบัติตรงตามข้อกำหนดหนึ่งเพื่อเรียกใช้ web2py ได้สำเร็จ

อย่างไรก็ตามเราจำเป็นต้องติดตั้งแพคเกจคลายซิปเพื่อแยกไฟล์ต้นฉบับของ web2py จากไฟล์ zip ที่เราจะดาวน์โหลด -

$ sudo apt-get update
$ sudo apt-get install unzip

ให้เราได้รับ web2py framework จากเว็บไซต์ของโครงการ เราจะดาวน์โหลดลงในโฟลเดอร์บ้านของเรา -

$cd ~
$ wget http://www.web2py.com/examples/static/web2py_src.zip

ตอนนี้เราสามารถคลายซิปไฟล์ที่เราเพิ่งดาวน์โหลดและย้ายเข้าไปข้างใน -

$ unzip web2py_src.zip
$ cd web2py

ในการเรียกใช้ web2py คุณไม่จำเป็นต้องติดตั้ง เมื่อคุณอยู่ในไดเร็กทอรี web2py คุณสามารถเรียกใช้งานได้โดยพิมพ์คำสั่งต่อไปนี้ -

$python web2py.py

หากทุกอย่างสำเร็จคุณจะเห็นผลลัพธ์ต่อไปนี้ซึ่งคุณจะถูกขอให้เลือกรหัสผ่านสำหรับ UI การดูแลระบบ -

web2py Web Framework
Created by Massimo Di Pierro, Copyright 2007-2017
Version 2.14.6-stable+timestamp.2016.05.10.00.21.47
Database drivers available: sqlite3, imaplib, pymysql, pg8000
WARNING:web2py:GUI not available because Tk library is not installed
choose a password:

please visit:
        http://127.0.0.1:8000/
use "kill -SIGTERM 23904" to shutdown the web2py server

อย่างไรก็ตามคุณต้องทราบว่าเว็บอินเทอร์เฟซที่เปิดตัวนั้นสามารถเข้าถึงได้บนเครื่องภายในเท่านั้น

จากผลลัพธ์คุณสามารถเข้าใจได้ว่าหากต้องการหยุดเว็บเซิร์ฟเวอร์คุณจะต้องพิมพ์“ CTRL-C” ในเทอร์มินัลทันที ในทางกลับกันหากต้องการหยุดเซิร์ฟเวอร์ web2py บนเทอร์มินัลอื่นที่เกี่ยวข้องกับ VPS เดียวกันคุณสามารถแทรกคำสั่ง kill -SIGTERM <PID> โดยที่ <PID> เป็น ID กระบวนการสำหรับเซิร์ฟเวอร์ web2py ซึ่งในกรณีนี้คือ 23904.

คุกกี้เซสชันจาก web2py

หากหน้าสามารถเข้าถึงได้โดยผู้ใช้ที่ลงชื่อเข้าใช้ไม่สามารถเข้าถึงได้โดยตรงจากหน้าเข้าสู่ระบบในกรณีนี้คุณสามารถใช้ -Cธง. แฟล็กนี้กำหนดคุกกี้สำหรับคำสั่ง ab แต่คุณต้องได้รับค่าของคุกกี้ตัวระบุเซสชันจากเซสชันที่ถูกต้อง จะไปได้อย่างไร? บทช่วยสอนออนไลน์ต่างๆจะนำคุณไปสู่เครื่องมือสำหรับนักพัฒนาเบราว์เซอร์ Chrome (หรือ Mozilla) แต่ในกรณีทดสอบของเราเนื่องจากแอปพลิเคชันพร้อมใช้งานในบรรทัดคำสั่งเท่านั้นเราจะใช้เบราว์เซอร์ lynx เพื่อรับค่า

ให้เราได้รับค่าคุกกี้ของเซสชันก่อน เปิดเทอร์มินัลอื่นแล้วพิมพ์คำสั่งต่อไปนี้ -

$ lynx http://127.0.0.1:8000/

เพื่อตอบสนองต่อคำสั่งดังกล่าว lynx จะขออนุญาตจากคุณเพื่อยอมรับคุกกี้จากเซิร์ฟเวอร์ web2py ดังที่แสดงในภาพด้านล่าง

จดค่าคุกกี้ก่อนพิมพ์ yเพื่อยอมรับคุกกี้ ตอนนี้เทอร์มินัลจะมีลักษณะคล้ายกับภาพต่อไปนี้ - เว็บไซต์บนเทอร์มินัล!

เมื่อได้รับค่าคุกกี้แล้วเราจะทำการทดสอบ ab เพื่อที่เราจะต้องเปิดเทอร์มินัลที่สาม (ดูภาพด้านล่าง) -

ตอนนี้ให้เราใช้แฟล็ก -C ในเทอร์มินัลที่สาม -

$ ab -n 100 -c 10 -C session_name = 127.0.0.1-643dad04-3c34  http://127.0.0.1:8000/

เอาต์พุต

This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient).....done


Server Software:        Rocket
Server Hostname:        127.0.0.1
Server Port:            8000

Document Path:          /
Document Length:        66 bytes

Concurrency Level:      10
Time taken for tests:   0.051 seconds
Complete requests:      100
Failed requests:        0
Non-2xx responses:      100
Total transferred:      27700 bytes
HTML transferred:       6600 bytes
Requests per second:    1968.12 [#/sec] (mean)
Time per request:       5.081 [ms] (mean)
Time per request:       0.508 [ms] (mean, across all concurrent requests)
Transfer rate:          532.39 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        1    2   0.9      2       4
Processing:     0    3   0.9      3       5
Waiting:        0    2   1.1      2       4
Total:          4    5   0.7      5       7

Percentage of the requests served within a certain time (ms)
  50%      5
  66%      5
  75%      5
  80%      6
  90%      6
  95%      6
  98%      7
  99%      7
 100%      7 (longest request)

จากผลลัพธ์ด้านบนเราสังเกตเห็นหลายประเด็น อันดับแรก web2py ใช้เว็บเซิร์ฟเวอร์Rocket นอกจากนี้เรายังทราบด้วยว่าเราได้รับ 'คำตอบที่ไม่ใช่ 2xx' นอกเหนือจากหัวข้อที่กล่าวถึงก่อนหน้านี้ในผลลัพธ์ โดยทั่วไปโปรโตคอล Http จะตอบสนองต่อคำขอโดยใช้รหัสตอบกลับและสิ่งใดก็ตามที่อยู่ในช่วง 200 วินาทีหมายถึง 'โอเค' และส่วนที่เหลือสอดคล้องกับปัญหาบางอย่าง ตัวอย่างเช่น 400s เป็นข้อผิดพลาดเกี่ยวกับทรัพยากรเช่นไม่พบไฟล์ 404 500s สอดคล้องกับข้อผิดพลาดของเซิร์ฟเวอร์ ในกรณีของเราทันทีไม่มีข้อผิดพลาดใด ๆ ยกเว้นเมื่อเราใช้ตัวเลือก -C สามารถระงับได้โดยใช้ตัวเลือก -l ตามที่อธิบายไว้แล้ว

กำลังตรวจสอบหน้าผู้ดูแลระบบ

ในส่วนนี้เราจะเข้าใจวิธีการตรวจสอบหน้าผู้ดูแลระบบ เพื่อจุดประสงค์ในการเปรียบเทียบให้เราทดสอบ URL อื่นของแอปพลิเคชัน web2py -

$ ab -n 100 -c 10 session_name = 127.0.0.1-643dad04-3c34  http://127.0.0.1:8000/admin

เอาต์พุต

This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient).....done


Server Software:        Rocket
Server Hostname:        127.0.0.1
Server Port:            8000

Document Path:          /admin
Document Length:        8840 bytes

Concurrency Level:      10
Time taken for tests:   2.077 seconds
Complete requests:      100
Failed requests:        0
Total transferred:      926700 bytes
HTML transferred:       884000 bytes
Requests per second:    48.14 [#/sec] (mean)
Time per request:       207.749 [ms] (mean)
Time per request:       20.775 [ms] (mean, across all concurrent requests)
Transfer rate:          435.61 [Kbytes/sec] received

Connection Times (ms)
          min  mean[+/-sd] median   max
Connect:        0    1   3.2      0      12
Processing:    62  204  52.2    199     400
Waiting:       61  203  52.0    199     400
Total:         62  205  54.3    199     411

Percentage of the requests served within a certain time (ms)
  50%    199
  66%    211
  75%    220
  80%    226
  90%    264
  95%    349
  98%    381
  99%    411
 100%    411 (longest request)

โดยเฉพาะอย่างยิ่งคุณควรสังเกตสถิติที่เกี่ยวข้องในส่วน "เวลาในการเชื่อมต่อ" และ "เปอร์เซ็นต์ของคำขอที่ให้บริการ ... " ของ http://127.0.0.1:8000/ และ http://127.0.0.1:8000/admin. มีความแตกต่างกันอย่างมาก

ใช้ Timelimit Option

โดยทั่วไปตัวเลือก Timelimit เป็นตัวเลือกที่ยุ่งยาก ให้เราเข้าใจสิ่งนี้จากคู่มือของ abซึ่งค่อนข้างอธิบายได้ -

-t timelimit
Maximum number of seconds to spend for benchmarking. This implies a -n 50000 internally.
Use this to benchmark the server within a fixed total amount of time.
Per default there is no timelimit.

ให้เราทำการทดสอบด้วยตัวเลือกนี้ เราจะสังเกตข้อสังเกตของเราหลังจากผ่านผลลัพธ์ -

$ ab -n 100 -c 10 -t 60   http://127.0.0.1:8000/

เอาต์พุต

This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient)
Completed 5000 requests
Completed 10000 requests
Completed 15000 requests
Completed 20000 requests
Completed 25000 requests
Completed 30000 requests
Completed 35000 requests
Completed 40000 requests
Completed 45000 requests
Completed 50000 requests
Finished 50000 requests


Server Software:        Rocket
Server Hostname:        127.0.0.1
Server Port:            8000

Document Path:          /
Document Length:        66 bytes

Concurrency Level:      10
Time taken for tests:   22.547 seconds
Complete requests:      50000
Failed requests:        0
Non-2xx responses:      50000
Total transferred:      13850000 bytes
HTML transferred:       3300000 bytes
Requests per second:    2217.61 [#/sec] (mean)
Time per request:       4.509 [ms] (mean)
Time per request:       0.451 [ms] (mean, across all concurrent requests)
Transfer rate:          599.88 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    2   0.8      2       8
Processing:     0    2   3.2      2     218
Waiting:        0    2   3.2      2     218
Total:          2    4   3.1      4     220

Percentage of the requests served within a certain time (ms)
  50%      4
  66%      4
  75%      4
  80%      5
  90%      5
  95%      5
  98%      7
  99%      8
 100%    220 (longest request)

โปรดสังเกตว่าเอาต์พุตจะแสดงอ็อพชันนี้แทนที่จำนวนคำร้องขอที่ระบุโดย -nตัวเลือกและดำเนินการต่อไม่เกินคำขอ 50K อย่างไรก็ตามเนื่องจากคำขอได้รับการจัดการอย่างรวดเร็ว ab จึงยุติทันทีที่ทำเครื่องหมาย 50k ได้ - ภายใน 22 วินาที (ดูหัวข้อเวลาที่ใช้สำหรับการทดสอบ) ในกรณีทันที

คุณสามารถทดสอบคำสั่งเดียวกันแทนที่ http://127.0.0.1:8000/ ด้วย http://127.0.0.1:8000/admin (สมมติว่าเป็นแอปพลิเคชัน web2py ของเรา) หรือเว็บไซต์ของบุคคลภายนอกเช่น https://www.apache.org/ สังเกตความแตกต่างของสถิติ

รายการตรวจสอบก่อนทำการทดสอบโหลด

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

• ตรวจสอบให้แน่ใจว่าไม่มีการโหลดโมดูล python เพิ่มเติม

• เพื่อหลีกเลี่ยงการหมดพอร์ต TCP / IP โดยทั่วไปคุณควรรอ 2-3 นาทีก่อนที่จะย้ายไปทดสอบ ab อื่น

• ตรวจสอบให้แน่ใจว่าจำนวนการเชื่อมต่อพร้อมกันต่ำกว่า Apache Worker Threads

• คุณควรรีบูตเซิร์ฟเวอร์ก่อนทำการทดสอบอีกครั้งหาก Apache หรือ python ขัดข้อง

ในบทนี้เราจะอธิบายชุดต่างๆของ -n และ -c ด้วยแฟล็กที่สำคัญเพื่อค่อยๆเพิ่มภาระในเว็บเซิร์ฟเวอร์ของคุณ

คุณควรเน้นที่การเปลี่ยนแปลงเมตริกต่อไปนี้เป็นหลักเมื่อคุณเพิ่มภาระ -

• คำขอต่อวินาที
• เวลาในการเชื่อมต่อ (มิลลิวินาที)
• เปอร์เซ็นต์ของคำขอที่ให้บริการภายในช่วงเวลาหนึ่ง (มิลลิวินาที)

คุณควรสังเกตค่าขีด จำกัด เมื่อเซิร์ฟเวอร์เริ่มติดขัดและคุณเริ่มได้รับคำขอที่ล้มเหลว

ผู้ใช้พร้อมกัน 1 คนที่มีการเข้าชม 100 หน้า

ให้เราโหลดเพจตามลำดับ 100 ครั้งโดยผู้ใช้คนเดียว -

$ ab -l -r -n 100 -c 1 -k -H "Accept-Encoding: gzip, deflate"  http://127.0.0.1:8000/

เอาต์พุต

This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient).....done


Server Software:        Rocket
Server Hostname:        127.0.0.1
Server Port:            8000

Document Path:          /
Document Length:        Variable

Concurrency Level:      1
Time taken for tests:   0.045 seconds
Complete requests:      100
Failed requests:        0
Non-2xx responses:      100
Keep-Alive requests:    0
Total transferred:      27700 bytes
HTML transferred:       6600 bytes
Requests per second:    2206.24 [#/sec] (mean)
Time per request:       0.453 [ms] (mean)
Time per request:       0.453 [ms] (mean, across all concurrent requests)
Transfer rate:          596.80 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       0
Processing:     0    0   0.0      0       0
Waiting:        0    0   0.0      0       0
Total:          0    0   0.0      0       1

Percentage of the requests served within a certain time (ms)
  50%      0
  66%      0
  75%      0
  80%      0
  90%      1
  95%      1
  98%      1
  99%      1
 100%      1 (longest request)

ผู้ใช้พร้อมกัน 5 คนแต่ละคนมีการเข้าชม 10 หน้า

กรณีนี้สอดคล้องกับการโหลดสูงสุดบนเว็บไซต์ที่มีผู้เข้าชมประมาณ 50,000+ ครั้งต่อเดือน

$ ab -l -r -n 10 -c 5 -k -H "Accept-Encoding: gzip, deflate"  http://127.0.0.1:8000/

ในผลลัพธ์ที่ตามมาเราจะละเว้นส่วนหัวทั่วไปเพื่อความชัดเจน

เอาต์พุต

...
Requests per second:    2009.24 [#/sec] (mean)
Time per request:       2.488 [ms] (mean)
Time per request:       0.498 [ms] (mean, across all concurrent requests)
Transfer rate:          543.52 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    1   0.5      1       2
Processing:     0    1   0.5      1       2
Waiting:        0    1   0.5      1       1
Total:          2    2   0.4      3       3
ERROR: The median and mean for the total time are more than twice the standard
       deviation apart. These results are NOT reliable.

Percentage of the requests served within a certain time (ms)
  50%      3
  66%      3
  75%      3
  80%      3
  90%      3
  95%      3
  98%      3
  99%      3
 100%      3 (longest request)

ผู้ใช้พร้อมกัน 10 คนแต่ละคนมีการเข้าชม 10 หน้า

การทดสอบนี้สอดคล้องกับการโหลดหน้าเว็บ 100 ครั้งโดยผู้ใช้ 10 คนที่แตกต่างกันโดยผู้ใช้แต่ละคนกำลังโหลดหน้าต่อเนื่อง 10 หน้า

$ ab  -r -n 10 -c 10 -k -H "Accept-Encoding: gzip, deflate"  http://127.0.0.1:8000/

เอาต์พุต

...
Requests per second:    2225.68 [#/sec] (mean)
Time per request:       4.493 [ms] (mean)
Time per request:       0.449 [ms] (mean, across all concurrent requests)
Transfer rate:          602.07 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        1    2   0.7      2       3
Processing:     0    2   1.0      2       3
Waiting:        0    1   1.0      2       3
Total:          4    4   0.3      4       4
WARNING: The median and mean for the waiting time are not within a normal deviation
        These results are probably not that reliable.

Percentage of the requests served within a certain time (ms)
  50%      4
  66%      4
  75%      4
  80%      4
  90%      4
  95%      4
  98%      4
  99%      4
 100%      4 (longest request)

ผู้ใช้พร้อมกัน 20 คนแต่ละคนมีการเข้าชม 20 หน้า

การทดสอบนี้สอดคล้องกับการโหลดหน้า 400 โดยผู้ใช้งานพร้อมกัน 20 คนผู้ใช้แต่ละคนกำลังโหลดหน้าเว็บตามลำดับ 20 หน้า

$ ab -r -n 20 -c 20 -k -H “Accept-Encoding: gzip, deflate” http://127.0.0.1:8000/

เอาต์พุต

...
Requests per second:    1619.96 [#/sec] (mean)
Time per request:       12.346 [ms] (mean)
Time per request:       0.617 [ms] (mean, across all concurrent requests)
Transfer rate:          438.21 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        2    6   2.3      6      10
Processing:     1    5   2.9      5      10
Waiting:        0    5   2.9      5       9
Total:         10   11   0.6     11      12

Percentage of the requests served within a certain time (ms)
  50%     11
  66%     11
  75%     12
  80%     12
  90%     12
  95%     12
  98%     12
  99%     12
 100%     12 (longest request)

ผู้ใช้งานพร้อมกัน 30 คนแต่ละคนมีการเข้าชม 30 หน้า

การทดสอบนี้สอดคล้องกับการโหลดหน้าเว็บ 900 หน้าโดยผู้ใช้ 30 คนที่แตกต่างกันโดยผู้ใช้แต่ละคนกำลังโหลดหน้าต่อเนื่อง 30 หน้า

$ ab  -r -n 30 -c 30 -k -H "Accept-Encoding: gzip, deflate"  http://127.0.0.1:8000/

เอาต์พุต

...
Requests per second:    2283.45 [#/sec] (mean)
Time per request:       13.138 [ms] (mean)
Time per request:       0.438 [ms] (mean, across all concurrent requests)
Transfer rate:          617.69 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        2    6   2.7      6      11
Processing:     1    6   3.1      6      11
Waiting:        0    5   3.2      5      10
Total:         11   12   0.5     12      13

Percentage of the requests served within a certain time (ms)
  50%     12
  66%     12
  75%     12
  80%     12
  90%     13
  95%     13
  98%     13
  99%     13
 100%     13 (longest request)

ตอนนี้เราได้เรียนรู้วิธีเพิ่มการโหลดทีละน้อยบนเว็บไซต์และทดสอบประสิทธิภาพ

ในบทนี้เราจะเปรียบเทียบผลลัพธ์ที่มีและไม่มีแฟล็ก ให้เราดูว่าการใช้แฟล็กที่เหมาะสมสามารถเพิ่มประสิทธิภาพของเว็บแอปพลิเคชันของคุณได้อย่างไร ก่อนหน้านั้นเราต้องเข้าใจว่าหากแอปพลิเคชันของคุณเรียบง่ายคุณอาจไม่สังเกตเห็นความแตกต่าง เช่นเดียวกับแอปพลิเคชันง่ายๆของเราที่มีแฟล็กและไม่มีแฟล็ก จากนั้นเราจะทำการทดสอบเดียวกันกับhttps://www.apache.org/ URL และดูความแตกต่าง

การทดสอบแอปพลิเคชันของเราโดยไม่มีธง

ในส่วนนี้เราจะเข้าใจวิธีทดสอบแอปพลิเคชันของเราโดยไม่มีแฟล็ก

$ ab -n 100 -c 10 http://127.0.0.1:8000/

เอาต์พุต

This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient).....done


Server Software:        Rocket
Server Hostname:        127.0.0.1
Server Port:            8000

Document Path:          /
Document Length:        Variable

Concurrency Level:      10
Time taken for tests:   0.244 seconds
Complete requests:      100
Failed requests:        0
Non-2xx responses:      100
Keep-Alive requests:    0
Total transferred:      27700 bytes
HTML transferred:       6600 bytes
Requests per second:    2208.77 [#/sec] (mean)
Time per request:       4.527 [ms] (mean)
Time per request:       0.453 [ms] (mean, across all concurrent requests)
Transfer rate:          597.49 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        1    2   0.7      2       3
Processing:     0    2   0.7      2       4
Waiting:        0    2   1.0      2       3
Total:          4    4   0.3      4       5

Percentage of the requests served within a certain time (ms)
  50%      4
  66%      4
  75%      5
  80%      5
  90%      5
  95%      5
  98%      5
  99%      5
 100%      5 (longest request)

ทดสอบแอปพลิเคชันของเราด้วย Flags

ในส่วนนี้เราจะเข้าใจวิธีทดสอบแอปพลิเคชันของเราด้วยแฟล็ก

$ ab -l -r -n 100 -c 10 -k -H "Accept-Encoding: gzip, deflate"  http://127.0.0.1:8000/

เอาต์พุต

...
Requests per second:    2277.07 [#/sec] (mean)
Time per request:       4.392 [ms] (mean)
Time per request:       0.439 [ms] (mean, across all concurrent requests)
Transfer rate:          615.97 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        1    2   0.7      2       3
Processing:     0    2   0.7      2       4
Waiting:        0    2   1.0      2       3
Total:          4    4   0.2      4       5

Percentage of the requests served within a certain time (ms)
  50%      4
  66%      4
  75%      4
  80%      4
  90%      5
  95%      5
  98%      5
  99%      5
 100%      5 (longest request)

เราสามารถสังเกตได้ว่าสถิติผลลัพธ์ไม่มีความแตกต่างกันมากนัก

การทดสอบเว็บไซต์องค์กร Apache โดยไม่มีธง

ตอนนี้ให้เราดูวิธีทดสอบเว็บไซต์องค์กร Apache โดยไม่มีแฟล็ก

$ ab -n 100 -c 10 http://www.apache.org/

เอาต์พุต

This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking www.apache.org (be patient).....done

Server Software:        Apache/2.4.7
Server Hostname:        www.apache.org
Server Port:            80

Document Path:          /
Document Length:        58433 bytes

Concurrency Level:      10
Time taken for tests:   1.498 seconds
Complete requests:      100
Failed requests:        0
Total transferred:      5877500 bytes
HTML transferred:       5843300 bytes
Requests per second:    66.74 [#/sec] (mean)
Time per request:       149.840 [ms] (mean)
Time per request:       14.984 [ms] (mean, across all concurrent requests)
Transfer rate:          3830.58 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       12  110 295.2     12    1012
Processing:    37   38   0.5     38      39
Waiting:       12   13   0.3     13      15
Total:         49  147 295.4     50    1051

Percentage of the requests served within a certain time (ms)
  50%     50
  66%     50
  75%     50
  80%     50
  90%    816
  95%   1050
  98%   1051
  99%   1051
 100%   1051 (longest request)

การทดสอบเว็บไซต์ Apache Organization ด้วย Flags

ตอนนี้ให้เราทดสอบเว็บไซต์องค์กร Apache ด้วย Flags

$ ab -l -r -n 100 -c 10 -k -H "Accept-Encoding: gzip, deflate"  http://www.apache.org/

เอาต์พุต

...
Document Length:        Variable

Concurrency Level:      10
Time taken for tests:   0.357 seconds
Complete requests:      100
Failed requests:        0
Keep-Alive requests:    100
Total transferred:      1358510 bytes
HTML transferred:       1317700 bytes
Requests per second:    280.28 [#/sec] (mean)
Time per request:       35.678 [ms] (mean)
Time per request:       3.568 [ms] (mean, across all concurrent requests)
Transfer rate:          3718.41 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    1   3.7      0      12
Processing:    14   17  21.3     15     227
Waiting:       14   17  21.3     14     227
Total:         14   18  21.5     15     227

Percentage of the requests served within a certain time (ms)
  50%     15
  66%     15
  75%     15
  80%     15
  90%     27
  95%     28
  98%     29
  99%    227
 100%    227 (longest request)

คุณสามารถสังเกตได้ว่าคำขอต่อวินาทีเพิ่มขึ้นอย่างไรโดยใช้แฟล็ก ในกรณีนี้โดยเฉพาะอย่างยิ่งเนื่องจากการใช้-H "Accept-Encoding: gzipยุบเนื่องจากแฟล็กนี้บอกให้เซิร์ฟเวอร์ Apache ให้บริการคำขอในไฟล์ gzipped รูปแบบ.

พิจารณาผล Apache Bench

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

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

ตรวจสอบว่ามีข้อผิดพลาดในบันทึกข้อผิดพลาดของ Apache หรือเว็บเซิร์ฟเวอร์ที่ใช้หรือบันทึก (ทั่วไป) หรือไม่ เมื่อคุณจะเพิ่มภาระของคุณสิ่งต่างๆจะเริ่มทำให้หายใจไม่ออก: ปัญหาหน่วยความจำจะเริ่มขึ้น สคริปต์ python จำนวนมากจะเริ่มทำงานผิดพลาดหากไม่ได้เขียนโดยคำนึงถึงการทำงานพร้อมกัน

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

สรุป

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