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

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

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

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

• การเพิ่มประสิทธิภาพ Apache;
• การเพิ่มประสิทธิภาพ PHP;
• การติดตั้ง eAccelerator;
• การติดตั้ง Nginx เป็นส่วนหน้า
• ติดตั้ง Memcached;
• การเพิ่มประสิทธิภาพไคลเอ็นต์

การเพิ่มประสิทธิภาพอาปาเช่

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

และควรคำนึงถึงสิ่งนี้เมื่อตั้งค่า นี่คือรายการคำแนะนำที่ควรปฏิบัติตามดีที่สุดเมื่อเตรียมเซิร์ฟเวอร์ HTTP สำหรับการดำเนินการ:

• ฟังก์ชันการทำงานของ Apache ส่วนแบ่งส่วนใหญ่มีอยู่ในโมดูลที่โหลดได้ ซึ่งสามารถเปิดใช้งานหรือปิดใช้งานได้โดยการแก้ไขไฟล์การกำหนดค่า (คำสั่ง LoadModule) แนวทางปฏิบัติที่ดีคือการปิดการใช้งานโมดูลที่ไม่ได้ใช้ทั้งหมดโดยสิ้นเชิง ซึ่งจะปรับปรุงประสิทธิภาพของเซิร์ฟเวอร์และประหยัด RAM
• Apache ประมวลผลคำขอใหม่แต่ละรายการในเธรดของตัวเอง และอนุญาตให้คุณใช้แนวทางที่แตกต่างกันในการดำเนินการนี้ หากคุณสร้าง Apache2 จากแหล่งที่มา คุณอาจสังเกตเห็นว่าในตัวเลือกการสร้างนั้นมีความสามารถในการเลือกสิ่งที่เรียกว่า MPM นี่คือโมดูลการประมวลผลหลายตัวที่ใช้ในการทำเซิร์ฟเวอร์ HTTP แบบขนาน

มีทั้งหมดสามอย่าง:

1. prefork เป็น MPM แบบคลาสสิกที่ใช้โมเดลการประมวลผลหลายตัวที่ใช้ใน Apache 1.3 แต่ละเธรดได้รับการประมวลผลในกระบวนการที่แยกจากกัน ไม่ใช่ตัวเลือกที่มีประสิทธิผลมากที่สุด แต่มีเสถียรภาพมากที่สุด ใช้เป็นค่าเริ่มต้น
2. ผู้ปฏิบัติงานเป็น MPM แบบเธรด เซิร์ฟเวอร์สร้างกระบวนการหลายอย่าง โดยแต่ละกระบวนการมีหลายเธรด หนึ่งคำขอ - หนึ่งเธรด พรีฟอร์คมีประสิทธิภาพมากกว่า แต่มีความเสถียรน้อยกว่า
3. เหตุการณ์ - เหตุการณ์ MPM แทนที่จะเป็นเธรด คำขอจะถูกประมวลผลโดยใช้โมเดลตามเหตุการณ์ที่คล้ายกับที่ใช้ใน nginx MPM ที่มีประสิทธิผลมากที่สุด แต่ก็มีความเสถียรน้อยที่สุด (อยู่ในขั้นทดลองของการพัฒนา)

การกระจายจำนวนมากช่วยให้คุณสามารถติดตั้ง Apache เวอร์ชันต่างๆ ได้ ซึ่งแตกต่างกันใน MPM ที่ใช้ ซึ่งสามารถพบได้ง่ายในพื้นที่เก็บข้อมูลโดยค้นหา "apache2-mpm"

• Apache ช่วยให้คุณควบคุมได้ ปริมาณสูงสุดสร้างเธรดโดยใช้ตัวเลือก MaxClients อย่าตั้งค่าสูงเกินไปมิฉะนั้น ช่วงเวลาหนึ่งเซิร์ฟเวอร์จะทำให้ RAM ทั้งหมดหมด เริ่มการสลับ และไคลเอนต์จำนวนมากจะยังคงไม่ได้รับบริการมากกว่าที่จะเป็นกรณีหากมีการตั้งค่าขีดจำกัดฮาร์ด ค่าที่เหมาะสมที่สุดคือจำนวนหน่วยความจำที่มีให้กับ Apache หารด้วยขนาดสูงสุดของเธรดที่สร้าง (ตรวจสอบโดยใช้ ps หรือด้านบน)
• เช่นเดียวกับเซิร์ฟเวอร์ HTTP อื่นๆ Apache ช่วยให้คุณสามารถควบคุมระยะเวลาของการเชื่อมต่อแบบ Keep-alive ซึ่งใช้ในการส่งคำขอ/ตอบกลับหลายรายการภายในการเชื่อมต่อเดียว Keep-alive ช่วยให้คุณประหยัดทรัพยากรเซิร์ฟเวอร์โดยไม่ต้องบังคับให้สร้างเธรดแยกสำหรับแต่ละรูปภาพ, CSS และองค์ประกอบหน้าอื่นๆ อย่างไรก็ตาม คุณไม่ควรเปิดการเชื่อมต่อดังกล่าวไว้นานเกินไป เนื่องจากการทำเช่นนี้ต้องใช้ทรัพยากรด้วย ค่าที่ดีสำหรับตัวเลือก KeepAliveTimeout คือ 5-10 วินาที และหากส่วนประกอบที่ขึ้นต่อกันทั้งหมดของเพจถูกส่งไปยังไคลเอนต์โดยเซิร์ฟเวอร์ที่แยกจากกัน และเซิร์ฟเวอร์ปัจจุบันใช้สำหรับการให้บริการ HTML/PHP เท่านั้น ก็ไม่จำเป็นต้องรองรับ Keep-alive เลย และควรตั้งค่าตัวเลือก KeepAlive เป็น Off จะดีกว่า
• Apache ไม่ชอบการบีบอัด หากคุณตัดสินใจที่จะเพิ่มความเร็วในการจัดส่งเพจโดยใช้การบีบอัด โปรดจำไว้ว่ามีแนวโน้มที่จะสร้างภาระบนเซิร์ฟเวอร์มากยิ่งขึ้น หากจำเป็นต้องบีบอัดจริงๆ (เช่น สำหรับ พอร์ทัลมือถือซึ่งกระแสหลักของลูกค้าใช้ช่องสัญญาณ GPRS) จากนั้นตั้งค่าอัตราส่วนการบีบอัดให้น้อยที่สุด สิ่งนี้จะทำให้ปริมาณข้อมูลผลลัพธ์เพิ่มขึ้นเล็กน้อยเท่านั้น แต่จะช่วยประหยัดทรัพยากรเซิร์ฟเวอร์ได้อย่างมาก

การเพิ่มประสิทธิภาพ PHP

บ่อยครั้ง โหลดที่หนักที่สุดไม่ได้สร้างโดยเซิร์ฟเวอร์ HTTP เลย แต่โดยล่ามของภาษาการเขียนโปรแกรมที่ใช้ในการสร้างเนื้อหาเว็บไซต์แบบไดนามิก ปัจจุบัน ภาษาที่ได้รับความนิยมมากที่สุดสำหรับการเขียนสคริปต์เว็บฝั่งเซิร์ฟเวอร์คือ PHP ดังนั้นเราจะเน้นที่ภาษานี้ในบทความของเรา เปิดไฟล์ /etc/php5/apache2/php.ini (เส้นทางสำหรับ Ubuntu อาจแตกต่างกันในรุ่นอื่น) และแก้ไขบรรทัดต่อไปนี้:

• memory_limit - ขีดจำกัดของหน่วยความจำที่ใช้เมื่อสร้างเว็บเพจ ก่อนที่จะเปลี่ยนพารามิเตอร์นี้ ขอแนะนำให้ทำการวัดที่เหมาะสมและกำหนดค่าตามผลลัพธ์
• display_errors = Off, error_log = /var/log/php - เปลี่ยนเส้นทางข้อความแสดงข้อผิดพลาดไปยังไฟล์บันทึก เปิดใช้งานตัวเลือกนี้เมื่อสคริปต์ทั้งหมดได้รับการดีบั๊กโดยสมบูรณ์
• upload_max_filesize และ post_max_size - ขนาดสูงสุดของไฟล์ที่อัปโหลดและคำขอ POST ขอย้ำอีกครั้งว่าควรเลือกค่าตามความต้องการของเว็บแอปพลิเคชันของคุณ

ตอนนี้คุณสามารถปิดไฟล์และเรียกใช้ได้ การเพิ่มประสิทธิภาพเชิงลึกโดยใช้ตัวเร่ง PHP

การติดตั้งตัวเร่งความเร็ว

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

แพ็คเกจ eAccelerator ไม่มีให้บริการในคลังเก็บรุ่นยอดนิยม ดังนั้นคุณจะต้องสร้างมันขึ้นมาเอง ขั้นแรก ให้ติดตั้งยูทิลิตี้ที่จำเป็นสำหรับการประกอบ:

$ sudo apt-get ติดตั้ง php5-dev จำเป็นต่อการสร้าง

$ ซีดี /tmp/
$ wget http://bart.eaccelerator.net/source/0.9.6.1/
ตัวเร่งความเร็ว-0.9.6.1.tar.bz2
$tar xvjf ตัวเร่งความเร็ว-0.9.6.1.tar.bz2
$cd ตัวเร่งความเร็ว-0.9.6.1
$phpize
$ ./configure --enable-eaccelerator=shared
$ ทำ
$ sudo ทำการติดตั้ง

