Score:0

สิ่งใดที่อาจทำให้คำขอถูกบล็อกใน IIS

ธง gl

ฉันใช้ IIS บน Windows Server 2016 กับ MySQL และ PHP บนเซิร์ฟเวอร์สองเครื่องที่เกือบจะเหมือนกัน เมื่อเร็ว ๆ นี้ฉันสังเกตเห็นการชะลอตัวของหนึ่งในสองเซิร์ฟเวอร์ของฉัน แต่จะเกิดขึ้นเมื่อไซต์ของฉันพยายามเรียกใช้สคริปต์หลาย ๆ อินสแตนซ์ในเวลาเดียวกันเท่านั้น พวกเขาดูเหมือนจะติดกัน

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

เซิร์ฟเวอร์ที่ไม่ดี ป้อนคำอธิบายรูปภาพที่นี่

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

เซิร์ฟเวอร์ที่ไม่ดี ป้อนคำอธิบายรูปภาพที่นี่

โปรดทราบว่าการสืบค้นเหล่านี้ใช้เวลาเพียงเสี้ยววินาทีเมื่อรันใน MySQL Workbench และเมื่อรันบนเซิร์ฟเวอร์อื่นของฉันซึ่งไม่ได้ประสบปัญหานี้ ดูในภาพหน้าจอนี้ (จากเซิร์ฟเวอร์ที่ดี) การค้นหาเดียวกันจะกลับมาในเสี้ยววินาที

เซิร์ฟเวอร์ที่ดี ป้อนคำอธิบายรูปภาพที่นี่

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

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

เซิร์ฟเวอร์ที่ไม่ดี ป้อนคำอธิบายรูปภาพที่นี่

ฉันได้ทำการเปลี่ยนแปลงบางอย่างกับเซิร์ฟเวอร์ที่ไม่ดีเมื่อเร็วๆ นี้ แต่เท่าที่ฉันจำได้ การเปลี่ยนแปลงเดียวที่ฉันทำคืออนุญาตการอัปโหลดไฟล์ที่ใหญ่ขึ้น

  • ใน PHP ฉันเพิ่ม post_max_size = 500M
  • ใน PHP ฉันเพิ่ม upload_max_filesize = 500M
  • ใน IIS ฉันเพิ่ม UploadReadAheadSize เป็น 49152000
  • ใน IIS ฉันเพิ่มความยาวเนื้อหาสูงสุดที่อนุญาตเป็น 300000000

เป็นไปได้ว่าฉันทำการเปลี่ยนแปลงอื่นๆ กับเซิร์ฟเวอร์นี้โดยที่ฉันจำไม่ได้

แก้ไขชั่วคราว

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

สิ่งที่ฉันได้ลอง

จนถึงตอนนี้ฉันได้ยืนยันแล้วว่าการกำหนดค่า IIS, การกำหนดค่า MySQL (my.ini) และการกำหนดค่า PHP (php.ini) ของฉันนั้นเหมือนกันทุกประการในทุก ๆ ด้านที่สำคัญบนเซิร์ฟเวอร์ทั้งสอง (อย่างน้อยก็เท่าที่ฉันเห็นได้ชัดเจน) . ฉันยังยืนยันว่าคำสั่ง Select ที่ฉันเรียกใช้ในการค้นหานี้ทำงานได้ดีพอๆ กันบนเซิร์ฟเวอร์ทั้งสอง หากฉันดำเนินการใน MySQL Workbench เฉพาะในเว็บแอปของฉันเท่านั้นที่ฉันประสบปัญหานี้

ฉันเลิกทำการเปลี่ยนแปลงสองรายการที่ทำกับ IIS เป็นการชั่วคราวสำหรับการอัปโหลดไฟล์ขนาดใหญ่ในกรณีดังกล่าว แต่นั่นดูเหมือนจะไม่สร้างความแตกต่าง

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

อาการอื่น ๆ

ฉันพบปัญหาที่คล้ายกันหากฉันเปิดรายงานหลายฉบับพร้อมกัน ถ้าฉันอนุญาตให้รายงานหนึ่งโหลดเสร็จก่อนที่จะเปิดรายงานถัดไป รายงานทั้งหมดจะโหลดอย่างรวดเร็ว แต่ถ้าฉันบังคับให้แอปเปิดหลายรายงานพร้อมกัน รายงานทั้งหมดจะค้าง

