ฉันเพิ่งได้เรียนรู้เกี่ยวกับการตรวจสอบ nodejs แม้ว่าฉันจะไม่มีพลังที่จะเรียนรู้ที่จะเขียนการตรวจสอบแบบง่ายๆ แต่ฉันก็ยังอดไม่ได้ที่จะเรียนรู้วิธีรับตัวบ่งชี้เหล่านี้ (หลังจากปรึกษาข้อมูลมากมายแล้ว ฉันรู้สึกว่า ว่ามีการแนะนำเนื้อหานี้น้อยเกินไปบนอินเทอร์เน็ตในประเทศ ฉันกำลังแยกแยะประเด็นความรู้เกี่ยวกับโหนดเซิร์ฟเวอร์ด้วย ดังนั้นฉันจะสรุปไว้ในบทความนี้และแบ่งปันกับคุณ)
อาจมีปัญหากับตัวบ่งชี้บางตัวในบทความนี้ ยินดีต้อนรับสู่การแลกเปลี่ยน ที่จริงแล้ว คุณสามารถจัดระเบียบข้อมูลเหล่านี้และเขียนลงในไลบรารีการตรวจสอบและใช้ในโครงการขนาดเล็กและขนาดกลางของคุณเองได้ จากนั้นการตอบสนองส่วนหน้าจะมีเครื่องมือเช่น bizcharts และ g2 และส่วนหน้าจะดึงหน้าจอข้อมูลขนาดใหญ่ด้วยตัวเอง ฉันคิดว่ามิติข้อมูลที่รวบรวมโดย esay monitor นั้นไม่ครอบคลุมเท่ากับของเรา
คอขวดด้านประสิทธิภาพของเซิร์ฟเวอร์มักมีดังต่อไปนี้:
การใช้งาน CPU และโหลดของ CPU ซึ่งทั้งสองอย่างนี้สามารถสะท้อนถึงความยุ่งของเครื่องได้ในระดับหนึ่ง
การCPU คือทรัพยากรของ CPU ที่ถูกใช้งานโดยการรันโปรแกรม ซึ่งบ่งชี้ว่าเครื่องกำลังรันโปรแกรมอย่างไร ณ จุดใดจุดหนึ่ง ยิ่งอัตราการใช้งานสูงแสดงว่าเครื่องกำลังรันโปรแกรมจำนวนมากในเวลานี้และในทางกลับกัน ระดับการใช้งานเกี่ยวข้องโดยตรงกับความแข็งแกร่งของ CPU ก่อนอื่นมาทำความเข้าใจ API ที่เกี่ยวข้องและคำอธิบายคำศัพท์บางอย่างเพื่อช่วยให้เราเข้าใจโค้ดสำหรับการรับการใช้งาน CPU
os.cpus()ส่งคืนอาร์เรย์ของอ็อบเจ็กต์ที่มีข้อมูลเกี่ยวกับคอร์ CPU แบบลอจิคัลแต่ละตัว
model: สตริงที่ระบุรุ่นของแกน CPU
ความเร็ว: ตัวเลขที่ระบุความเร็วของแกน CPU ในหน่วย MHz
ครั้ง: อ็อบเจ็กต์ที่มีคุณสมบัติต่อไปนี้:
หมายเหตุ: ค่า nice มีไว้สำหรับ POSIX เท่านั้น บนระบบปฏิบัติการ Windows ค่า nice จะเป็น 0 เสมอสำหรับโปรเซสเซอร์ทั้งหมด
เมื่อคุณเห็นผู้ใช้และฟิลด์ที่ดี นักเรียนบางคนสับสนเกี่ยวกับข้อดี ฉันก็เช่นกัน ดังนั้นฉันจึงสอบถามอย่างละเอียดเกี่ยวกับความหมายของพวกเขา โปรดดำเนินการต่อ
ผู้ระบุสัดส่วนของเวลาที่ CPU ทำงานใน โหมดผู้ใช้
การดำเนินการกระบวนการแอปพลิเคชันแบ่งออกเป็น โหมดผู้ใช้ และ โหมดเคอร์เนล : CPU ดำเนินการตรรกะโค้ดของกระบวนการแอปพลิเคชันเองในโหมดผู้ใช้ โดยปกติจะเป็นการ คำนวณ เชิงตรรกะ หรือตัวเลข CPU ดำเนินการเรียกระบบที่เริ่มต้นโดยกระบวนการในโหมดเคอร์เนล ซึ่งโดยปกติจะเป็นการตอบสนอง ต่อการร้องขอทรัพยากรของกระบวนการ
โปรแกรม userspace คือกระบวนการใดๆ ที่ไม่ได้เป็นส่วนหนึ่งของเคอร์เนล เชลล์ คอมไพเลอร์ ฐานข้อมูล เว็บเซิร์ฟเวอร์ และโปรแกรมที่เกี่ยวข้องกับเดสก์ท็อปล้วนเป็นกระบวนการในพื้นที่ผู้ใช้ หากโปรเซสเซอร์ไม่ได้ใช้งาน เป็นเรื่องปกติที่เวลา CPU ส่วนใหญ่ควรใช้ไปกับการรันกระบวนการพื้นที่ผู้ใช้
Nice แสดงถึงสัดส่วนของเวลาที่ CPU ทำงานใน โหมดผู้ใช้ที่มีลำดับความสำคัญต่ำ ลำดับความสำคัญต่ำหมายความว่าค่า nice ของกระบวนการน้อยกว่า 0
ผู้ใช้แสดงถึงสัดส่วนของเวลาที่ CPU ทำงานใน โหมดเคอร์เนล
โดยทั่วไป การใช้งาน CPU ในโหมดเคอร์เนล ไม่ควรสูงเกินไป เว้นแต่กระบวนการแอปพลิเคชันจะเริ่มต้นการเรียกระบบจำนวนมาก หากสูงเกินไป แสดงว่าการเรียกของระบบใช้เวลานาน เช่น การดำเนินการ IO บ่อยครั้ง
ระบุสัดส่วนของเวลาที่ CPU อยู่ในสถานะไม่ได้ใช้งาน ซึ่ง CPU ไม่มีงานที่ต้องทำ
irq แสดงถึงสัดส่วนของเวลาที่ CPU จัดการกับ การขัดจังหวะของฮาร์ดแวร์
การขัดจังหวะการ์ดเครือข่าย เป็นตัวอย่างทั่วไป: หลังจากที่การ์ดเครือข่ายได้รับแพ็กเก็ตข้อมูล การ์ดจะแจ้งให้ CPU ทราบเพื่อประมวลผลผ่านการขัดจังหวะด้วยฮาร์ดแวร์ หากการรับส่งข้อมูลเครือข่ายของระบบมีปริมาณมาก อาจสังเกตการใช้งาน irq เพิ่มขึ้นอย่างมีนัยสำคัญ
หากสถานะผู้ใช้น้อยกว่า 70% สถานะเคอร์เนลน้อยกว่า 35% และสถานะโดยรวมน้อยกว่า 70% ก็สามารถนับเป็นสถานะปกติได้
ตัวอย่างต่อไปนี้แสดงให้เห็นถึงการใช้เมธอด os.cpus() ใน Node.js:
ตัวอย่างที่ 1:
// โปรแกรม Node.js เพื่อแสดง
//os.cpus() วิธีการ
// กำลังจัดสรรโมดูลระบบปฏิบัติการ
const os = ต้องการ('os');
// พิมพ์ค่า os.cpus()
console.log(os.cpus()); เอาต์พุต:
[ { รุ่น: 'Intel (R) Core (TM) i5-7200U CPU @ 2.50GHz',
ความเร็ว:2712,
ครั้ง:
{ ผู้ใช้:900000, ดี:0, sys:940265, ไม่ได้ใช้งาน:11928546, irq:147046 } },
{ รุ่น: 'Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz',
ความเร็ว:2712,
ครั้ง:
{ ผู้ใช้:860875, ดี:0, sys:507093, ไม่ได้ใช้งาน:12400500, irq:27062 } },
{ รุ่น: 'Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz',
ความเร็ว:2712,
ครั้ง:
{ ผู้ใช้:1273421, ดี:0, sys:618765, ไม่ได้ใช้งาน:11876281, irq:13125 } },
{ รุ่น: 'Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz',
ความเร็ว:2712,
ครั้ง:
{ ผู้ใช้:943921, nice:0, sys:460109, idle:12364453, irq:12437 } } ] ต่อไปนี้เป็นรหัสสำหรับวิธีรับการใช้งาน cpu
const os = need('os');
const sleep = ms => สัญญาใหม่ (แก้ไข => setTimeout (แก้ไข, ms));
คลาส OSUtils {
ตัวสร้าง () {
this.cpuUsageMSDefault = 1,000; // ระยะเวลาเริ่มต้นการใช้งาน CPU}
-
* รับการใช้งาน CPU ในช่วงระยะเวลาหนึ่ง* @param { Number } Options.ms [ช่วงเวลา ค่าเริ่มต้นคือ 1,000ms ซึ่งก็คือ 1 วินาที]
* @param { บูลีน } Options.percentage [true (ส่งคืนเป็นผลลัพธ์เป็นเปอร์เซ็นต์) | false]
* @returns { สัญญา }
-
async getCPUUsage (ตัวเลือก = {}) {
const นั่น = นี่;
ให้ { cpuUsageMS, เปอร์เซ็นต์ } = ตัวเลือก;
cpuUsageMS = cpuUsageMS ||. that.cpuUsageMSDefault;
const t1 = that._getCPUInfo(); // ข้อมูล CPU ที่จุดเวลา t1 รอการนอนหลับ (cpuUsageMS);
const t2 = that._getCPUInfo(); // ข้อมูล CPU ที่จุดเวลา t2 const idle = t2.idle - t1.idle;
ผลรวม const = t2.total - t1.total;
ให้การใช้งาน = 1 - ไม่ได้ใช้งาน / ทั้งหมด;
ถ้า (เปอร์เซ็นต์) การใช้งาน = (การใช้งาน * 100.0).toFixed(2) + "%";
การใช้งานคืน;
-
-
* รับข้อมูลเวลา CPU ทันที * @returns { Object } ข้อมูล CPU * ผู้ใช้ <number> จำนวนมิลลิวินาทีที่ CPU ใช้ในโหมดผู้ใช้
* nice <number> จำนวนมิลลิวินาทีที่ CPU ใช้ในโหมด Nice
* sys <number> จำนวนมิลลิวินาทีที่ CPU ใช้ในโหมดระบบ
* idle <number> จำนวนมิลลิวินาทีที่ CPU ใช้ในโหมดไม่ได้ใช้งาน
* irq <number> จำนวนมิลลิวินาทีที่ CPU ใช้ในโหมดคำขอขัดจังหวะ
-
_getCPUInfo() {
const cpus = os.cpus();
ให้ผู้ใช้ = 0, ดี = 0, sys = 0, ไม่ได้ใช้งาน = 0, irq = 0, รวม = 0;
สำหรับ (ให้ cpu เป็น cpus) {
const ครั้ง = cpus [cpu] .times;
ผู้ใช้ += times.user;
ดี += ครั้งดี;
sys += ครั้ง.sys;
ไม่ได้ใช้งาน += ครั้ง ไม่ได้ใช้งาน;
irq += ครั้ง.irq;
-
รวม += ผู้ใช้ + ดี + sys + ไม่ได้ใช้งาน + irq;
กลับ {
ผู้ใช้,
ระบบ,
ไม่ได้ใช้งาน,
ทั้งหมด,
-
-
-
const cpuUsage = OSUtils ใหม่ ().getCPUUsage ({ เปอร์เซ็นต์: จริง });
console.log('cpuUsage: ', cpuUsage.then(data=>console.log(data))); // คอมพิวเตอร์ของฉันมี โหลด CPU (loadavg) นั้นง่ายต่อการเข้าใจและอ้างอิงถึงบางอย่าง ช่วงเวลา จำนวนกระบวนการที่ใช้เวลา CPU และกระบวนการที่รอเวลา CPU คือค่าเฉลี่ยโหลด กระบวนการที่รอเวลา CPU ที่นี่หมายถึงกระบวนการที่รอการปลุก ไม่รวมกระบวนการในสถานะรอ
ก่อนหน้านี้ เราจำเป็นต้องเรียนรู้โหนด API
os.loadavg()ส่งคืนอาร์เรย์ที่มีการโหลดเฉลี่ย 1, 5 และ 15 นาที
ค่าเฉลี่ยการโหลดคือการวัดกิจกรรมของระบบที่คำนวณโดยระบบปฏิบัติการและแสดงเป็นทศนิยม
ค่าเฉลี่ยการโหลดเป็นแนวคิดเฉพาะของ Unix บน Windows ค่าที่ส่งคืนจะเป็น [0, 0, 0] เสมอ
ใช้เพื่ออธิบายความยุ่งในปัจจุบันของระบบปฏิบัติการ สามารถเข้าใจได้ง่ายว่าเป็นจำนวนงานโดยเฉลี่ยที่ CPU ใช้และรอใช้งาน CPU ต่อหน่วยเวลา โหลดของ CPU สูงเกินไป บ่งชี้ว่ามีกระบวนการมากเกินไป ในโหนด อาจสะท้อนให้เห็นในการเริ่มกระบวนการใหม่ซ้ำๆ โดยใช้โมดูลพระราชวังต้องห้าม
const os = ต้องการ('os');
//จำนวนเธรด CPU const length = os.cpus().length;
//โหลดเฉลี่ยของ CPU คอร์เดียว ส่งคืนอาร์เรย์ที่มีโหลดเฉลี่ย 1, 5 และ 15 นาที os.loadavg().map(load => load / length) มาอธิบาย API ก่อน มิฉะนั้นคุณจะไม่สามารถอ่านได้ ทำความเข้าใจโค้ดของเราในการรับตัวบ่งชี้หน่วยความจำ
ฟังก์ชันนี้ส่งคืนพารามิเตอร์ 4 ตัว ความหมายและความแตกต่างมีดังนี้:
ใช้โค้ดต่อไปนี้เพื่อพิมพ์การใช้หน่วยความจำของกระบวนการลูก จะเห็นได้ว่า rss มีค่าเท่ากับ RES ของคำสั่งด้านบนโดยประมาณ นอกจากนี้หน่วยความจำของกระบวนการหลักมีเพียง 33M ซึ่งน้อยกว่าหน่วยความจำของกระบวนการลูก จะเห็นได้ว่าการใช้หน่วยความจำนั้นคำนวณแยกกัน
var showMem = ฟังก์ชั่น(){
var mem = กระบวนการ.memoryUsage();
รูปแบบ var = ฟังก์ชั่น (ไบต์) {
กลับ (ไบต์ / 1024/1024).toFixed(2) + 'MB';
-
console.log('กระบวนการ: heapTotal ' + รูปแบบ (mem.heapTotal) + ' heapUsed ' + รูปแบบ (mem.heapUsed) + ' rss ' + รูปแบบ (mem.rss) + ' ภายนอก:' + รูปแบบ (mem.external) );
console.log('-------------------------------------------------) --- ---------------');
}; สำหรับโหนด เมื่อหน่วยความจำรั่วเกิดขึ้น การแก้ไขปัญหาไม่ใช่เรื่องง่าย หากมีการตรวจสอบว่าหน่วยความจำเพิ่มขึ้นแต่ไม่ลดลง แสดงว่าจะต้องมีปัญหาหน่วยความจำรั่ว การใช้หน่วยความจำที่ดีควรเพิ่มขึ้นและลดลง เมื่อการเข้าถึงมีขนาดใหญ่ การเข้าถึงจะเพิ่มขึ้น และเมื่อการเข้าถึงลดลง
const os = need('os');
// ตรวจสอบการใช้งานหน่วยความจำกระบวนการโหนดปัจจุบัน const { rss, heapUsed, heapTotal } = process.memoryUsage();
// รับหน่วยความจำว่างของระบบ const systemFree = os.freemem();
// รับหน่วยความจำระบบทั้งหมด const systemTotal = os.totalmem();
โมดูล.ส่งออก = {
หน่วยความจำ: () => {
กลับ {
ระบบ: 1 - systemFree / systemTotal, // ฮีปการใช้หน่วยความจำระบบ: heapUsed / headTotal, // โหนดการใช้งานหน่วยความจำกระบวนการโหนดปัจจุบัน: rss / systemTotal, // อัตราส่วนการใช้หน่วยความจำกระบวนการโหนดปัจจุบันของหน่วยความจำระบบ}
-
} การตรวจสอบดิสก์จะตรวจสอบการใช้งานดิสก์เป็นหลัก เนื่องจากการเขียนบันทึกบ่อยครั้ง พื้นที่ดิสก์จึงค่อยๆ ใช้หมด เมื่อดิสก์ไม่เพียงพอก็จะเกิดปัญหาต่างๆ ในระบบ ตั้งค่าขีดจำกัดสูงสุดสำหรับการใช้งานดิสก์ เมื่อการใช้งานดิสก์เกินค่าคำเตือน ผู้ดูแลระบบเซิร์ฟเวอร์ควรจัดระเบียบบันทึกหรือล้างข้อมูลในดิสก์
โค้ดต่อไปนี้อ้างอิงถึง easy monitor 3.0
const { execSync } = need('child_process');
ผลลัพธ์ const = execSync('df -P', { การเข้ารหัส: 'utf8'})
เส้น const = result.split('n');
เมตริก const = {};
lines.forEach(บรรทัด => {
ถ้า (line.startsWith('/')) {
const จับคู่ = line.match(/(d+)%s+(/.*$)/);
ถ้า (ตรงกัน) {
อัตรา const = parseInt (จับคู่ [1] || 0);
const mount = การแข่งขัน [2];
if (!mounted.startsWith('/Volumes/') && !mounted.startsWith('/private/')) {
เมตริก [ติดตั้ง] = อัตรา;
-
-
-
-
console.log(metric) โหลด I/O ส่วนใหญ่อ้างถึงดิสก์ I/O ซึ่งสะท้อนถึงสถานการณ์การอ่านและเขียนบนดิสก์ สำหรับแอปพลิเคชันที่เขียนโดยโหนดซึ่งส่วนใหญ่ใช้สำหรับบริการเครือข่าย ไม่น่าเป็นไปได้ที่โหลด I/O จะสูงเกินไป แรงกดดัน I/O ของการอ่านจำนวนมากจะมาจากฐานข้อมูล .
หากต้องการรับตัวบ่งชี้ I/O เราจำเป็นต้องเข้าใจคำสั่ง Linux ที่เรียกว่า iostat หากไม่ได้ติดตั้ง คุณจะต้องติดตั้ง มาดูกันว่าเหตุใดคำสั่งนี้จึงสะท้อนถึงตัวบ่งชี้ I/O
iostat -dx
คำอธิบายคุณสมบัติ
rrqm/s: จำนวนการดำเนินการอ่านแบบผสานต่อวินาที นั่นคือ rmerge/s (จำนวนครั้งที่คำขออ่านไปยังอุปกรณ์ถูกรวมต่อวินาที และระบบไฟล์จะรวมคำขอเพื่ออ่านบล็อกเดียวกัน) wrqm/s: จำนวนการดำเนินการเขียนแบบผสานต่อวินาที นั่นคือ wmerge/s (จำนวนครั้งที่คำขอเขียนไปยังอุปกรณ์ถูกรวมเข้าด้วยกันต่อวินาที) r/s: จำนวนการอ่านจากอุปกรณ์ I/O ที่เสร็จสมบูรณ์ต่อวินาที นั่นคือริโอ/เอส w/s: จำนวนการเขียนไปยังอุปกรณ์ I/O ที่เสร็จสมบูรณ์ต่อวินาที นั่นคือ wio/s rsec/s: จำนวนเซกเตอร์ที่อ่านต่อวินาที นั่นคือ rsect/s wsec/s: จำนวนเซกเตอร์ที่เขียนต่อวินาที เช่น wsect/s rkB/s: K ไบต์ที่อ่านต่อวินาที มันคือครึ่งหนึ่งของ rsect/s เนื่องจากแต่ละเซกเตอร์มีขนาด 512 ไบต์ wkB/s: จำนวน K ไบต์ที่เขียนต่อวินาที มันคือครึ่งหนึ่งของ wsect/s avgrq-sz: ขนาดข้อมูลเฉลี่ย (เซกเตอร์) ต่อการดำเนินการ I/O ของอุปกรณ์ avgqu-sz: ความยาวคิว I/O เฉลี่ย await: เวลารอโดยเฉลี่ย (มิลลิวินาที) สำหรับการดำเนินการ I/O ของอุปกรณ์แต่ละรายการ svctm: เวลาประมวลผลเฉลี่ย (มิลลิวินาที) ของการดำเนินการ I/O ของอุปกรณ์แต่ละรายการ %util: เปอร์เซ็นต์ของหนึ่งวินาทีที่ใช้สำหรับการดำเนินการ I/O นั่นคือเปอร์เซ็นต์ของ CPU ที่ใช้โดย IO
เราจำเป็นต้องตรวจสอบ %util เท่านั้น
หาก %util ใกล้ถึง 100% หมายความว่ามี I มากเกินไป /O ร้องขอถูกสร้างขึ้น ระบบ I/O ถูกโหลดอย่างสมบูรณ์ และอาจมีปัญหาคอขวดบนดิสก์นี้
หาก await มีขนาดใหญ่กว่า svctm มาก แสดงว่าคิว I/O ยาวเกินไป และเวลาตอบสนองของแอปพลิเคชันจะช้าลง หากเวลาตอบสนองเกินช่วงที่ผู้ใช้สามารถทนได้ คุณสามารถพิจารณาเปลี่ยนดิสก์ที่เร็วกว่าได้ การปรับอัลกอริธึมเคอร์เนลลิฟต์และเพิ่มประสิทธิภาพแอปพลิเคชันหรืออัพเกรด CPU
จะตรวจสอบเวลาตอบสนองของหน้าเว็บของ Nodejs โซลูชันนี้เลือกมาจากบทความในบล็อกของอาจารย์ Liao Xuefeng
ล่าสุดฉันต้องการติดตามประสิทธิภาพของ Nodejs การบันทึกและการวิเคราะห์ Log นั้นยุ่งยากเกินไป วิธีที่ง่ายที่สุดคือการบันทึกเวลาการประมวลผลของคำขอ HTTP แต่ละรายการและส่งคืนโดยตรงใน HTTP Response Header
การบันทึกเวลาของคำขอ HTTP นั้นง่ายมาก ซึ่งหมายถึงการบันทึกการประทับเวลาเมื่อได้รับคำขอ และการบันทึกเวลาอื่นเมื่อตอบสนองต่อคำขอ ความแตกต่างระหว่างการประทับเวลาทั้งสองคือเวลาในการประมวลผล
อย่างไรก็ตาม โค้ด res.send() จะกระจายไปตามไฟล์ js ต่างๆ ดังนั้นคุณจึงไม่สามารถเปลี่ยนฟังก์ชันการประมวลผล URL ทุกฟังก์ชันได้
แนวคิดที่ถูกต้องคือการใช้มิดเดิลแวร์เพื่อให้บรรลุเป้าหมาย แต่ Nodejs ไม่มีวิธีการสกัดกั้น res.send() จะทำลายมันได้อย่างไร?
ที่จริงแล้ว ตราบใดที่เราเปลี่ยนความคิดของเราเล็กน้อย ละทิ้งวิธี OOP แบบเดิม และมองว่า res.send() เป็นฟังก์ชันออบเจ็กต์ เราก็สามารถบันทึกฟังก์ชันการประมวลผลดั้งเดิม res.send แล้วแทนที่ res.send ด้วยของเรา ฟังก์ชั่นการประมวลผลของตัวเอง:
app.use (ฟังก์ชั่น (req, res, ถัดไป) {
//บันทึกเวลาเริ่มต้น:
var exec_start_at = Date.now();
//บันทึกฟังก์ชันการประมวลผลดั้งเดิม:
var _send = ส่งอีกครั้ง;
// ผูกฟังก์ชันตัวจัดการของเราเอง:
res.send = ฟังก์ชั่น () {
//ส่งส่วนหัว:
res.set('X-Execution-Time', String(Date.now() - exec_start_at));
// เรียกใช้ฟังก์ชันการประมวลผลดั้งเดิม:
กลับ _send.apply (res, อาร์กิวเมนต์);
-
ต่อไป();
}); การประทับเวลาเสร็จสิ้นด้วยโค้ดเพียงไม่กี่บรรทัด
ไม่จำเป็นต้องประมวลผลเมธอด res.render() เนื่องจาก res.render() เรียกภายใน res.send()
เมื่อเรียกใช้ฟังก์ชัน Apply() สิ่งสำคัญคือต้องส่งผ่านวัตถุ res มิฉะนั้นฟังก์ชันการประมวลผลดั้งเดิมจะชี้ไปที่ไม่ได้กำหนด ซึ่งจะนำไปสู่ข้อผิดพลาดโดยตรง
วัดเวลาตอบสนองของหน้าแรก 9 มิลลิวินาที
อภิธานศัพท์ QPS:
QPS: การสืบค้นต่อวินาที หมายถึง "อัตราการสืบค้นต่อวินาที" ซึ่งเป็นจำนวนการสืบค้นที่เซิร์ฟเวอร์สามารถตอบสนองได้ ต่อวินาที คือการวัดปริมาณการรับส่งข้อมูลที่เซิร์ฟเวอร์สืบค้นเฉพาะจัดการภายในระยะเวลาที่กำหนด
บนอินเทอร์เน็ต ประสิทธิภาพของเครื่องที่ทำหน้าที่เป็นเซิร์ฟเวอร์ระบบชื่อโดเมนมักวัดจากอัตราการสืบค้นต่อวินาที
TPS: เป็นตัวย่อของ TransactionsPerSecond ซึ่งเป็นจำนวนธุรกรรมต่อวินาที เป็นหน่วยวัดผลการทดสอบซอฟต์แวร์ ธุรกรรมหมายถึงกระบวนการที่ไคลเอนต์ส่งคำขอไปยังเซิร์ฟเวอร์และเซิร์ฟเวอร์ตอบสนอง ไคลเอนต์เริ่มกำหนดเวลาเมื่อส่งคำขอและสิ้นสุดเมื่อได้รับการตอบกลับของเซิร์ฟเวอร์เพื่อคำนวณเวลาที่ใช้และจำนวนธุรกรรมที่เสร็จสมบูรณ์
QPS กับ TPS: โดยพื้นฐานแล้ว QPS นั้นคล้ายคลึงกับ TPS แต่ข้อแตกต่างคือการเข้าชมเพจจะสร้าง TPS แต่คำขอเพจอาจสร้างคำขอหลายรายการไปยังเซิร์ฟเวอร์ และเซิร์ฟเวอร์สามารถนับคำขอเหล่านี้เป็น " QPS" ตัวอย่างเช่น การเข้าถึงเพจจะร้องขอเซิร์ฟเวอร์สองครั้ง การเข้าถึงหนึ่งครั้งจะสร้าง "T" และ "Q" สองตัว
ตอบสนอง: เวลาทั้งหมดที่ใช้ในการดำเนินการคำขอตั้งแต่ต้นจนจบเมื่อได้รับข้อมูลการตอบสนอง นั่นคือ เวลาจากไคลเอนต์ที่เริ่มต้นคำขอจนถึงรับผลการตอบสนองของเซิร์ฟเวอร์
เวลาตอบสนอง RT (เวลาตอบสนอง) เป็นหนึ่งในตัวบ่งชี้ที่สำคัญที่สุดของระบบ ค่าตัวเลขของมันสะท้อนถึงความเร็วของระบบโดยตรง
พร้อมกัน หมายถึง จำนวนคำขอที่ระบบสามารถจัดการได้ในเวลาเดียวกัน ซึ่งยังสะท้อนถึงความสามารถในการโหลดของระบบด้วย
ปริมาณงาน (ความสามารถในการรับความดัน) ของระบบมีความสัมพันธ์อย่างใกล้ชิดกับการใช้ CPU ของคำขอ อินเทอร์เฟซภายนอก IO ฯลฯ ยิ่งการใช้ CPU ของคำขอเดียวยิ่งสูง อินเทอร์เฟซระบบภายนอกและความเร็ว IO ก็จะยิ่งช้าลง และความจุทรูพุตของระบบก็จะยิ่งต่ำลง และในทางกลับกัน
พารามิเตอร์ที่สำคัญหลายประการของทรูพุตของระบบ: QPS (TPS) จำนวนการทำงานพร้อมกัน และเวลาตอบสนอง
QPS (TPS): (แบบสอบถามต่อวินาที) จำนวนคำขอ/ธุรกรรมต่อวินาที
การทำงานพร้อมกัน: จำนวนคำขอ/ธุรกรรมที่ประมวลผลโดยระบบในเวลาเดียวกัน
เวลาตอบสนอง: โดยทั่วไป เวลาตอบสนองโดยเฉลี่ย
จะถูกคำนวณหลังจากทำความเข้าใจความหมายของข้อความข้างต้น องค์ประกอบสามประการ ความสัมพันธ์ระหว่างสิ่งเหล่านั้น:
มาทำความเข้าใจแนวคิดข้างต้นผ่านตัวอย่างกันดีกว่า ตามกฎ 80/20 หาก 80% ของการเข้าชมรายวันกระจุกตัวอยู่ใน 20% ของเวลา เวลา 20% นี้เรียกว่าเวลาสูงสุด
1 เครื่องเดียวต้องใช้ PV 300w ต่อวัน
(3000000 * 0.8) / (86400 * 0.2) = 139 (QPS)
2. ถ้า QPS ของเครื่องคือ 58 ต้องใช้กี่เครื่องเพื่อรองรับ?
139/58 = 3
ณ จุดนี้ ถ้าคุณทำสถาปัตยกรรมส่วนหน้าของโปรเจ็กต์ขนาดเล็กและขนาดกลางทั่วไป และปรับใช้บริการโหนดของคุณเอง คุณจะรู้ว่าต้องใช้เครื่องกี่เครื่องในการสร้างคลัสเตอร์เพื่อรายงาน PPT ฮ่าๆ คุณสามารถคำนวณค่าคร่าวๆ ด้วย PV
เราจำเป็นต้องเข้าใจการทดสอบความเครียด (เราจำเป็นต้องอาศัยการทดสอบความเครียดเพื่อรับ qps) ใช้คำสั่ง ab เป็นตัวอย่าง:
รูปแบบคำสั่ง:
ab [options] [http://]hostname[:port]/path
Common พารามิเตอร์มีดังนี้:
-n คำขอทั้งหมด จำนวนคำขอ -c การทำงานพร้อมกัน จำนวนการทำงานพร้อมกัน -t ขีดจำกัดเวลา จำนวนวินาทีสูงสุดสำหรับการทดสอบ ซึ่งถือเป็นเวลาหมดเวลาของคำขอ -p postfile ไฟล์ที่มีข้อมูลที่ต้องใช้ POST -T content-type ข้อมูลส่วนหัวของประเภทเนื้อหาที่ใช้โดยข้อมูล POST คัดลอกโค้ด