ฉันรวมไซต์ D7 เข้าด้วยกันด้วยหัวข้อย่อย Minelli ตามวิธีที่ฉันทดลองมากด้วยธีมที่แตกต่างกันโมดูลที่แตกต่างกัน อยู่ที่ไหนสักแห่งระหว่างที่ฉันพัฒนาปัญหาประสิทธิภาพแปลก ๆ และตอนนี้ฉันไม่รู้จริง ๆ ว่าชุดรูปแบบ / โมดูล / การกำหนดค่าเกิดจากอะไร

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

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

ฉันจะไปที่ไหนต่อไป

มีสามสิ่งที่ฉันจะตรวจสอบ

หนึ่งถ้าคุณอยู่ในไซต์การผลิตและไม่แก้ไขไฟล์ PHP คุณควรตรวจสอบให้แน่ใจว่า APC เปิดใช้งานมีหน่วยความจำเพียงพอและมี TTL ยาว (คุณสามารถไปกับวันหรือไม่หมดอายุหากคุณต้องการ) apc.stat=0นอกจากนี้คุณยังสามารถพิจารณาการตั้งค่า เอกสาร APCมีข้อมูลทั้งหมดที่คุณต้องการสำหรับการตั้งค่า TTL สำหรับการเลือกจำนวนหน่วยความจำคุณควรติดไฟล์ apc.php ไว้ที่อื่นเพื่อป้องกันและตรวจสอบการใช้หน่วยความจำและสถิติปั่นป่วน ปรับหน่วยความจำ APC เพื่อให้อัตราการพลาดของคุณต่ำมาก ความช้าเริ่มต้นอาจเป็นเพราะ APC เต็มและปล่อยออกมา (IIRC, APC จะทิ้งแคชทั้งหมดเมื่อเต็มแทนที่จะใช้ LRU หรือกลยุทธ์แคชขั้นสูงขึ้นไป)

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

ประการที่สามตรวจสอบให้แน่ใจว่าคุณมีกลยุทธ์cron ของ Drupalอย่างแท้จริง ส่วนตัวฉันจะปิดการใช้งานอัตโนมัติ cagic ใน "admin / config / system / cron" และตั้งค่า crontab ให้ทำงานทุกคืน คุณสามารถลองใช้Elysia Cron ได้หากคุณต้องการควบคุมสิ่งต่างๆอย่างละเอียดยิ่งขึ้น วิธีนี้คุณสามารถทำงานที่จำเป็นได้บ่อยเท่าที่ต้องการ แต่ให้ทำงานปกติข้ามคืน ความเชื่องช้าเริ่มแรกของคุณอาจมาจาก cron ที่เกิดขึ้นทุก ๆ ชั่วโมง คุณสามารถยืนยันสิ่งนี้ได้โดยดูเมื่อ cron รันใน "admin / reports / dblog" และพยายามที่จะจับคู่กับความเชื่องช้าของคุณ

Ivanhoe123 น่าจะถูกต้อง: Drupal 7 มาพร้อมกับ 'คนที่ไม่ดี cron' เปิดใช้งานโดยค่าเริ่มต้น ในระยะสั้นก็หมายความว่า cron จะถูกเรียกใช้ก่อนที่ Drupal จะแสดงหน้าเว็บ

พยายามใช้งาน cron จริงบนไซต์ที่ใช้งานจริง สำหรับรายละเอียดทางเทคนิคเพิ่มเติมโปรดดูที่http://drupal.org/cronหรือพูดคุยกับ บริษัท โฮสติ้งของคุณ

หากต้องการปิดใช้งานไปที่ผู้ดูแลระบบ / กำหนดค่า / ระบบ / cron และเลือก 'ไม่เคย'

Develเข้าสู่ระบบฐานข้อมูลโมดูลข้อเสนอที่จะตรวจสอบว่าคุณมีข้อสงสัยใด ๆ ที่ทำงานนาน

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

เพียงแค่จากรสชาติของคำถามฉันคิดถึงสามสิ่งในทันที

• MySQL Storage Engine / CPU
• การแคชฐานข้อมูล
• ล็อคตาราง

เครื่องมือจัดเก็บ MySQL

หากคุณไม่ได้ใช้การค้นหา / การจัดทำดัชนี FULLTEXT ใด ๆ ฉันขอแนะนำให้คุณแปลงข้อมูล MyISAM ทั้งหมดของคุณเป็น InnoDB MyISAM ไม่ได้ออกแบบมาเพื่อใช้ประโยชน์จาก CPU หลายตัวและหลายคอร์ InnoDB ได้รับการปรับปรุงอย่างมากสำหรับการใช้งานหลาย CPU รวมถึงการอ่าน / เขียนไฮเปอร์เธรด