อะไรเป็นสาเหตุของปัญหาคอขวดนี้

Wilson Hauck avatar
jp flag
โพสต์จากเซิร์ฟเวอร์ FAST และ SLOW ขอข้อมูลเพิ่มเติม ขนาด RAM, # คอร์, อุปกรณ์ SSD หรือ NVME ใด ๆ บนเซิร์ฟเวอร์ MySQL? โพสต์บน pastebin.com และแชร์ลิงก์ จากรูทการเข้าสู่ระบบ SSH ของคุณ ผลลัพธ์ข้อความของ: B) แสดงสถานะทั่วโลก; หลังจาก UPTIME ขั้นต่ำ 24 ชั่วโมง C) แสดงตัวแปรทั่วโลก; D) แสดงรายการกระบวนการทั้งหมด; จ) สถานะ; ไม่แสดงสถานะเพียงสถานะ; F) กรอกรายงาน www.MySQLTuner.pl (perl) หรือที่คล้ายกัน G) แสดงสถานะ INNODB ของเครื่องยนต์ สำหรับการวิเคราะห์การปรับแต่งเวิร์กโหลดของเซิร์ฟเวอร์เพื่อให้คำแนะนำ
Wilson Hauck avatar
jp flag
เครื่องยนต์ FEDERATED มีส่วนเกี่ยวข้องหรือไม่?
gl flag
@WilsonHauck ไม่ ไม่ใช่ในกรณีนี้ ฉันได้ย้ายออกจากตารางรวมทั้งหมดแล้ว พวกเขาสร้างปัญหามากเกินไปอย่างที่คุณทราบ :-)
Wilson Hauck avatar
jp flag
ยอดเยี่ยม. ขอให้มีความสุขในวันหยุดสุดสัปดาห์
Score:0
ธง us

ฉันคิดว่าไม่ใช่เซิร์ฟเวอร์ IIS ที่มีปัญหาที่นี่ ทุกสิ่งที่คุณค้นหาคุณต้องเรียกใหม่ในรหัสของคุณและดูเหมือนว่ามีบางอย่างในสคริปต์ PHP ของคุณที่ต้องใช้เวลานาน

ทุกครั้งที่คุณส่งคำขอใหม่ คุณเพียงแค่บล็อกอินสแตนซ์ PHP ใหม่ และเมื่อ PHP หมดอินสแตนซ์ก็จะหยุดทำงาน

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

ตอนนี้ฉันแค่เดาว่าดีที่สุดเท่าที่จะทำได้ ดูเหมือนว่าคุณกำลังใช้ regex หรือฟังก์ชันที่คล้ายกันในฐานข้อมูล SQL ของคุณและเมื่อคุณมีหลายแถว การโทรออกช้ามาก นั่นเป็นสาเหตุที่ทำให้แฮงค์มาก

แต่อีกครั้งฉันแค่เดาว่าฉันรู้ผลการทดสอบที่ฉันบอกให้คุณทำช้าเกินไป

gl flag
ฉันจะลองแสดงความคิดเห็นในโค้ดเพื่อดูว่าฉันสามารถแยกมันได้อีกหรือไม่ แต่อย่างที่ฉันพูดใน OP ของฉัน การเรียกที่เลือกนั้นรวดเร็วหากฉันเรียกมันใน MySQL Workbench หรือถ้าฉันเรียกใช้การค้นหาเพียงครั้งเดียว
Score:0
ธง gl

ปรากฎว่าการเรนเดอร์ HTML ทำให้แฮงค์ เมื่อผลการค้นหาของฉันยาว เบราว์เซอร์จะใช้เวลานานในการแสดงผล HTML ทั้งหมด และในขณะที่ดำเนินการนั้น เบราว์เซอร์ไม่สามารถประมวลผลคำขอถัดไปได้

ฉันแก้ปัญหาด้วยการจำกัดผลการค้นหาไว้ที่ 50 แถว ดังนั้นตอนนี้ HTML จึงแสดงผลเกือบจะทันทีและคำขอถัดไปก็สามารถดำเนินการได้ ดังนั้นจึงไม่ใช่ IIS ที่บล็อกคำขอ แต่เป็นเบราว์เซอร์

โพสต์คำตอบ

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