ฉันไม่มีกรอบอ้างอิงในแง่ของสิ่งที่ถือว่า "เร็ว" ฉันสงสัยมาตลอด แต่ไม่เคยพบคำตอบที่ตรง ...
คำตอบ:
OpenStreetMap ดูเหมือนว่าจะมี10-20 ต่อวินาที
Wikipedia ดูเหมือนจะ30000 ถึง 70000 ต่อวินาทีที่แพร่กระจายไปทั่ว300 เซิร์ฟเวอร์ (100 ถึง 200 คำขอต่อวินาทีต่อเครื่องซึ่งส่วนใหญ่เป็นแคช)
Geograph ได้รับภาพ 7000 ภาพต่อสัปดาห์ (1 อัปโหลดต่อ 95 วินาที)
ไม่แน่ใจว่ายังมีใครสนใจ แต่ข้อมูลนี้ถูกโพสต์เกี่ยวกับ Twitter (และที่นี่ด้วย ):
สถิติ
- ผู้ใช้มากกว่า 350,000 คน ตัวเลขที่แท้จริงเป็นความลับสุดยอดมากเช่นเคย
- 600 คำขอต่อวินาที
- เฉลี่ย 200-300 การเชื่อมต่อต่อวินาที เพิ่มขึ้นถึง 800 การเชื่อมต่อต่อวินาที
- MySQL จัดการ 2,400 คำขอต่อวินาที
- 180 Rails อินสแตนซ์ ใช้ Mongrel เป็นเซิร์ฟเวอร์ "เว็บ"
- 1 เซิร์ฟเวอร์ MySQL (กล่องใหญ่ 8 คอร์หนึ่งกล่อง) และ 1 ทาส Slave อ่านได้สำหรับสถิติและการรายงานเท่านั้น
- 30+ กระบวนการสำหรับจัดการงานแปลก ๆ
- 8 อา X4100s.
- ดำเนินการตามคำขอใน 200 มิลลิวินาทีใน Rails
- เวลาเฉลี่ยที่ใช้ในฐานข้อมูลคือ 50-100 มิลลิวินาที
- memcached มากกว่า 16 GB
เมื่อฉันไปที่แผงควบคุมของเว็บโฮสต์ของฉันเปิด phpMyAdmin และคลิกที่ "แสดงข้อมูลรันไทม์ MySQL" ฉันจะได้รับ:
เซิร์ฟเวอร์ MySQL นี้ทำงานเป็นเวลา 53 วัน 15 ชั่วโมง 28 นาทีและ 53 วินาที เริ่มต้นเมื่อ 24 ต.ค. 2551 เวลา 04:03 น.
สถิติการสืบค้น: ตั้งแต่เริ่มต้นมีการส่งแบบสอบถาม 3,444,378,344 ไปยังเซิร์ฟเวอร์
รวม 3,444 M
ต่อชั่วโมง 2.68 M
ต่อนาที 44.59 k
ต่อวินาที 743.13
นั่นคือค่าเฉลี่ยของการสืบค้น mySQL 743 รายการต่อวินาทีในช่วง 53 วันที่ผ่านมา
ฉันไม่รู้เกี่ยวกับคุณ แต่สำหรับฉันมันเร็วมาก! เร็วมาก!!
โดยส่วนตัวแล้วฉันชอบทั้งการวิเคราะห์ที่ทำทุกครั้ง .... คำขอ / วินาทีและเวลาเฉลี่ย / คำขอและชอบดูเวลาขอสูงสุดเช่นกันนอกจากนั้น มันง่ายที่จะพลิกหากคุณมี 61 คำขอ / วินาทีจากนั้นคุณสามารถพลิกไปที่คำขอ 1,000 มิลลิวินาที / 61
เพื่อตอบคำถามของคุณเราได้ทำการทดสอบการโหลดครั้งใหญ่ด้วยตัวเองและพบว่ามีการใช้งานกับฮาร์ดแวร์ amazon ต่างๆที่เราใช้ (ค่าที่ดีที่สุดคือ CPU ขนาดกลาง 32 บิตเมื่อลงมาที่ $$ / เหตุการณ์ / วินาที) และคำขอ / วินาทีของเรา ตั้งแต่ 29 คำขอ / วินาที / โหนดสูงสุด 150 คำขอ / วินาที / โหนด
แน่นอนว่าการให้ฮาร์ดแวร์ที่ดีกว่านั้นให้ผลลัพธ์ที่ดีกว่า แต่ไม่ใช่ ROI ที่ดีที่สุด อย่างไรก็ตามโพสต์นี้ยอดเยี่ยมมากเพราะฉันกำลังมองหาแนวร่วมบางอย่างเพื่อดูว่าหมายเลขของฉันอยู่ที่ไหนในสนามเบสบอลและแชร์ของฉันด้วยในกรณีที่มีคนอื่นกำลังมองหา ของฉันโหลดสูงที่สุดเท่าที่ฉันจะทำได้
หมายเหตุ: ขอบคุณคำขอ / การวิเคราะห์ที่สอง (ไม่ใช่ ms / คำขอ) เราพบปัญหาลินุกซ์ที่สำคัญที่เรากำลังพยายามแก้ไขโดยที่ linux (เราทดสอบเซิร์ฟเวอร์ใน C และ java) หยุดการโทรทั้งหมดในไลบรารีซ็อกเก็ตเมื่อโหลดมากเกินไป ซึ่งดูแปลกมาก สามารถดูโพสต์แบบเต็มได้ที่นี่จริง .... http://ubuntuforums.org/showthread.php?p=11202389
เรายังคงพยายามแก้ไขปัญหาดังกล่าวเนื่องจากทำให้การทดสอบของเราเพิ่มขึ้นอย่างมากจาก 2 นาที 42 วินาทีถึง 1 นาที 35 วินาทีเมื่อได้รับการแก้ไขดังนั้นเราจึงเห็นการปรับปรุงประสิทธิภาพ 33% .... ไม่ต้องพูดถึง ยิ่งการโจมตี DoS แย่ลงคือการหยุดชั่วคราวเหล่านี้นานขึ้นเพื่อให้ cpus ทั้งหมดลดลงเหลือศูนย์และหยุดการประมวลผล ... ในความคิดของฉันการประมวลผลเซิร์ฟเวอร์ควรดำเนินต่อไปเมื่อเผชิญกับ DoS แต่ด้วยเหตุผลบางอย่างมันก็หยุดทำงานทุกครั้ง ในบางครั้ง Dos นานถึง 30 วินาที !!!
เพิ่มเติม: เราพบว่ามันเป็นข้อผิดพลาดเงื่อนไขการแข่งขัน jdk .... ยากที่จะแยกในคลัสเตอร์ขนาดใหญ่ แต่เมื่อเรารัน 1 เซิร์ฟเวอร์ 1 โหนดข้อมูล แต่ 10 โหนดเราสามารถสร้างซ้ำได้ทุกครั้งและดูที่เซิร์ฟเวอร์ / datanode เกิดขึ้นเมื่อ การเปลี่ยน jdk เป็นรุ่นก่อนหน้าช่วยแก้ปัญหาได้ เราอยู่บน jdk1.6.0_26 ฉันเชื่อ
นั่นเป็นคำถามประเภทแอปเปิ้ลกับส้มที่เปิดกว้างมาก
คุณกำลังถาม 1. โหลดคำขอเฉลี่ยสำหรับแอปพลิเคชันที่ใช้งานจริง 2. สิ่งที่ถือว่าเร็ว
สิ่งเหล่านี้ไม่เกี่ยวข้องกัน
จำนวนคำขอเฉลี่ยต่อวินาทีของคุณถูกกำหนดโดย
จำนวนผู้ใช้พร้อมกัน
ข จำนวนหน้าที่เฉลี่ยของคำขอต่อวินาที
ค. จำนวนคำขอเพิ่มเติม (เช่นการโทร ajax ฯลฯ )
สิ่งที่ถือว่าเร็ว .. คุณหมายถึงว่ามีคำขอเพียงไม่กี่ไซต์? หรือถ้าชิ้นส่วนของฮาร์ดแวร์ถือว่าเร็วหากสามารถประมวลผล xyz # ของคำขอต่อวินาทีได้?
โปรดทราบว่ากราฟอัตราการเข้าชมจะเป็นรูปแบบไซน์โดย "ชั่วโมงเร่งด่วน" อาจเป็น 2 เท่าหรือ 3 เท่าของอัตราที่คุณได้รับในขณะที่ผู้ใช้กำลังนอนหลับ (จะมีประโยชน์เมื่อคุณตั้งเวลาการประมวลผลชุดประจำวันที่จะเกิดขึ้นบนเซิร์ฟเวอร์)
คุณสามารถดูผลได้แม้ในไซต์ "นานาชาติ" (หลายภาษาแปลเป็นภาษาท้องถิ่น) เช่น wikipedia
น้อยกว่า 2 วินาทีต่อผู้ใช้โดยปกตินั่นคือผู้ใช้ที่เห็นการตอบสนองช้ากว่านี้คิดว่าระบบทำงานช้า
ตอนนี้คุณบอกฉันว่าคุณเชื่อมต่อกับผู้ใช้กี่คน
คุณสามารถค้นหา "การวิเคราะห์ผลกระทบ slashdot" สำหรับกราฟของสิ่งที่คุณจะได้เห็นถ้าลักษณะของเว็บไซต์บางส่วนก็กลายเป็นที่นิยมในข่าวเช่นกราฟนี้ในวิกิพีเดีย
เว็บแอปพลิเคชันที่อยู่รอดมักจะเป็นเว็บที่สามารถสร้างเพจแบบคงที่แทนที่จะส่งทุกคำขอผ่านภาษาประมวลผล
มีวิดีโอที่ยอดเยี่ยม (ฉันคิดว่ามันอาจจะอยู่บน ted.com ฉันคิดว่ามันอาจจะมาจากทีมงานเว็บ flickr หรือไม่มีใครรู้ลิงค์หรือไม่) พร้อมแนวคิดเกี่ยวกับวิธีการปรับขนาดเว็บไซต์ให้เกินเซิร์ฟเวอร์เดียวเช่นวิธีการ จัดสรรการเชื่อมต่อระหว่างเซิร์ฟเวอร์แบบอ่านอย่างเดียวและแบบอ่าน - เขียนเพื่อให้ได้ผลดีที่สุดสำหรับผู้ใช้ประเภทต่างๆ