นี่คือข้อความบางส่วนที่ฉันทำเกี่ยวกับเรื่องนี้ใน DBA StackExchange และในเว็บไซต์นี้เกี่ยวกับการปรับแต่ง MySQL สำหรับประสิทธิภาพของ InnoDB

• Sep 20, 2011: หลายคอร์และประสิทธิภาพ MySQL
• Sep 12, 2011: เป็นไปได้ที่จะทำให้ MySQL ใช้มากกว่าหนึ่งคอร์
• Jun 07, 2011: ฉันจะแปลงฐานข้อมูลจาก MyISAM เป็น InnoDB ได้อย่างไร
• May 26, 2011: เกี่ยวกับประสิทธิภาพของฐานข้อมูลเธรดเดี่ยวและเธรดแบบมัลติเธรด
• Apr 15, 2011: https://drupal.stackexchange.com/questions/1715/what-would-be-the-optimal-mysql-configuration-for-a-drupal-7-site/2367#2367

การแคชฐานข้อมูล

อีกข้อโต้แย้งที่สำคัญสำหรับการแปลงข้อมูล MyISAM ทั้งหมดเป็น InnoDB คือวิธีที่ MySQL เก็บข้อมูล / ดัชนี MyISAM Storage Engine เก็บเฉพาะดัชนีแคช InnoDB เก็บข้อมูลและจัดทำดัชนี ด้วยเหตุนี้คุณสามารถจัดสรรหน่วยความจำให้เพียงพอสำหรับ InnoDB Buffer Pool เพื่อรองรับหนึ่งในรายการต่อไปนี้ (แล้วแต่จำนวนใดจะน้อยกว่า)

• ข้อมูลและดัชนี InnoDB ทั้งหมด (เหมาะอย่างยิ่งหากคุณมี RAM เพียงพอสำหรับมันและสำหรับระบบปฏิบัติการ; กำจัดความล่าช้าที่ตามมา)
• 75% ของ RAM ที่ติดตั้ง (ในกรณีที่คุณมีข้อมูล / ดัชนี InnoDB เพิ่มเติมว่า RAM ลดความล่าช้าให้น้อยที่สุด)

หากคุณใช้ MySQL 5.1 คุณสามารถตั้งค่าinnodb_max_dirty_pages_pct = 0 ซึ่งจะเพิ่มดิสก์ I / O เพียงเล็กน้อย แต่ InnoDB Buffer Pool จะถูกล้างข้อมูลเพียงพอที่จะอนุญาตให้ข้อมูลเก่าและหน้าดัชนีหมุนออกโดยไม่ต้องใช้ดิสก์ I / O ปลั๊กอิน InnoDB ของ MySQL 5.5 และ MySQL 5.1 ไม่ต้องการการปรับค่านี้เนื่องจากมีกลไกการล้างข้อมูลบัฟเฟอร์เริ่มต้นที่ดีกว่า

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

ล็อคตาราง

• InnoDB ไม่ล็อคระดับแถวซึ่งช่วยให้การทำธุรกรรมและการ nonblocking อ่าน
• MyISAM เพียง แต่ล็อคตารางเต็มรูปแบบสำหรับทุก INSERT, UPDATE และลบ

ถ้อยคำส

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

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

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

เสียงเหมือน cron กำลังทำงานอยู่

ตรวจสอบการตั้งค่าของคุณที่นี่: admin / config / system / cron

ฉันเกือบจะทิ้ง Drupal สำหรับโครงการสุดท้ายของฉันเพราะสิ่งนี้

ฉันต้องมีมากกว่าหนึ่งสาเหตุ ฉันยังไม่พบโซลูชัน 'แก้ไขทั้งหมด' ที่ใช้งานได้ทุกครั้งที่ปัญหานี้เกิดขึ้น

Syslog และ Ubuntu / Debain

ครั้งแรกที่ฉันวิ่งข้ามความเร็วในการโหลดเป็นระยะเวลา 15 วินาทีคือขณะที่ใช้งาน drupal บนระบบที่ใช้ Debian / Ubuntu โดยเฉพาะ (ไม่แบ่งใช้) การปิดใช้งานโมดูล Syslogเป็นวิธีแก้ปัญหาสำหรับฉัน