สร้างไดเร็กทอรีเพื่อจัดเก็บแคช:

$ sudo mkdir -p /var/cache/eaccelerator
$ sudo chmod 0777 /var/cache/eaccelerator
และสุดท้าย เราเชื่อมต่อ eAccelerator กับ PHP (เพิ่มที่จุดเริ่มต้นของไฟล์):
# vi /etc/php5/apache2/php.ini
- กำลังเชื่อมต่อส่วนขยาย
ส่วนขยาย = "eaccelerator.so"
eaccelerator.enable = "1"
- ขนาดสูงสุด ดิสก์แคช(เมกะไบต์)
eaccelerator.shm_size = "64"
- ไดเร็กทอรีที่เก็บแคช
eaccelerator.cache_dir = "/var/cache/eaccelerator"
- เปิดใช้งานเครื่องมือเพิ่มประสิทธิภาพโค้ด
eaccelerator.optimizer = "1"
- คอมไพล์สคริปต์ที่แก้ไขใหม่
eaccelerator.check_mtime = "1"
- ปิดการใช้งานโหมดการแก้ไขข้อบกพร่อง
eaccelerator.debug = "0"
- แคชไฟล์ทั้งหมด (ตัวกรองว่าง)
eaccelerator.filter = ""
; ไม่จำกัดขนาดแคชในหน่วยความจำ
eaccelerator.shm_max = "0"
- หากไม่มีที่ว่างในแคช ให้ลบอ็อบเจ็กต์ที่เก่ากว่า
1 ชั่วโมง (3600 วินาที)
eaccelerator.shm_ttl = "3600"
eaccelerator.shm_prune_ช่วงเวลา = "0"
- แคชข้อมูลทั้งในหน่วยความจำและบนดิสก์
eaccelerator.shm_only = "0"
- บีบอัดข้อมูลแคชด้วยระดับการบีบอัดสูงสุด
eaccelerator.compress = "1"
eaccelerator.compress_level = "9"

การติดตั้ง nginx

เว็บไซต์ไดนามิกขนาดใหญ่ที่ได้รับความนิยมสามารถสร้างภาระบนเซิร์ฟเวอร์ที่ Apache เริ่มสำลักและถ่มน้ำลาย

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

สิ่งนี้จะช่วยลดภาระบนฮาร์ดแวร์ลงอย่างมาก แต่สร้างปัญหาบางอย่างเมื่อประมวลผลเนื้อหาแบบไดนามิก (ซึ่งเป็นเหตุผลว่าทำไมจึงไม่ใช้เป็นเซิร์ฟเวอร์ HTTP หลัก) โดยปกติแล้ว Nginx จะถูกติดตั้งบนเครื่องเฉพาะที่ต้องเผชิญกับ เครือข่ายภายนอกและทำหน้าที่เป็นจุดตรวจแรกตามเส้นทางคำขอ อย่างไรก็ตาม มีตัวเลือกหนึ่งด้วย ฟิสิคัลเซิร์ฟเวอร์เมื่อ Apache และ Nginx ทำงานบนเครื่องเดียวกัน มาอาศัยอยู่กับมันกันเถอะ เปิดไฟล์ /etc/apache2/ports.conf และเปลี่ยนสองตัวเลือก:

