ผู้แต่ง: Fenng | คุณสามารถพิมพ์ซ้ำได้ เมื่อพิมพ์ซ้ำ โปรดระบุแหล่งที่มาดั้งเดิมและข้อมูลผู้แต่งของบทความและคำชี้แจงลิขสิทธิ์ในรูปแบบของไฮเปอร์ลิงก์: http://www.dbanotes.net/web/flickr_web_tech .html
Cal Henderson เป็นหนึ่งในผู้พัฒนาเว็บไซต์ Flickr ที่มีชื่อเสียง ในบทความชื่อ Serving JavaScript Fast เขาได้แนะนำเทคนิคในการเพิ่มประสิทธิภาพแอปพลิเคชันไซต์ Flickr ฉันรู้สึกว่าฉันได้รับประโยชน์มากมายจากการอ่านบทความนี้ “เคี้ยวซาลาเปาคนอื่น” สรุปเนื้อหาหลักของบทความ
Flickr เป็นเว็บไซต์ตัวแทนของ Web 2.0 นอกเหนือจากการปรับเนื้อหาให้เหมาะสมซึ่งพบได้ทั่วไปในเว็บไซต์ทั่วไปแล้ว ปัญหาเครือข่ายที่ต้องเผชิญยังต้องจัดการความซับซ้อนของการปรับใช้และการแจกจ่ายอย่างยืดหยุ่นซึ่งเกิดจากการเปลี่ยนแปลงบ่อยครั้งใน JavaScript และ CSS
คำถามแรกที่ต้องเผชิญเมื่อตั้งค่ากลยุทธ์ขนาดไฟล์คือจะรวม JavaScript และ CSS ทั้งหมดไว้ในไฟล์เดียวหรือแยกออกเป็นหลายไฟล์ จากมุมมองของการลดคำขอเครือข่าย ข้อแรกดีกว่าและข้อหลังแย่ลง อย่างไรก็ตาม จากมุมมองแบบคู่ขนาน ทั้ง IE และ Firefox สามารถขอทรัพยากรได้เพียงสองรายการจากโดเมนเดียวในเวลาเดียวกัน โดยค่าเริ่มต้น ซึ่งจะทำให้ผู้ใช้ได้รับประสบการณ์ที่ไม่ดี - ไฟล์ทั้งหมดจะต้องถูกดาวน์โหลด ใช้การประนีประนอม - แบ่ง JavaScript และ CSS ออกเป็นไฟล์ย่อยหลายไฟล์โดยรักษาจำนวนไฟล์ให้เล็กที่สุดเท่าที่จะเป็นไปได้ สิ่งนี้นำมาซึ่งความซับซ้อนในการพัฒนา แต่ประโยชน์ด้านประสิทธิภาพนั้นใหญ่มาก
ปัญหาการเพิ่มประสิทธิภาพการบีบอัด ไม่ต้องสงสัยเลยว่าการบีบอัดเนื้อหาไซต์เป็นวิธีการเพิ่มประสิทธิภาพเว็บที่ใช้กันทั่วไป อย่างไรก็ตามไม่สามารถบรรลุผลตามที่ต้องการได้เสมอไป เหตุผลก็คือโมดูล mod-gzip ไม่เพียงแต่ใช้ทรัพยากร CPU ฝั่งเซิร์ฟเวอร์เท่านั้น แต่ยังใช้ทรัพยากร CPU ฝั่งไคลเอ็นต์ด้วย นอกจากนี้ ไฟล์ชั่วคราวที่สร้างขึ้นหลังจาก mod_gzip บีบอัดไฟล์จะถูกวางไว้บนดิสก์ ซึ่งจะทำให้เกิดปัญหาร้ายแรงด้วย สำหรับดิสก์ IO Flickr ใช้โมดูล mod_deflate ที่รองรับโดย Httpd 2.x และใหม่กว่า การดำเนินการบีบอัดทั้งหมดดำเนินการในหน่วยความจำ mod_deflate ไม่สามารถใช้งานได้ใน Httpd 1.x แต่คุณสามารถปรับปรุงประสิทธิภาพทางอ้อมได้โดยการสร้างดิสก์ RAM
แน่นอนว่า mod_gzip นั้นไม่มีประโยชน์ มันยังคงมีประโยชน์สำหรับไฟล์ที่ถูกบีบอัดล่วงหน้า นอกจากนี้ เมื่อใช้การบีบอัด คุณต้องใส่ใจกับกลยุทธ์นี้ด้วย
การบีบอัดไม่สามารถบรรลุประโยชน์ได้มากนัก)Flickr
บีบอัดเฉพาะ JavaScript และ CSS เวอร์ชันใหม่กว่าสามารถจัดการไฟล์ที่บีบอัดล่วงหน้าได้โดยอัตโนมัติโดยการกำหนดค่าตัวเลือก mod_gzip_update_static
การบีบอัดข้อมูลหลักวิธีหนึ่งคือการบีบอัดเนื้อหา สำหรับ JavaScript คุณสามารถทำได้โดยการลดความคิดเห็น การรวมช่องว่าง การใช้ไวยากรณ์แบบกะทัดรัด และเทคนิคอื่นๆ (สคริปต์ของ Google ทั้งหมดอ่านยากมากและกะทัดรัดมากด้วยแนวคิดที่คล้ายกัน) การประมวลผลในลักษณะนี้ JavaScript อาจมีวงเล็บจำนวนมากที่แยกวิเคราะห์ได้ยาก Flickr ใช้ Dojo Compressor เพื่อสร้างแผนผังการแยกวิเคราะห์ Dojo Compressor มีค่าใช้จ่ายต่ำมากและมีความโปร่งใสสำหรับผู้ใช้ปลายทาง วิธีการประมวลผล JavaScript ได้รับการแนะนำ และการประมวลผล CSS นั้นค่อนข้างง่าย ด้วยการแทนที่นิพจน์ทั่วไปอย่างง่าย (เช่น การแทนที่หลายช่องว่างด้วยอักขระเว้นวรรคหนึ่งตัว) คุณสามารถเริ่มต้นได้ อัตราส่วนกำลังอัดถึง 50%
การเพิ่มประสิทธิภาพของนักพัฒนา Caching Flickr ได้ใช้กลไก Etag และ Last-Modified ที่กำหนดโดยข้อกำหนด HTTP 1.1 อย่างเต็มที่ เพื่อปรับปรุงประสิทธิภาพของ Caching เป็นที่น่าสังเกตว่า Cal ได้แนะนำเคล็ดลับ e-Tag ภายใต้เงื่อนไขการปรับสมดุลโหลด คุณสามารถตั้งค่า Apache ให้รับ E-Tag ผ่านเวลาการปรับไฟล์และขนาดไฟล์ ตามค่าเริ่มต้น Apache รับ e-Tag ผ่านโหนดไฟล์ แน่นอนว่าสิ่งนี้ไม่สมบูรณ์แบบ เพราะมันจะส่งผลต่อ if-modified-since
การใช้งาน mod_rewrite ที่ยืดหยุ่น ว่ากันว่าแอปพลิเคชั่นเว็บไซต์ Flickr ถูกสร้างขึ้นทุกวัน (Daily Build) นี่จะคิดไม่ถึงหากไม่มีกลไกที่ยืดหยุ่น ยิ่งไปกว่านั้น บนไซต์อย่าง Flickr การซิงโครไนซ์การแก้ไขเนื้อหาเป็นเรื่องที่น่าปวดหัว อาวุธของพวกเขาคือการใช้ mod_rewrite อย่างยืดหยุ่น ด้วยการกำหนดค่ากฎการเขียน URL ใหม่ ทำให้ง่ายต่อการสลับไปยังสภาพแวดล้อมที่แตกต่างกัน ฟังดูง่ายมาก แต่จะง่ายแค่ไหนถ้าไม่มีทักษะด้านเทคโนโลยีเว็บบางอย่าง
เราได้เห็น Flickr ที่เหมือนฝันและมีประสิทธิภาพสูงด้วยการประยุกต์ใช้วิธีการหลักเหล่านี้
BTW: เนื่องจาก Flickr ไม่มีเซิร์ฟเวอร์ในประเทศจีน จึงไม่สามารถกล่าวถึงความเร็วในการเข้าถึงสำหรับผู้ใช้แผ่นดินใหญ่ได้ :(
--สิ้นสุด
บทความนี้ [เคล็ดลับการเพิ่มประสิทธิภาพแอปพลิเคชันเว็บสำหรับนักพัฒนา Flickr] มาจาก dbanotes.net