ดังที่ @BetaRide กล่าวว่าการใช้ xDebug หรือผู้สร้างโปรไฟล์ PHP อื่น ๆ นั้นให้ความกระจ่างอย่างยิ่ง

ยังคงมีปัญหา - วิธีแก้ปัญหา

สำหรับการติดตั้งอื่น ๆ ของฉันฉันยังคงสูญเสีย

ปัญหานี้ชัดเจนมากขึ้นในเซิร์ฟเวอร์การพัฒนาของฉันและการติดตั้ง Drupal ที่มีปริมาณน้อย

เพื่อเป็นการหลีกเลี่ยงปัญหาฉันได้ตั้งค่างาน cron เพื่อโหลดหน้าแรกของไซต์ทุก ๆ 60 วินาทีรวมถึงสคริปต์ cron ของ Drupal ทุก ๆ 300 วินาที เห็นได้ชัดว่าไม่ได้ดีที่สุด แต่ฉันอยากจะลองใช้เวลาโหลด 15 วินาทีแทนผู้มาเยี่ยมชม

หลายคนแนะนำให้ปัญหานี้อาจจะเกี่ยวข้องกับการปิดกั้นกระบวนการพื้นหลังซิงโครที่เกี่ยวข้องโดยเฉพาะอย่างยิ่งงาน cron หนัก

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

• กระบวนการพื้นหลังและโมดูลที่รวมมานั้นอนุญาตให้ประมวลผลคิวกระบวนการส่วนหลังของ Drupal แบบอะซิงโครนัสดังนั้นจึงไม่บล็อก สิ่งนี้สามารถหยุดปัญหาได้ นอกจากนี้ด้วยโมดูลแบ็คกราวนด์กระบวนการ Apache Server ที่รวมอยู่ใน dev ล่าสุดจะมีรายงาน UI พื้นฐาน แต่ปรับปรุงด้วยคุณสมบัติในการดูแลปลดล็อกและตรวจสอบเวลาเริ่มต้นและความคืบหน้าของกระบวนการเหล่านี้ สิ่งนี้สามารถระบุกระบวนการที่เป็นปัญหาได้
• Ultimate Cronสร้างกระบวนการพื้นหลังเพื่อให้งาน cron ทริกเกอร์มี scehid asynchronous แยกของพวกเขาซึ่งแต่ละคนสามารถตรวจสอบและหยุดใน UI เช่นเดียวกับการที่ยอดเยี่ยมสำหรับการแยกงานที่หนักหน่วงในการแยกงานออกจากการล้างข้อมูลค่าใช้จ่ายต่ำเป็นประจำนอกจากนี้ยังให้รายงานที่มีข้อมูลที่สะดวกเช่นระยะเวลาการทำงานของงาน cron ที่ถูกเรียกแต่ละครั้งเมื่อทำงานล่าสุดสถานะปัจจุบัน เป็นต้นซึ่งสามารถลบการบล็อกจากและ / หรือระบุกระบวนการที่เป็นปัญหา

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

อย่างไรก็ตามหากไม่สามารถกำหนดค่าให้ช่วยได้นั่นแสดงว่ามีปัญหามากกว่ากระบวนการพื้นหลังแบบซิงโครนัส FWIW ฉันไม่เคยมีปัญหานี้ในไซต์ใด ๆ ตั้งแต่ทำให้โมดูลเหล่านี้ทำงานได้อย่างถูกต้อง (ยัง - touch wood) - แต่ฉันเคยเห็นมันในเว็บไซต์ของฉันมาก่อนรวมถึงไซต์ Drupal สดๆ

นอกจากนี้ควรระวังโมดูลปลั๊กอินที่เกี่ยวข้องอื่น ๆ ที่กำลังพัฒนาเช่นในกรณีที่มีความเข้มสูงซับซ้อนUltimate Cron Queue Scalerซึ่งอนุญาตการควบคุมปริมาณตามเกณฑ์อาจช่วยลดปัญหาประสิทธิภาพ cron ที่เกี่ยวข้อง

* ไม่มีส่วนเกี่ยวข้องฉันเป็นเพียงผู้ใช้ที่ประทับใจในงานของพวกเขามาก

ตั้งแต่นี้จะตีฉันอีกครั้งฉัน startet ทำการตรวจสอบปัญหา ฉันสามารถยืนยันได้อย่างแน่นอน