ชื่อ VirtualHost *:81
ฟัง 81
ถัดไปติดตั้ง Nginx:
$ sudo apt-get ติดตั้ง nginx
เปิดไฟล์การกำหนดค่าและเขียนสิ่งต่อไปนี้ลงไป:
# vi /etc/nginx/nginx.conf
# ผู้ใช้ Nginx
ผู้ใช้ www-data;
# กำหนดจำนวนกระบวนการ Nginx ให้เท่ากับจำนวน
แกนประมวลผล
ผู้ปฏิบัติงาน_กระบวนการ 1;
error_log /var/log/nginx/error.log;
pid /var/run/nginx.pid;
เหตุการณ์ (
ผู้ปฏิบัติงาน_การเชื่อมต่อ 1,024;
}
http(
# การตั้งค่ามาตรฐาน
รวม /etc/nginx/mime.types;
แอปพลิเคชัน default_type / octet-stream;
server_names_hash_bucket_size 64;
access_log /var/log/nginx/access.log;
ส่งไฟล์บน;
#tcp_nopush บน;
#keepalive_หมดเวลา 0;
Keepalive_หมดเวลา 65;
tcp_nodelay บน;
# เปิดใช้งานการบีบอัด
เปิด gzip;
gzip_proxyed ใด ๆ ;
gzip_min_length 1100;
gzip_http_version 1.0;
gzip_buffers 4 8k;
gzip_comp_level 9;
ข้อความ gzip_types/ข้อความธรรมดา/แอปพลิเคชัน CSS/
ข้อความ x-javascript/แอปพลิเคชัน xml/xml
แอปพลิเคชัน/xml+ข้อความ rss/จาวาสคริปต์;
รวม /etc/nginx/conf.d/*.conf;
รวม /etc/nginx/sites-enabled/*;
}

มาสร้างการกำหนดค่าโฮสต์ของเรา:

# vi /etc/nginx/sites-enabled/host.com
เซิร์ฟเวอร์ (
ฟัง 80;
เซิร์ฟเวอร์_ชื่อโฮสต์.com;
access_log /var/log/nginx.access_log;
# Nginx จัดทำสถิติทั้งหมดอย่างอิสระ
ตำแหน่ง ~* \.(jpg|jpeg|gif|png|css|js|zip|
tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|tar|wav|bm
p|rtf|swf|ico|flv|txt|xml|docx|xlsx)$ (
รูต /var/www/host.com/;
ดัชนีindex.htmlindex.php;
access_log ปิด;
หมดอายุ 30d;
}
# การเข้าถึงไฟล์เช่น .htaccess ถูกปฏิเสธ
ตำแหน่ง ~ /\.ht (
ปฏิเสธทั้งหมด
}
# คำขอทั้งหมดสำหรับเนื้อหาอื่น ๆ ทั้งหมดจะถูกส่งไปยัง Apache
ที่ตั้ง/(
พร็อกซี_พาส http://127.0.0.1:81/;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-ส่งต่อ-สำหรับ $remote_
เพิ่ม;
proxy_set_header โฮสต์ $ โฮสต์;
พร็อกซี_เชื่อมต่อ_หมดเวลา 60;
proxy_send_timeout 90;
พร็อกซี_read_หมดเวลา 90;
ปิด proxy_redirect;
proxy_set_header การเชื่อมต่อปิด;
proxy_pass_header ประเภทเนื้อหา;
proxy_pass_header การจัดการเนื้อหา;
proxy_pass_header ความยาวเนื้อหา;
}
}

เพียงรีสตาร์ท Apache และ Nginx:

$ sudo service apache2 รีสตาร์ท
$ sudo service nginx รีสตาร์ท

กำลังติดตั้ง memcached

Memcached คือระบบแคชข้อมูลในหน่วยความจำที่สามารถใช้สำหรับการจัดเก็บแบบกระจายและเร่งการเข้าถึงข้อมูลทุกประเภท
นี่เป็นหนึ่งในโซลูชันที่ได้รับความนิยมมากที่สุดในด้านการเพิ่มประสิทธิภาพเว็บไซต์โดยรวมสำหรับการโหลดสูง ซึ่งไม่จำเป็นต้องกำหนดค่าหรือการเรียนรู้ API อย่างกว้างขวาง โดยปกติแล้ว memcached จะถูกใช้งานโดยสองฝ่าย กล่าวคือ ฝ่ายหนึ่งใส่ข้อมูลลงในแคช และอีกฝ่ายดึงข้อมูลออกมา ในสภาพแวดล้อมของเว็บ บทบาทของฝ่ายแรกมักจะเล่นโดยสคริปต์ PHP ขนาดเล็กที่เขียนข้อมูลสำคัญ (ในแง่ของความเร็วในการอัพโหลด) ไปยัง memcached ในขณะที่ฝ่ายที่สองมักจะเป็นเซิร์ฟเวอร์ส่วนหน้าแบบน้ำหนักเบา (โดยปกติคือ nginx) ที่ใช้ โมดูลพิเศษสำหรับการอ่านและส่งคืนข้อมูลจาก memcached Memcached มักใช้เพื่อแคชทั้งหน้าของเว็บไซต์ ซึ่งจะช่วยเพิ่มความเร็วในการเข้าถึงหน้าเหล่านี้ได้หลายระดับ ในกรณีที่ง่ายที่สุด การกำหนดค่านี้จะมีลักษณะดังนี้:

1. ติดตั้ง memcached:

$ sudo apt-get ติดตั้ง memcached

2. ข้อมูลต่อไปนี้ถูกเพิ่มไปยังส่วนเซิร์ฟเวอร์ของไฟล์การกำหนดค่า nginx:

# vi /etc/nginx/nginx.conf
ที่ตั้ง/(
# ตั้งค่าคีย์ memcached ให้เท่ากับคีย์ที่ร้องขอ
ยูอาร์ไอ
ตั้งค่า $memcached_key $uri;
# ที่อยู่และพอร์ตของ memcached daemon
memcached_pass 127.0.0.1:11211;
# ชื่อเริ่มต้น
default_type ข้อความ/html;
# หากไม่พบข้อมูลในแคช เราจะขอข้อมูลจากแบ็กเอนด์
error_page 404 = /สำรอง;
}
ตำแหน่ง /ทางเลือก (
แบ็กเอนด์ proxy_pass;
}

3. สำหรับ PHP มีการติดตั้งส่วนขยาย memcache (ไคลเอนต์สำหรับ memcached):

$ sudo pecl ติดตั้ง memcache

4. รหัสต่อไปนี้ถูกฝังอยู่ในหน้า:

$ vi smaple.php
# ละเว้นการเริ่มต้น Memcached
ob_start();
$html = ob_get_clean();
$memcache->set($_SERVER["REQUEST_URI"], $html);
เสียงสะท้อน $html;

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

# vi /var/www/index.php

นี่คือหน้าเดียวกันทุกประการ รหัสการตรวจสอบสิทธิ์จะอยู่ในไฟล์ auth.php และส่วนที่เหลือของหน้าจะอยู่ใน body.php สิ่งที่บิดเบี้ยวคือคุณวางโค้ดแคชที่ให้ไว้ข้างต้นในขั้นตอนที่สี่เฉพาะในส่วนที่สองของไฟล์เหล่านี้ จึงเกิดภาพดังต่อไปนี้

1. มีคนมาที่ไซต์เป็นครั้งแรก หน้าหลักของเว็บไซต์ถูกร้องขอไปยัง nginx
2. เซิร์ฟเวอร์ nginx ร้องขอไฟล์ index.php จากแบ็กเอนด์ (Apache) พบคำสั่ง SSI ภายในไฟล์ และสร้างคำขอเพิ่มเติม *2* ไปยังแบ็กเอนด์ (auth.php และ body.php)
3. เมื่อได้รับคำขอ Apache จะเปิดตัวล่าม PHP เพื่อประมวลผลไฟล์ที่ร้องขอ ส่งผลให้เกิดเนื้อหา (เหนือสิ่งอื่นใด) ไฟล์หนัก body.php จบลงในแคช memcached
4. การตอบกลับจะถูกส่งกลับโดย nginx ซึ่งรวมไฟล์ต่างๆ ไว้ในดัชนีเดียว php และมอบให้กับลูกค้า
5. หลังจากนั้นผู้เข้าร่วมที่ลงทะเบียนมาที่ไซต์คำขอ index.php เกิดขึ้นจากส่วนหลัง (แม้ว่าส่วนใหญ่จะถูกนำมาจากแคชของ nginx เอง) อย่างไรก็ตามมีเพียงการตรวจสอบสิทธิ์ที่ง่ายและสะดวกเท่านั้น คำขอ php จะไปที่ Apache ในขณะที่ body.php จะถูกนำมาจากแคช memcached

ดำเนินไปโดยไม่ได้บอกว่าต้องเปิดใช้งาน SSI ในไฟล์กำหนดค่า nginx โดยใช้ตัวเลือก “ssi on” ที่อยู่ในส่วน “location /” เป็นที่น่าสังเกตว่าบล็อก auth.php ยังสามารถแคชได้ แต่ในการทำเช่นนี้คุณจะต้องกำหนดตัวระบุให้กับผู้ใช้ที่ลงทะเบียนทั้งหมด บันทึกลงในคุกกี้ และใช้เพื่อสร้างคีย์ memcached ที่ไม่ซ้ำใคร

การเพิ่มประสิทธิภาพไคลเอ็นต์

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

1. ใช้ gzip หรือ deflate เพื่อบีบอัดหน้าและข้อมูล ในการดำเนินการนี้ คุณสามารถใช้โมดูลเซิร์ฟเวอร์ HTTP: ngx_http_gzip_module สำหรับ nginx, mod_compress สำหรับ lighttpd และ mod_deflate สำหรับ Apache
2. ใช้แพ็คเกอร์เพื่อการปรับให้เหมาะสมและการลบออก ขยะส่วนเกินจาก HTML และ JavaScript (โดยปกติจะลบความคิดเห็นและการเว้นวรรคทั้งหมด เปลี่ยนชื่อด้วยคำที่สั้นกว่า ฯลฯ เช่น web-optimizator, code.google.com/p/web-optimizator)
3. ใส่โค้ด CSS และ JavaScript ลงในไฟล์แยกกัน จากนั้นเบราว์เซอร์สามารถแคชและนำไปใช้กับหน้าอื่น ๆ ได้ (สามารถวางไว้บนเซิร์ฟเวอร์แยกต่างหากเพื่อให้โหลดพร้อมกันได้)
4. เพื่อให้เบราว์เซอร์โหลดหน้าเว็บได้ราบรื่นและถูกต้องยิ่งขึ้น กำลังโหลด CSSที่จุดเริ่มต้นของหน้าและ JavaScript ที่ส่วนท้าย
5. อย่าลืมติดตั้ง ส่วนหัวหมดอายุและการควบคุมแคชเพื่อให้เบราว์เซอร์สามารถแคช CSS และ JavaScript ได้
6. อย่าใช้ JPG และ PNG เมื่อคุณสามารถใช้ GIF ได้ (เช่น สำหรับไอคอนขนาดเล็ก)

การปรับสมดุล

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

เมคแคช

ถ้ามีเพียงพอ ปริมาณมากหน่วยความจำ แนวทางปฏิบัติที่ดีคือการรัน memcached daemon ด้วยแฟล็ก '-L' ด้วยเหตุนี้ daemon จะเตรียมหน่วยความจำทั้งหมดที่จัดสรรไว้เพื่อใช้ล่วงหน้า วิธีนี้จะปรับปรุงประสิทธิภาพโดยรวมของ memcached เล็กน้อย โดยไม่จำเป็นต้องจัดสรรหน่วยความจำอย่างต่อเนื่องขณะทำงาน

วิธีเพิ่มประสิทธิภาพเซิร์ฟเวอร์บน CentOS OS ส่วนที่ 3: การเพิ่มประสิทธิภาพการตั้งค่าเว็บเซิร์ฟเวอร์อย่างรวดเร็ว

ในบทความนี้ เราจะบอกวิธีเพิ่มประสิทธิภาพเซิร์ฟเวอร์ (เฉพาะหรือเสมือน) โดยใช้ CentOS OS เป็นตัวอย่าง โดยการปรับการตั้งค่าเว็บเซิร์ฟเวอร์ Nginx และ Apache (httpd) ให้เหมาะสมอย่างรวดเร็ว

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

เป็นการดีที่สุดที่จะทำงานกับเซิร์ฟเวอร์ผ่าน SSH แต่ถ้าคุณมีปัญหาในการทำงานกับ SSH คุณสามารถเปิดไฟล์ผ่านตัวจัดการไฟล์ของแผงควบคุมได้ (คำแนะนำในการทำงานกับ SSH ในส่วนแรกของบทความนี้)

การเพิ่มประสิทธิภาพการตั้งค่าเว็บเซิร์ฟเวอร์ Apache (httpd)

ไฟล์การกำหนดค่าเว็บเซิร์ฟเวอร์ Apache อยู่ในเส้นทางต่อไปนี้:

/etc/httpd/conf/httpd.conf

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

เริ่มเซิร์ฟเวอร์ 5
เซิร์ฟเวอร์ขั้นต่ำ 5
MaxSpareServers20
แม็กซ์ไคลเอนท์ 256
MaxRequestsPerChild 0

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

จากนั้น นับ 2/3 ของจำนวน RAM ทั้งหมดบนเซิร์ฟเวอร์ของคุณ และหารด้วยจำนวนหน่วยความจำที่ใช้โดยกระบวนการของเว็บเซิร์ฟเวอร์หนึ่งกระบวนการ หมายเลขผลลัพธ์จะเป็นค่าที่เหมาะสมที่สุดของ MaxClients

ตัวอย่างเช่น เรามีเซิร์ฟเวอร์ที่มี RAM ขนาด 8 GB 2\3 จาก 8 จะเป็น 5.3 GB โดยทั่วไปกระบวนการเว็บเซิร์ฟเวอร์หนึ่งรายการจะใช้หน่วยความจำประมาณ 40 MB เราคำนวณ 5300MB \ 40MB เราได้ 132 ปัดเศษลงดีกว่า เราทิ้งค่าไว้ 130 ดังนั้นบล็อกไฟล์การกำหนดค่าควรมีลักษณะดังนี้:

เริ่มเซิร์ฟเวอร์ 5
เซิร์ฟเวอร์ขั้นต่ำ 5
MaxSpareServers20
ลูกค้าสูงสุด 130
MaxRequestsPerChild 0

เปิดใช้งาน KeepAlive ด้วย โดยทำสิ่งนี้ ค้นหาบรรทัดในไฟล์กำหนดค่า:

ให้มีชีวิตอยู่ปิด

เปลี่ยนปิดเป็นเปิด:

ให้มีชีวิตอยู่ต่อไป

หลังจากทำการเปลี่ยนแปลง ให้รีสตาร์ทเว็บเซิร์ฟเวอร์ด้วยคำสั่ง:

/etc/init.d/httpd รีสตาร์ท

บริการ httpd รีสตาร์ท

การเพิ่มประสิทธิภาพการตั้งค่าเว็บเซิร์ฟเวอร์ Nginx

ไฟล์การกำหนดค่าเว็บเซิร์ฟเวอร์ Nginx อยู่ในเส้นทางต่อไปนี้:

/etc/nginx/nginx.conf

ในนั้นคุณต้องกำหนดค่าจำนวนกระบวนการ Nginx โดยทั่วไป การตั้งค่านี้ขึ้นอยู่กับจำนวนแกนประมวลผลที่พร้อมใช้งานสำหรับเซิร์ฟเวอร์ของคุณ คำสั่ง worker_processes มีหน้าที่รับผิดชอบในเรื่องนี้ ในไฟล์การกำหนดค่าจะมีลักษณะดังนี้:

ผู้ใช้อาปาเช่;

pid /var/run/nginx.pid;
ผู้ปฏิบัติงาน_กระบวนการ 4;

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

ผู้ปฏิบัติงาน_rlimit_nofile 65536;
เหตุการณ์ (
ใช้อีพอล;
ผู้ปฏิบัติงาน_การเชื่อมต่อ 65536;
}

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

ด้วยเหตุนี้ จุดเริ่มต้นของไฟล์ conf จึงควรมีลักษณะดังนี้:

ผู้ใช้อาปาเช่;
error_log /var/log/nginx/error.log เตือน;
pid /var/run/nginx.pid;
ผู้ปฏิบัติงาน_กระบวนการ 4;
ผู้ปฏิบัติงาน_rlimit_nofile 80000;
เหตุการณ์ (
ใช้อีพอล;
ผู้ปฏิบัติงาน_การเชื่อมต่อ 65536;
}
http(

แอปพลิเคชัน default_type / octet-stream;
log_format หลัก "$remote_addr - $remote_user [$time_local] "$request" "
"$สถานะ $body_bytes_sent "$http_referer" "
""$http_user_agent" "$http_x_forwarded_for"";
access_log /var/log/nginx/access.log หลัก;

ปิดการเข้าถึง_ล็อก;

(คุณสามารถดูโหลดดิสก์ได้โดยใช้ยูทิลิตี้ด้านบน)

คุณยังสามารถเปิดใช้งานการบีบอัด Gzip ใน Nginx ได้ สิ่งนี้จะทำให้เว็บไซต์ของคุณโหลดเร็วขึ้นและยังมีประโยชน์อีกด้วย การส่งเสริม SEOอย่างไรก็ตาม เราขอแนะนำให้ตรวจสอบความเร็วในการดาวน์โหลดหลังจากเปิดใช้งาน Gzip เนื่องจาก บนไซต์ที่มีคำขอจำนวนมาก สิ่งนี้อาจส่งผลเสีย ถึง เปิดใช้งานการบีบอัด Gzip ใน Nginxคุณต้องเพิ่มลงในส่วน http (รหัสนี้:

เปิด Gzip;
gzip_comp_level 5;
gzip_min_length 10240;


gzip_disable "msie6";

เพิ่มโค้ดนี้ในบรรทัดถัดไปหลังจาก http ( เพื่อให้มีลักษณะดังนี้:

ใช้อีโพล;
ผู้ปฏิบัติงาน_การเชื่อมต่อ 65536;
}
http(
เปิด gzip;
gzip_comp_level 5;
gzip_min_length 10240;
gzip_proxied หมดอายุไม่มีแคชไม่มีการตรวจสอบสิทธิ์ส่วนตัวไม่มีการจัดเก็บ;
ข้อความ gzip_types / ข้อความธรรมดา / แอปพลิเคชัน css / แอปพลิเคชัน json / ข้อความ x-javascript / แอปพลิเคชัน xml / แอปพลิเคชัน xml / xml + ข้อความ rss / แอปพลิเคชัน javascript / javascript;
gzip_disable "msie6";
รวม /etc/nginx/mime.types;
แอปพลิเคชัน default_type / octet-stream;

หากมีการตั้งค่า Gzip ในโค้ดด้านล่าง ให้ลบออก

หลังจากตั้งค่าเสร็จแล้วให้รีสตาร์ท Nginx ด้วยคำสั่ง:

/etc/init.d/nginx รีสตาร์ท

บริการ nginx รีสตาร์ท

คุณสามารถค้นหาเอกสารก่อนหน้านี้เกี่ยวกับการเพิ่มประสิทธิภาพการตั้งค่าเซิร์ฟเวอร์ได้โดยใช้ลิงก์ต่อไปนี้:

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

อะไรที่ทำให้ Apache ช้าลง และวิธีใช้ PHP ให้เกิดประโยชน์สูงสุด

ซีรี่ส์เนื้อหา:

Linux, Apache, MySQL และ PHP (หรือ Perl) เป็นพื้นฐานสำหรับสถาปัตยกรรม LAMP สำหรับเว็บแอปพลิเคชัน แพ็คเกจมากมายด้วย โอเพ่นซอร์สซึ่งขึ้นอยู่กับส่วนประกอบของ LAMP พร้อมที่จะแก้ไขปัญหาต่างๆ มากมาย เมื่อโหลดแอปพลิเคชันเพิ่มขึ้น ปัญหาคอขวดของโครงสร้างพื้นฐานหลักจะเด่นชัดมากขึ้น ส่งผลให้เวลาตอบสนองต่อคำขอของผู้ใช้ช้าลง โดยจะแสดงวิธีการตั้งค่าระบบ Linux และครอบคลุมพื้นฐานของ LAMP และการวัดประสิทธิภาพ บทความนี้เน้นที่ส่วนประกอบของเว็บเซิร์ฟเวอร์ ทั้ง Apache และ PHP

การตั้งค่าอาปาเช่

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

การกำหนดค่าโมดูลมัลติโปรเซสเซอร์

แอปพลิเคชัน Apache เป็นแบบโมดูลาร์ในแง่ที่ว่าคุณสามารถเพิ่มและลบองค์ประกอบต่างๆ ได้อย่างง่ายดาย ฟังก์ชันการทำงานแบบโมดูลาร์นี้ใน Apache core -- การจัดการ การเชื่อมต่อเครือข่ายและการส่งคำขอ - จัดเตรียมโมดูลการประมวลผลหลายตัว (โมดูลการประมวลผลหลายตัว, MPM) โมดูลช่วยให้คุณสามารถใช้เธรดหรือแม้แต่ย้าย Apache ไปยังระบบปฏิบัติการอื่นได้

สามารถใช้งานโมดูลมัลติโปรเซสเซอร์ได้ครั้งละหนึ่งโมดูลเท่านั้น และจะต้องคอมไพล์แบบคงที่โดยใช้ --with-mpm= (ผู้ปฏิบัติงาน|prefork|เหตุการณ์) .

เรียกว่าหนึ่งกระบวนการต่อแบบจำลองคำขอแบบดั้งเดิม เตรียมส้อม- รุ่นใหม่ที่ใช้เธรดเรียกว่า คนงานใช้หลายกระบวนการ โดยแต่ละกระบวนการมีหลายเธรด เพื่อให้ได้ข้อมูลเพิ่มเติม ประสิทธิภาพสูงด้วยต้นทุนค่าโสหุ้ยที่ต่ำกว่า ในที่สุด, เหตุการณ์-- โมดูลทดลองที่ประกอบด้วย กลุ่มพิเศษ thread" สำหรับงานที่แตกต่างกัน หากต้องการทราบว่าคุณกำลังใช้โมดูลมัลติโปรเซสเซอร์ตัวใดอยู่ ให้รัน httpd -l

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

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

รายการ 1. การกำหนดค่าโมดูลมัลติโปรเซสเซอร์พรีฟอร์ก

StartServers 50 MinSpareServers 15 MaxSpareServers 30 MaxClients 225 MaxRequestsPerChild 4000

ในโมดูลพรีฟอร์ค กระบวนการใหม่สร้างขึ้นโดยใช้คำขอ กระบวนการสแตนด์บายไม่ได้ใช้งานเพื่อสื่อสารกับคำขอที่เข้ามา ซึ่งช่วยลดเวลารอการเริ่มต้น การกำหนดค่าก่อนหน้านี้เริ่มกระบวนการ 50 กระบวนการทันทีที่เว็บเซิร์ฟเวอร์เริ่มทำงาน และพยายามให้ 10 ถึง 20 กระบวนการไม่ได้ใช้งาน เซิร์ฟเวอร์ที่ทำงานอยู่- ขีดจำกัดของกระบวนการฮาร์ดถูกกำหนดโดยใช้ MaxClients แม้ว่ากระบวนการจะสามารถสื่อสารกับคำขอตามลำดับได้จำนวนมาก แต่ Apache จะฆ่ากระบวนการหลังจากการเชื่อมต่อ 4,000 ครั้ง ซึ่งช่วยลดความเสี่ยงที่หน่วยความจำจะรั่วไหล

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

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

หาก MaxClients สูงเกินไป ลูกค้าทั้งหมดจะไม่ได้รับเพียงพอ ระดับสูงบริการเนื่องจากเว็บเซิร์ฟเวอร์พยายามฆ่ากระบวนการหนึ่งเพื่อให้กระบวนการอื่นทำงาน การตั้งค่าต่ำเกินไปอาจส่งผลให้คุณถูกปฏิเสธการให้บริการอย่างไม่มีเหตุผล การตรวจสอบจำนวนกระบวนการที่ทำงานในช่วงเวลาที่มีการโหลดเพิ่มขึ้น และการวิเคราะห์จำนวนหน่วยความจำที่ใช้โดยกระบวนการ Apache ทั้งหมด จะทำให้คุณมีความคิดที่ดีเกี่ยวกับการตั้งค่านี้ หากคุณตั้งค่า MaxClients สูงกว่า 256 คุณต้องตั้งค่า ServerLimit ให้เป็นค่าเดียวกัน โปรดอ่านเอกสารประกอบสำหรับโมดูลมัลติโปรเซสเซอร์ของคุณอย่างละเอียดเพื่อดูคำเตือนที่เกี่ยวข้อง

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

การใช้ตัวเลือกและการแทนที่อย่างมีประสิทธิภาพ

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

การกำหนดค่าเหล่านี้อยู่ในรูปแบบของคอนเทนเนอร์ใน httpd.conf เช่น ระบุว่าการกำหนดค่าอ้างอิงถึงตำแหน่งของดิสก์หรือ ตั้งค่าการอ้างอิงไปยังเส้นทางที่ระบุใน URL รายการที่ 2 แสดงคอนเทนเนอร์ Directory ที่ใช้งานจริง

รายการ 2. คอนเทนเนอร์ไดเร็กทอรีที่ใช้กับไดเร็กทอรีราก

AllowOverride ไม่มีตัวเลือก FollowSymLinks

ในรายการ 2 การกำหนดค่าที่จำกัดเฉพาะแท็กไดเรกทอรีและ /ไดเรกทอรีจะมีผลกับไดเรกทอรีที่กำหนดและเนื้อหาในไดเรกทอรีนั้น ซึ่งในกรณีนี้คือไดเรกทอรีราก ในที่นี้ แท็ก AllowOverride ระบุว่าผู้ใช้ไม่ได้รับอนุญาตให้แทนที่ตัวเลือกใดๆ (เพิ่มเติมในภายหลัง) ตัวเลือก FollowSymLinks ถูกเปิดใช้งาน ซึ่งช่วยให้ Apache สามารถดูลิงก์สัญลักษณ์ที่ผ่านมาเพื่อให้บริการตามคำขอ แม้ว่าไฟล์จะไม่ได้อยู่ในไดเร็กทอรีที่มีไฟล์เว็บก็ตาม ซึ่งหมายความว่าหากไฟล์ในไดเร็กทอรีเว็บของคุณเป็นลิงก์สัญลักษณ์ไปยัง /etc/passwd เว็บเซิร์ฟเวอร์จะให้บริการไฟล์ได้สำเร็จหากมีคำขอเข้ามา การใช้ -FollowSymLinks จะปิดใช้งานคุณลักษณะนี้ และคำขอเดียวกันจะทำให้เกิดข้อผิดพลาดในการส่งคืนไปยังไคลเอ็นต์

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

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

รายการ 3. ข้อจำกัดของ FollowSymLinks สำหรับไดเร็กทอรีผู้ใช้

ตัวเลือก FollowSymLinks ตัวเลือก -FollowSymLinks

ในรายการ 3 ไดเร็กทอรี public_html ใดๆ ในโฮมไดเร็กทอรีของผู้ใช้จะปิดใช้งานตัวเลือก FollowSymLinks สำหรับไดเร็กทอรีนั้นและไดเร็กทอรีย่อยทั้งหมด

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

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

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

รายการ 4. การย้ายการกำหนดค่า .htaccess ไปที่ httpd.conf

AuthUserFile /home/user/.htpasswd AuthName "โครงการลับ Uber" AuthType พื้นฐาน ต้องมีผู้ใช้ที่ถูกต้อง

หากวางการกำหนดค่าไว้ใน httpd.conf และ AllowOverrides ถูกปิดใช้งาน การใช้งานดิสก์อาจลดลง ไดเร็กทอรีโปรเจ็กต์ของผู้ใช้อาจไม่ดึงดูดการเข้าชมมากนัก แต่ให้พิจารณาถึงประสิทธิภาพของวิธีการนี้สำหรับไซต์ที่ใช้งานหนัก

บางครั้งก็เป็นไปไม่ได้ที่จะกำจัดการใช้ไฟล์ .htaccess ตัวอย่างเช่น ในรายการ 5 ซึ่งการเลือกถูกจำกัดไว้ที่ส่วนเฉพาะของระบบไฟล์ ความสามารถในการเลิกทำก็อาจถูกจำกัดเช่นกัน

รายการ 5. การจำกัดการตรวจสอบ .htaccess

AllowOverrides ไม่มี AllowOverrides AuthConfig

หลังจากที่คุณทำตามขั้นตอนในรายการที่ 5 เสร็จแล้ว Apache ยังคงค้นหาไฟล์ .htaccess ในไดเร็กทอรีหลัก แต่หยุดค้นหาในไดเร็กทอรี public_html เนื่องจากส่วนที่เหลือของระบบไฟล์ไม่สามารถทำงานได้อีกต่อไป ตัวอย่างเช่น หากไฟล์ /home/user/public_html/project/notes.html ถูกร้องขอ ไฟล์นั้นจะถูกแสดงผลสำเร็จก็ต่อเมื่อพบ public_html และไดเร็กทอรีโปรเจ็กต์เท่านั้น

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

การเชื่อมต่อแบบถาวร

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

Apache ช่วยให้คุณสามารถกำหนดวิธีการเรียกการเชื่อมต่อแบบถาวร ของฝาก- KeepAlive 5 ที่ระดับ httpd.conf ทั่วโลกทำให้เซิร์ฟเวอร์สามารถประมวลผลคำขอการเชื่อมต่อ 5 รายการก่อนที่การเชื่อมต่อจะถูกยกเลิกโดยการบังคับ การตั้งค่าตัวเลขนี้เป็น 0 จะปิดใช้งานการเชื่อมต่อแบบถาวร KeepAliveTimeout ในระดับโลกเช่นกัน จะกำหนดระยะเวลาที่ Apache จะรอคำขออื่นก่อนที่จะปิดเซสชัน

การจัดการการเชื่อมต่อแบบถาวรไม่ใช่การกำหนดค่าขนาดเดียวที่เหมาะกับทุกคน เว็บไซต์บางแห่งทำงานได้ดีขึ้นหากปิดใช้งาน Keepalive (KeepAlive 0) และในบางกรณีการเปิดใช้งานจะมีประโยชน์อย่างมาก ทางออกเดียวคือลองทั้งสองตัวเลือกแล้วค้นหาด้วยตัวเอง อย่างไรก็ตาม ก็สมเหตุสมผลที่จะใช้การหมดเวลาต่ำ เช่น 2 วินาที โดยใช้ KeepAliveTimeout 2 หากคุณเปิดใช้งาน Keepalives สิ่งนี้จะช่วยให้มั่นใจได้ว่าลูกค้าที่ต้องการส่งคำขออีกครั้งจะมีเวลาเพียงพอ และพนักงานจะไม่ถูกปล่อยให้อยู่เฉยๆ ในขณะที่รอคำขออื่นที่อาจไม่มีวันมาถึง

การบีบอัด

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

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

การตั้งค่า PHP

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

การแคช Opcode

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

การติดตั้ง eAccelerator ต้องใช้ไลบรารีบนคอมพิวเตอร์ การพัฒนา PHP- เนื่องจากลีนุกซ์รุ่นต่างๆ วางไฟล์ไว้ในตำแหน่งที่ต่างกัน โปรดรับคำแนะนำในการติดตั้งโดยตรงจากเว็บไซต์ eAccelerator (ดูลิงก์ในหัวข้อ) อาจเป็นไปได้ว่าการแจกจ่ายของคุณได้รวมแพ็คเกจแคช opcode ไว้แล้ว และคุณควรติดตั้งแพ็คเกจที่เหมาะสม

ไม่ว่าคุณจะติดตั้ง eAccelerator บนระบบของคุณอย่างไร ก็มีตัวเลือกการกำหนดค่ามากมาย ไฟล์การกำหนดค่าโดยปกติจะเป็น /etc/php.d/eaccelerator.ini eaccelerator.shm_size กำหนดขนาดของแคชหน่วยความจำแบบแบ่งใช้ที่จัดเก็บสคริปต์ที่คอมไพล์แล้ว ค่านี้วัดเป็นเมกะไบต์ การกำหนดขนาดที่เหมาะสมขึ้นอยู่กับการใช้งาน eAccelerator จัดเตรียมสคริปต์เพื่อแสดงสถานะแคช ซึ่งรวมถึงการใช้หน่วยความจำ 64 เมกะไบต์เป็นจุดเริ่มต้นที่ดี (eaccelerator.shm_size="64") คุณยังสามารถปรับขนาดสูงสุดสำหรับหน่วยความจำที่ใช้ร่วมกันได้ หากค่าที่คุณเลือกไม่ได้รับการยอมรับ เพิ่ม kernel.shmmax=67108864 ไปที่ /etc/sysctl.conf และรัน sysctl -p เพื่อให้การตั้งค่ามีผล ค่า kernel.shmmax มีหน่วยวัดเป็นไบต์

หากเกินจำนวนหน่วยความจำที่ใช้ร่วมกันที่จัดสรรไว้ eAccelerator จะต้องลบสคริปต์เก่าออกจากหน่วยความจำ สิ่งนี้ถูกปิดใช้งานตามค่าเริ่มต้น eaccelerator.shm_ttl = "60" ระบุว่าเมื่อ eAccelerator หมดหน่วยความจำที่ใช้ร่วมกัน สคริปต์ใดๆ ที่ไม่ได้เข้าถึงภายใน 60 วินาทีควรถูกลบ

อีกทางเลือกหนึ่งของ eAccelerator ยอดนิยมคือ Alternative PHP Cache (APC) ผู้สร้าง Zend ยังมีแคช opcode เชิงพาณิชย์ที่มีเครื่องมือเพิ่มประสิทธิภาพเพื่อปรับปรุงประสิทธิภาพให้ดียิ่งขึ้น

php.ini

คุณกำหนดค่า PHP ใน php.ini สี่ พารามิเตอร์ที่สำคัญการตั้งค่าจะกำหนดจำนวนทรัพยากรระบบที่ PHP สามารถใช้ได้ ดังแสดงในตารางที่ 1

ตารางที่ 1. การตั้งค่า php.ini ที่เกี่ยวข้องกับทรัพยากร

ขนาดของค่าเหล่านี้โดยทั่วไปจะขึ้นอยู่กับการใช้งาน หากคุณยอมรับจากผู้ใช้ ไฟล์ขนาดใหญ่, max_input_time สามารถเพิ่มได้ใน php.ini หรือโดยการแทนที่ในโค้ด เช่นเดียวกันสำหรับโปรแกรมที่ใช้งาน จำนวนมาก CPU หรือหน่วยความจำอาจต้องใช้ค่าที่สูงกว่า เป้าหมายคือการลดผลกระทบของโปรแกรมที่ใช้พลังงานสูง ดังนั้นจึงไม่แนะนำให้ปิดการใช้งานการตั้งค่าเหล่านี้ทั่วโลก หมายเหตุอีกประการหนึ่งเกี่ยวกับ max_execution_time: หมายถึงเวลา CPU ที่ใช้ในกระบวนการ ไม่ใช่เวลาที่แน่นอน ดังนั้น โปรแกรมที่ทำ I/O จำนวนมากและการคำนวณเพียงเล็กน้อยอาจทำงานได้นานกว่า max_execution_time มาก max_input_time ยังสามารถมากกว่า max_execution_time ได้

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

บทสรุป

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

บทความถัดไปและเป็นบทความสุดท้ายของชุดนี้จะกล่าวถึงการตั้งค่าฐานข้อมูล ข้อมูลมายเอสคิวแอล- อย่าสูญเสียจิตวิญญาณของคุณ!

|

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

คู่มือนี้จะช่วยคุณปรับปรุงประสิทธิภาพของ Apache บนเซิร์ฟเวอร์เสมือนของคุณ

1: ปิดการใช้งานโมดูลที่ไม่จำเป็น

บนระบบที่คล้ายกับ Ubuntu และ Debian จะมีไดเร็กทอรี etc/apache2/mods-enabled และ /etc/apache2/mods-available/ ส่วนหลังจะเก็บรายการโมดูลทั้งหมดที่ติดตั้งบนเซิร์ฟเวอร์นี้ และไดเร็กทอรีที่เปิดใช้งาน mods จะมีโมดูลที่เปิดใช้งานอยู่ในปัจจุบัน

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

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

บน Ubuntu และ Debian โมดูลจะถูกปิดใช้งานโดยใช้คำสั่งนี้:

sudo a2dismod ดัชนีอัตโนมัติ

แต่ละโมดูลใช้ทรัพยากรจำนวนมาก หากคุณไม่ได้ใช้โมดูลต่อไปนี้ ให้ปิดการใช้งานโมดูลเหล่านี้:

• เขียนใหม่
• หลาม
• แร็ค/รูบี้/ผู้โดยสาร

โมดูลเหล่านี้บางส่วนไม่ได้เปิดใช้งานตามค่าเริ่มต้น แต่สถานการณ์จะแตกต่างกันไปในแต่ละเซิร์ฟเวอร์

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

หลังจากปิดใช้งานโมดูลแล้ว ให้รีสตาร์ท Apache จากนั้นตรวจสอบบันทึกข้อผิดพลาดเพื่อให้แน่ใจว่าการปิดใช้งานโมดูลไม่เป็นอันตรายต่อเว็บเซิร์ฟเวอร์

ตัวอย่างเช่น คุณอาจได้รับข้อผิดพลาดเช่นนี้:

ข้อผิดพลาดทางไวยากรณ์ในบรรทัด 6 ของ /etc/apache2/sites-enabled/site1:
คำสั่ง "DAVLockDB" ไม่ถูกต้อง อาจสะกดผิดหรือกำหนดโดยโมดูลที่ไม่รวมอยู่ในการกำหนดค่าเซิร์ฟเวอร์
การดำเนินการ "configtest" ล้มเหลว

ซึ่งหมายความว่าจำเป็นต้องมีโมดูลที่ปิดใช้งานเพื่อให้เว็บเซิร์ฟเวอร์ทำงานได้อย่างถูกต้อง เปิดเครื่อง

sudo a2enmod dav_fs

2: ย้ายรหัส

เว็บไซต์ PHP มักใช้โมดูล mod_php ยอดนิยม และเว็บไซต์ Ruby มักใช้ Passenger Phusion (โมดูล mod_rails หรือ mod_rack)

ปัญหาคือรหัส C สำหรับล่ามภาษาซ้อนอยู่ใน Apache ซึ่งต้องใช้หน่วยความจำเพิ่มเติมเพื่อดูแต่ละหน้า หากหน้าเว็บยอดนิยมบนไซต์ของคุณได้รับคำขอ HTTP 30 รายการ หนึ่งในนั้นจะเป็นคำขอ หน้าไดนามิกและส่วนที่เหลืออีก 29 รายการเป็นทรัพยากรแบบคงที่ (รูปภาพ, CSS และจาวาสคริปต์) เพื่อปรับปรุงประสิทธิภาพของ Apache คุณสามารถกำจัดคำขอ 29 รายการที่ไม่ให้บริการเนื้อหาแบบไดนามิกได้

การเปิดใช้งานโมดูล mod_php อาจส่งผลให้กระบวนการลูก Apache เดี่ยวต้องใช้ RAM 100 MB ยิ่งกระบวนการ Apache ทำงานบนเซิร์ฟเวอร์มากเท่าใด การประมวลผลก็จะยิ่งยากขึ้นเท่านั้น

เมื่อต้องการแก้ไขปัญหานี้ คุณสามารถใช้เครื่องมือต่อไปนี้:

• สำหรับ PHP คุณสามารถติดตั้ง php-fpm ซึ่งก็คือ กระบวนการที่แยกจากกันขึ้นอยู่กับโปรโตคอล fastcgi
• ใน Python ให้ใช้ uWSGI หรือ gnunicorn
• สำหรับ Rails ให้ใช้ยูนิคอร์น

โดยจะเริ่มกระบวนการสำหรับ PHP, Python หรือ Ruby ก่อน จากนั้น Apache จะเปลี่ยนเส้นทางการเรียกไปยังเนื้อหาแบบไดนามิกไปยังกระบวนการนั้น แทนที่จะพยายามจัดการกับมันด้วยโค้ดที่ซ้อนกัน

หลังจากลบโมดูล mod_php ขนาดของกระบวนการ Apache สามารถเปลี่ยนจาก 90-120 MB เหลือเพียง 10 MB เนื้อหาไดนามิกทั้งหมดให้บริการโดยเพียงสองกระบวนการบนแบ็กเอนด์

3: จำกัดจำนวนกระบวนการ Apache

ระบบปฏิบัติการจำนวนมากใช้การกำหนดค่าเริ่มต้นซึ่งไม่เหมาะมากสำหรับเซิร์ฟเวอร์ขนาดเล็ก - กระบวนการย่อย 25 รายการ หากกระบวนการลูกของ Apache แต่ละกระบวนการต้องการ RAM 120 MB เซิร์ฟเวอร์ก็จะใช้จ่าย 3 GB บน Apache เพียงอย่างเดียว

เว็บเบราว์เซอร์ของผู้ใช้หนึ่งรายสามารถขอองค์ประกอบไซต์ได้ 4 รายการในแต่ละครั้ง ซึ่งหมายความว่ามีเพียง 7-8 คนเท่านั้นที่สามารถโอเวอร์โหลดเซิร์ฟเวอร์ได้ หน้าเว็บค้างหรือโหลดช้ามาก

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

พิจารณาว่าแอปพลิเคชันของคุณต้องการ RAM เท่าใดและหน่วยความจำเหลืออยู่เท่าใด จากนั้นจัดสรรหน่วยความจำที่เหลือส่วนใหญ่ให้กับ Apache

ตัวอย่างเช่น คุณมีกระบวนการ php-fpm สามกระบวนการสำหรับการประมวลผลเนื้อหาไดนามิก โดยแต่ละกระบวนการใช้หน่วยความจำสูงสุด 70 MB และเซิร์ฟเวอร์ MySQL ที่ใช้ RAM สูงสุด 120 MB ผลลัพธ์คือแอปพลิเคชันใช้หน่วยความจำ 330 MB หากคุณมีเซิร์ฟเวอร์ขนาดเล็ก คุณสามารถจัดสรรหน่วยความจำประมาณ 150 MB ให้กับ Apache ได้

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

ด้านบน -bn 1
ผู้ใช้ PID PR NI VIRT RES SHR S % CPU % MEM TIME + คำสั่ง
[...]
15015 www-ข้อมูล 20 0 232m 9644 1900 S 0.0 1.6 0:00.02 apache2
15016 www-ข้อมูล 20 0 232m 9644 1900 S 0.0 1.6 0:00.01 apache2
15017 www-ข้อมูล 20 0 232m 9644 1900 S 0.0 1.6 0:00.02 apache2

ค้นหาค่าในคอลัมน์ RES สำหรับ Apache (เช่น 9644) แล้วจดบันทึกไว้ ขณะนี้เว็บเซิร์ฟเวอร์ใช้หน่วยความจำเกือบ 10 MB หากคุณจำกัดจำนวนกระบวนการลูกของ Apache ไว้ที่ 15 หน่วยความจำที่จัดสรร 150 MB ก็เพียงพอแล้ว

แก้ไขไฟล์การกำหนดค่า Apache (บน Ubuntu และ Debian นี่คือ /etc/apache2/apache2.confand) และค้นหาส่วน mpm_prefork_module ค้นหาบรรทัด MaxClients แล้วป้อน 15 จากนั้นบันทึกไฟล์และรีสตาร์ทเว็บเซิร์ฟเวอร์

เริ่มเซิร์ฟเวอร์ 3
เซิร์ฟเวอร์ขั้นต่ำ 3
MaxSpareServers5
แม็กซ์ไคลเอนท์ 30
MaxRequestsPerChild 0

โดยค่าเริ่มต้น ค่า MaxClients อาจมีขนาดใหญ่มาก มันจำเป็นต้องลดลง

เมื่อจำนวนลูกค้าถึงขีดจำกัด ลูกค้าใหม่จะได้รับข้อผิดพลาด เมื่อโหลดหน้าซ้ำ พวกเขาจะสามารถเข้าถึงไซต์ได้

ฟังดูแย่ แต่ก็ยังดีกว่าถ้าปิดการเชื่อมต่อเหล่านี้อย่างรวดเร็วและทำให้เซิร์ฟเวอร์ทำงานตามปกติ ดีกว่ารอจนกว่าเซิร์ฟเวอร์จะหยุดทำงาน

ในบางสถานการณ์ กระบวนการลูกน้อยลงสามารถช่วยปรับปรุงประสิทธิภาพของเซิร์ฟเวอร์ได้

การกำหนดค่า Apache มักใช้ prefork mpm ซึ่งถือว่าปลอดภัยและเหมาะสำหรับ PHP และภาษาอื่นๆ

ถ้าคุณกำจัด โมดูลภายนอก(PHP หรือ Rails) คุณอาจพิจารณา MPM ของผู้ปฏิบัติงานเป็นทางเลือก

หากต้องการเปิดใช้งานโมดูลนี้ ให้ป้อน:

sudo apt-get ติดตั้ง apache2-mpm-worker
แพ็คเกจต่อไปนี้จะถูกลบออก:
apache2-mpm-prefork libapache2-mod-php5.1
แพ็คเกจใหม่ต่อไปนี้จะถูกติดตั้ง:
apache2-mpm-คนงาน
อัปเกรดแล้ว 0 รายการ ติดตั้งใหม่ 1 รายการ ต้องลบ 2 รายการ และไม่ได้อัปเกรด 2 รายการ
จำเป็นต้องได้รับไฟล์เก็บถาวร 2,284 B
หลังจากการดำเนินการนี้ พื้นที่ดิสก์ 8,718 kB จะถูกทำให้ว่าง
คุณต้องการดำเนินการต่อหรือไม่?

ความสนใจ!บน Ubuntu การติดตั้งโมดูลผู้ปฏิบัติงานจะลบ prefork mpm, mod_php และโมดูลอื่น ๆ ที่เข้ากันไม่ได้

แท็ก:

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

โหลดเฉพาะโมดูลที่จำเป็นเท่านั้น

Apache เป็นโปรแกรมโมดูลาร์ที่มีการใช้งานฟังก์ชั่นส่วนใหญ่ในโมดูล นอกจากนี้ โมดูลเหล่านี้สามารถคอมไพล์หรือประกอบในรูปแบบของ DSO - ไลบรารีแบบไดนามิก ดิสทริบิวชันสมัยใหม่ส่วนใหญ่จะจัดส่ง Apache พร้อมด้วยชุด DSO เพื่อให้สามารถปิดการใช้งานโมดูลที่ไม่จำเป็นได้อย่างง่ายดายโดยไม่ต้องคอมไพล์ใหม่
รัน apache ด้วยโมดูลที่จำเป็นเท่านั้นเพื่อลดการใช้หน่วยความจำ หากคุณตัดสินใจที่จะคอมไพล์ apache ด้วยตัวเอง ให้เลือกรายการโมดูลที่คุณรวมไว้ หรือคอมไพล์เป็น DSO โดยใช้ apxs ใน apache1 และ apxs2 ใน apache2 หากต้องการปิดใช้งานโมดูล DSO ที่ไม่จำเป็น เพียงใส่เครื่องหมายบรรทัด LoadModule พิเศษใน httpd.conf Apache ที่มีโมดูลที่คอมไพล์แบบคงที่จะใช้หน่วยความจำน้อยกว่าเล็กน้อย แต่คุณจะต้องคอมไพล์ใหม่ทุกครั้งเพื่อเปลี่ยนรายการโมดูล

เลือก MPM ที่เหมาะสม

ใน Apache แต่ละคำขอจะได้รับการประมวลผลในกระบวนการหรือเธรดของตัวเอง เมื่อคอมไพล์แล้ว apache ให้คุณเลือก MPM (โมดูลการประมวลผลหลายตัว) หนึ่งในหลายตัว ซึ่งมีหน้าที่รับผิดชอบในการฟังพอร์ต ยอมรับคำขอ และกระจายคำขอเหล่านี้ไปยังกระบวนการลูกหรือเธรดที่คำขอเหล่านี้จะถูกประมวลผล
การเลือก MPM ขึ้นอยู่กับปัจจัยหลายประการ เช่น OS มีการรองรับเธรดหรือไม่ จำนวนหน่วยความจำที่ว่าง และข้อกำหนดด้านความเสถียรและความปลอดภัย
หากการรักษาความปลอดภัยเป็นสิ่งสำคัญมาก คุณควรเลือก MPM ของผู้ใช้โดยยอมเสียสละประสิทธิภาพ
หากประสิทธิภาพเป็นสิ่งสำคัญ ตัวเลือกจะจำกัดอยู่ที่ 2 mpm: พรีฟอร์กและคนงาน
คนงาน- โฟลว์ MPM เช่น ในนั้น แต่ละคำขอจะให้บริการในเธรดที่แยกจากกันของกระบวนการลูกอย่างใดอย่างหนึ่ง เธรดเป็นอ็อบเจ็กต์สำหรับระบบปฏิบัติการที่ง่ายกว่ากระบวนการที่ใช้หน่วยความจำอย่างมีประสิทธิภาพมากกว่าและการสลับบริบทนั้นเร็วกว่าสำหรับเธรดเหล่านั้น อย่างไรก็ตาม เนื่องจากแต่ละเธรดสามารถเข้าถึงหน่วยความจำทั้งหมดของกระบวนการ mpm ของผู้ปฏิบัติงานจึงมีแนวโน้มที่จะล้มเหลวมากกว่า: ความล้มเหลวของเธรดเดียวอาจทำให้กระบวนการทั้งหมดที่เธรดนั้นตั้งอยู่เสียหาย (ซึ่งเป็นเหตุผลว่าทำไม mpm ของผู้ปฏิบัติงานจึงเริ่มการทำงานย่อยหลายรายการ กระบวนการที่มีหลายเธรดในแต่ละ )
ส้อม- mpm ใช้กระบวนการลูกหลายกระบวนการ แต่ละกระบวนการลูกจัดการการเชื่อมต่อเดียว เนื่องจากกระบวนการนี้เป็นโครงสร้างที่หนักกว่า จึงใช้ทรัพยากรมากกว่าเล็กน้อย แต่มีโอกาสล้มเหลวน้อยกว่า - การประมวลผลคำขอแต่ละรายการไม่ได้ขึ้นอยู่กับกระบวนการอื่น
ขออภัย การเปลี่ยน mpm จำเป็นต้องคอมไพล์ Apache ใหม่ นี่คือจุดที่การแจกแจงตามแหล่งที่มาแสดงข้อดี: คุณสามารถคอมไพล์ Apache ใหม่และแพ็คเกจที่ต้องพึ่งพาทั้งหมดได้อย่างง่ายดายโดยไม่ต้องเปลี่ยนระบบให้เป็นดัมพ์ การแจกแจงแบบไบนารีจัดการกับสถานการณ์นี้ในรูปแบบที่แตกต่างกัน ตัวอย่างเช่น ใน RHEL apache rpm มี apache สองเวอร์ชัน - พร้อมด้วย worker และ prefork mpm (prefork ถูกใช้เป็นค่าเริ่มต้น) อย่างไรก็ตาม mpm ของผู้ปฏิบัติงานไม่รองรับ php ดังนั้นหากคุณต้องการ php และ mpm ของผู้ปฏิบัติงาน คุณจะต้องคอมไพล์มันเองหรือมองหาที่เก็บข้อมูลของบุคคลที่สาม

การค้นหา DNS

คำสั่ง HostnameLookups ประกอบด้วย DNS ย้อนกลับคำขอ เพื่อให้โฮสต์ DNS ของลูกค้าถูกรวมไว้ในบันทึกแทนที่อยู่ IP แน่นอนว่าสิ่งนี้จะทำให้การประมวลผลคำขอช้าลงอย่างมาก เนื่องจาก... คำขอจะไม่ได้รับการประมวลผลจนกว่าจะได้รับการตอบกลับจากเซิร์ฟเวอร์ DNS ดังนั้น ตรวจสอบให้แน่ใจว่าคำสั่งนี้ปิดอยู่เสมอ (ปิด HostnameLookups) และหากคุณยังต้องการที่อยู่ DNS คุณสามารถค้นหาได้ในภายหลังโดยเรียกใช้บันทึกในยูทิลิตี้ logresolve (ซึ่งมาพร้อมกับ Apache)
นอกจากนี้ ตรวจสอบให้แน่ใจว่าคำสั่ง Allow from และ Deny From ใช้ที่อยู่ IP ไม่ใช่ ชื่อโดเมน- มิฉะนั้น apache จะส่งคำขอ DNS สองครั้ง (ย้อนกลับและส่งต่อ) เพื่อให้แน่ใจว่าไคลเอนต์คือคนที่เขาอ้างว่าเป็น

อนุญาตแทนที่

หากไม่ได้ตั้งค่าคำสั่ง AllowOverride เป็น 'ไม่มี' apache จะพยายามเปิดไฟล์ .htaccess ในทุกไดเร็กทอรีที่เยี่ยมชมและในไดเร็กทอรีทั้งหมดที่อยู่เหนือมัน ตัวอย่างเช่น:

DocumentRoot /var/www/html อนุญาตแทนที่ทั้งหมด

หากมีการร้องขอ /index.html apache จะพยายามเปิด (และตีความ) ไฟล์ /.htaccess, /var/.htaccess, /var/www/.htaccess และ /var/www/html/.htaccess สิ่งนี้จะเพิ่มเวลาการประมวลผลคำขอ ดังนั้น หากคุณต้องการเพียง .htaccess สำหรับไดเร็กทอรีเดียว ให้อนุญาตเฉพาะไดเร็กทอรีนั้นเท่านั้น:

DocumentRoot /var/www/html AllowOverride ไม่มี อนุญาตแทนที่ทั้งหมด

FollowSymLinks และ SymLinksIfOwnerMatch

หากเปิดใช้งานตัวเลือก FollowSymLinks สำหรับไดเร็กทอรี เซิร์ฟเวอร์จะติดตาม ลิงก์สัญลักษณ์ในไดเรกทอรีนี้ หากเปิดใช้งานตัวเลือก SymLinksIfOwnerMatch สำหรับไดเร็กทอรี apache จะติดตามลิงก์สัญลักษณ์เฉพาะในกรณีที่เจ้าของไฟล์หรือไดเร็กทอรีที่ลิงก์ชี้ไปนั้นตรงกับเจ้าของไดเร็กทอรีที่ระบุ ดังนั้นเมื่อเปิดใช้งานตัวเลือก SymLinksIfOwnerMatch apache จะส่งคำขอของระบบเพิ่มเติม
นอกจากนี้ จำเป็นต้องมีคำขอของระบบเพิ่มเติมเมื่อไม่ได้ติดตั้ง FollowSymlinks ที่. สถานการณ์ด้านประสิทธิภาพที่ดีที่สุดคือเมื่อเปิดใช้งานตัวเลือก FollowSymlinks

การเจรจาต่อรองเนื้อหา

พยายามหลีกเลี่ยงการเจรจาเนื้อหา

MaxClients

คำสั่ง MaxClients กำหนดจำนวนคำขอพร้อมกันสูงสุดที่เซิร์ฟเวอร์จะสนับสนุน Apache จะไม่วางไข่กระบวนการ/เธรดมากกว่า MaxClients ค่า MaxClient ไม่ควรเล็กเกินไป (ไม่เช่นนั้นไคลเอนต์จำนวนมากจะยังคงไม่ได้รับบริการ) แต่คุณไม่ควรตั้งค่าตัวเลขมากเกินไป - เป็นการดีกว่าที่จะไม่ให้บริการลูกค้าบางรายแทนที่จะใช้ทรัพยากรทั้งหมดจนหมด เข้าสู่การสลับและตายภายใต้โหลด ค่าที่ดีอาจเป็น MaxClients = จำนวนหน่วยความจำที่จัดสรรสำหรับเว็บเซิร์ฟเวอร์ / ขนาดสูงสุดของกระบวนการที่สร้างหรือเธรด สำหรับไฟล์คงที่ apache จะใช้ประมาณ 2-3 MB ต่อกระบวนการ สำหรับไฟล์ไดนามิก (php, cgi) - ขึ้นอยู่กับสคริปต์ แต่โดยทั่วไปจะประมาณ 16-32 MB

หากเซิร์ฟเวอร์ให้บริการคำขอ MaxClients อยู่แล้ว คำขอใหม่จะถูกจัดคิว ซึ่งขนาดจะถูกกำหนดโดยใช้คำสั่ง ListenBacklog

MinSpareServers, MaxSpareServers และ StartServers

เพราะ การสร้างเธรด และโดยเฉพาะอย่างยิ่งกระบวนการ เป็นการดำเนินการที่มีราคาแพง apache สร้างขึ้นล่วงหน้า คำสั่ง MaxSpareServers และ MinSpareServers กำหนดจำนวนกระบวนการ/เธรดที่ควรรอพร้อมที่จะยอมรับคำขอ (สูงสุดและต่ำสุด) หากค่า MinSpareServers น้อยเกินไปและมีคำขอจำนวนมากมาโดยไม่คาดคิด apache จะถูกบังคับให้สร้างกระบวนการ/เธรดใหม่จำนวนมาก ซึ่งจะสร้างภาระเพิ่มเติมในสถานการณ์ที่ตึงเครียดนี้ ในทางกลับกัน หาก MaxSpareServers มีขนาดใหญ่เกินไป apache จะโหลดระบบอย่างหนักด้วยกระบวนการเหล่านี้ แม้ว่าจำนวนไคลเอ็นต์จะน้อยมากก็ตาม
ลองตั้งค่า MinSpareServers และ MaxSpareServers โดยที่ apache จะไม่สร้างกระบวนการ/เธรดมากกว่า 4 กระบวนการต่อวินาที หากสร้างมากกว่า 4 ข้อความเกี่ยวกับสิ่งนี้จะถูกวางไว้ใน ErrorLog นี่เป็นสัญญาณว่า MinSpareServers มีขนาดเล็กเกินไป

MaxRequestsPerChild

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

KeepAlive และ KeepAliveTimeout

KeepAlive ช่วยให้คุณสามารถส่งคำขอหลายรายการในการเชื่อมต่อ TCP เดียว สิ่งนี้มีประโยชน์อย่างยิ่งสำหรับหน้า html ที่มีรูปภาพจำนวนมาก หาก KeepAlive ถูกตั้งค่าเป็นปิด การเชื่อมต่อแยกต่างหากจะถูกสร้างขึ้นสำหรับเพจเองและสำหรับแต่ละรูปภาพ (ซึ่งจะต้องได้รับการประมวลผลโดยกระบวนการหลัก) ซึ่งไม่ดีสำหรับทั้งเซิร์ฟเวอร์และไคลเอนต์ ดังนั้นในกรณีเช่นนี้ ขอแนะนำให้ตั้งค่า KeepAlive เป็น On สำหรับแอปพลิเคชันอื่น (เช่น สำหรับเซิร์ฟเวอร์ดาวน์โหลด) KeepAlive อาจไม่มีประโยชน์และเป็นอันตรายด้วยซ้ำ เมื่อเปิดใช้งาน KeepAlive เซิร์ฟเวอร์จะไม่ปิดการเชื่อมต่อทันที แต่จะรอ KeepAliveTimeout วินาทีสำหรับการร้องขอใหม่ เพื่อป้องกันไม่ให้กระบวนการต้องคอยนานเกินไปโดยไม่จำเป็น ให้ตั้งค่า KeepAliveTimeout ให้น้อยพอ โดยปกติแล้วประมาณ 5-10 วินาทีก็เพียงพอแล้ว

การบีบอัด

การบีบอัด HTTP ถูกกำหนดไว้ในมาตรฐาน HTTP/1.1 และขณะนี้โปรแกรมไคลเอนต์สมัยใหม่ทั้งหมดและเซิร์ฟเวอร์เกือบทั้งหมดรองรับแล้ว เซิร์ฟเวอร์สามารถส่งคืนการตอบกลับในรูปแบบ gzip หรือยุบ และโปรแกรมไคลเอนต์จะขยายขนาดข้อมูลที่ผู้ใช้ไม่มีใครสังเกตเห็น ซึ่งจะช่วยลดปริมาณการรับส่งข้อมูลที่ถ่ายโอน (สูงสุด 75%) แต่แน่นอนว่าจะเพิ่มการใช้งาน CPU
อย่างไรก็ตาม หากไคลเอนต์จำนวนมากเยี่ยมชมเซิร์ฟเวอร์ของคุณโดยใช้การเชื่อมต่อที่ช้า การบีบอัดสามารถลดภาระบนเซิร์ฟเวอร์ของคุณได้ เนื่องจากเซิร์ฟเวอร์สามารถส่งมอบการตอบสนองที่บีบอัดได้เร็วขึ้น และเพิ่มทรัพยากรที่ครอบครองโดยกระบวนการลูก เอฟเฟกต์นี้สามารถสังเกตเห็นได้ชัดเจนเป็นพิเศษหากคุณมีโปรเซสเซอร์ที่รวดเร็ว แต่มีหน่วยความจำน้อย
การแคชถูกกำหนดค่าโดยคำสั่งโมดูล mod_deflate โปรดทราบว่าคุณไม่ควรตั้งค่าระดับการบีบอัด gzip มากกว่า 4-5 ซึ่งจะต้องใช้เวลา CPU มากขึ้นอย่างมาก และผลกระทบจะค่อนข้างน้อย แน่นอนว่าไม่จำเป็นต้องพยายามบีบอัดรูปภาพเป็น jpg, gif และ png, เพลง, ไฟล์วิดีโอ และไฟล์ไบนารีอื่น ๆ ทั้งหมดที่ได้รับการบีบอัดอย่างดีอยู่แล้ว