1. การเรียกเพื่อdrupal_cron_run()ให้ทำงานโดยแกนหลักของ poorman เพิ่ม ~ 5s ให้กับเวลาที่ร้องขอบนเครื่อง dev ของฉัน นี้สามารถทดสอบโดย uncommenting ทดสอบรอบการเรียกร้องให้drupal_cron_run()ในmodules/system/system.moduleในsystem_run_automated_cron()
2. การล้างแคชทั้งหมดเพิ่มเวลาในการร้องขอบนเครื่อง dev ของฉัน ~ 2 วินาที สิ่งนี้สามารถทดสอบได้โดยการทำdrush cc allและโหลดหน้าซ้ำอีกครั้ง

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

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

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

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

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

2. หากผลลัพธ์จากขั้นตอนที่ 1 ดีและเซิร์ฟเวอร์ตอบสนองอย่างรวดเร็วและคำขอต่อไปนี้นั้นรวดเร็วให้ติดตั้งเฉพาะธีมจากไซต์ปัจจุบันของคุณไปยังไซต์ติดตั้งใหม่ทั้งหมดและทดสอบอีกครั้ง หากทุกอย่างยังคงตอบสนองอย่างรวดเร็วธีมของคุณจะไม่เป็นปัญหาและคุณควรดำเนินการต่อในขั้นตอนที่ 3 ไม่เช่นนั้นคุณจะต้องเริ่มแก้ไขข้อบกพร่องของธีม * 1

3. หากหลังจากการทดสอบในขั้นตอนที่ 2 ไซต์ยังคงเริ่มต้นอย่างรวดเร็วนำโมดูลในไซต์ปัจจุบันของคุณและให้แน่ใจว่าได้ทดสอบเวลาตอบสนองหลังจากการเพิ่มและเปิดใช้งานแต่ละโมดูล * 2

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

5. การตั้งค่าและการกำหนดค่าพร้อมและไซต์ยังคงรวดเร็วตอนนี้นำข้อมูลมา โหนดนำเข้าข้อกำหนดเกี่ยวกับอนุกรมวิธานความคิดเห็น ฯลฯ ฉันรู้ว่าฉันต้องฟังเหมือนระเบียนที่เสียหาย แต่จะทดสอบทุกครั้งหลังจากทำตามขั้นตอนทุกครั้ง

* 1 การทดสอบชุดรูปแบบ:กระบวนการนี้อาจยุ่งยากในชุดรูปแบบที่ละเอียดยิ่งขึ้นต่อไปนี้เป็นตัวชี้สองสามข้อ:

1. หากคุณลิงก์ไปยังไลบรารี js หรือ css ภายนอกให้ลองใช้สำเนาโลคัลของเดียวกัน

2. ในไฟล์ template.php ของคุณตรวจสอบฟังก์ชันที่อาจมีลูปที่ยาวกว่าหรือไม่มีที่สิ้นสุดรวมถึงฟังก์ชัน preprocess และ / หรือฟังก์ชันธีม hook

3. ตรวจสอบไฟล์เทมเพลตอื่น ๆ (page.tpl.php และอื่น ๆ ) และค้นหาการประมวลผล PHP แบบอาร์เรย์และวัตถุ

4. หากใช้ "มุมมอง" และมุมมองไฟล์เทมเพลตให้ตรวจสอบด้วยเช่นกัน

5. ตรวจสอบพา ธ ซ้ำเพิ่มประสิทธิภาพของภาพ js และ css เสมอ บางครั้งไฟล์ js อาจมีความสูงหนักเมื่อใช้โค้ดหลายชุดในไฟล์เดียว

* 2 โมดูลทดสอบ: โมดูลทดสอบแตกต่างกันเล็กน้อยเนื่องจากอนุญาตให้ใช้การจัดการกับ PHP อย่างหนัก นี่คือตัวชี้:

1. โมดูลที่สนับสนุนโดยชุมชน (CCK, Views และอื่น ๆ ) มีคิวปัญหาใน drupal.org ตรวจสอบเพื่อดูว่ามีปัญหาใด ๆ ที่มีอยู่เกี่ยวกับปัญหาของคุณหรือไม่และหากมีโอกาสเป็นไปได้ว่าอาจมีโปรแกรมแก้ไขเพื่อแก้ไข

2. เป็นเจ้าของโมดูลรหัสที่กำหนดเองได้หรือไม่ถ้าคุณเข้ารหัสคุณต้องแก้ไขใช่มั้ย ตรวจสอบการเข้ารหัสของคุณอีกครั้งและตรวจสอบการใช้ฟังก์ชั่นกับ api.drupal.org คุณอาจใช้ฟังก์ชัน overkilling แทนการใช้ hook

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

4. หากเว็บไซต์ของคุณเป็นการอัพเกรด (D5 -> D6 -> D7) ตรวจสอบการโยกย้ายหรืออัปเกรดสคริปต์ (โดยปกติจะอยู่ในไฟล์ module.install) คุณอาจต้องมี "ดัชนี" เพิ่มเติมในการกำหนดค่าตารางใหม่เพื่อให้แบบสอบถาม SQL ช้า X เร็วขึ้น .

5. หากคุณคิดว่าคุณมีวิสัยทัศน์ที่ชัดเจนเกี่ยวกับปัญหาลองก้าวออกมาเล็กน้อยและทำกิจกรรมอื่น ๆ ที่ไม่เกี่ยวข้องโดยสิ้นเชิงจากนั้นกลับมาอีกครั้งเพื่อกลับมาดูปัญหาอีกครั้ง

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

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

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

ลบการอ้างอิงในตารางตัวแปรหากโมดูลนั้นไม่มีอยู่อีกต่อไป

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

บางคนกล่าวว่า GoDaddy จะช้า บริษัท โฮสติ้งบนคลาวด์หลายแห่งจะมีความล่าช้าในเบื้องต้นเนื่องจากบริการต่างๆเช่น AWS การที่เซิร์ฟเวอร์ถูกลดความสำคัญลงโดยอัตโนมัติและเซิร์ฟเวอร์เหล่านั้นจะต้องใช้เวลาหนึ่งหรือสองวินาทีในการ 'ปลุก'

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

นอกจากนี้ CDN สามารถช่วยคุณได้ เว็บ / ฐานข้อมูลของคุณจะไม่ถูกโหลดเมื่อแสดงหน้าเว็บหรือรูปภาพที่แคชไว้ กวดวิชาที่ดีที่นี่: http://wimleers.com/article/easy-drupal-cdn-integration-for-fun-and-profit

และ ... WebPageTest ทำให้ฉันมีความสุข http://www.webpagetest.org/เปรียบเทียบเวลาโหลดรอบโลกและกับเว็บเบราว์เซอร์ที่แตกต่างกันฟรี ใช้สิ่งนี้เพื่อรับผลลัพธ์ในโลกแห่งความจริงสำหรับการเปลี่ยนแปลงใด ๆ ที่คุณทำ

ปัญหาอาจเกิดขึ้นได้ทุกที่

1. ตรวจสอบให้แน่ใจว่าคุณไม่ได้เปิดโหมดแก้ไขข้อบกพร่องในธีมหรือโมดูลใด ๆ ตัวอย่างเช่นในหลาย ๆ รูปแบบมีตัวเลือกในการสร้างชุดข้อมูลรีจิสตรี
2. หากคุณกำลังทำงานบนโฮสติ้งที่ใช้ร่วมกันเช่น Godaddy ดังนั้น 15 วินาทีสำหรับการร้องขอครั้งแรกถือเป็นเรื่องปกติ
3. แปลงเว็บไซต์หรือหน้าของคุณเพื่อ codebase ใช้โมดูล Drush CTools ส่งออก วิธีนี้จะกำจัดการเรียกฐานข้อมูลใด ๆ และเว็บไซต์ของคุณจะทำงานจาก php
4. หากคุณยังคงได้รับปัญหาใช้การตั้งค่า Devel โดยการเปิดquery logและตัวเลือกที่page timer admin/config/development/develดูว่าหนึ่งในสองนั้นใช้เวลาในการสร้างทั้งหน้ามากขึ้น
5. รีสตาร์ทเซิร์ฟเวอร์ของคุณหากไม่มีอะไรทำงาน
6. กรณีที่แย่ที่สุดติดตั้งXHProfเพื่อดูว่ามีอะไรผิดปกติเกิดขึ้น

ดังนั้นนี่คือวิธีที่ฉันแก้ไขปัญหาสำหรับการติดตั้งของฉัน มันไม่ได้เป็นทางออกที่แท้จริงเพราะฉันไม่สามารถตอกย้ำแหล่งที่มาของปัญหา (ถ้ามี) แต่เป็นการแก้ไขที่ดี

1) CSS รวม (การตั้งค่าแคช) สิ่งนี้ลดเวลาแฝงลงครึ่งหนึ่ง

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

3) ตั้งค่างาน cron ที่เรียกโฮมเพจกับ Lynx ทุก ๆ 30 นาที

ทั้งหมดนี้บนเซิร์ฟเวอร์โฮสต์ที่ใช้ร่วมกัน มันไม่ได้ดีที่สุด แต่ก็ใช้งานได้

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

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

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