Tối ưu hóa apache / php / mysql chạy trên VPS để tải nặng

Câu hỏi về tối ưu hóa máy chủ apache / mysql trên VPS với 512m RAM. Dưới tải bình thường mọi thứ chạy nhanh, không có độ trễ kết nối. Tuy nhiên, khi chúng tôi nhận được số ngày lưu lượng truy cập lớn (50 nghìn lượt truy cập), trang web sẽ thu thập dữ liệu và phải mất 30 giây + để lấy lại nội dung từ apache.

Trang web đang chạy trên Expression Engine (CMS) (bằng PHP) và tôi đã làm theo hướng dẫn tối ưu hóa tải nặng của họ. Tôi đã googled và theo dõi khá nhiều người ngoài kia vì một chút may mắn, đưa nó đến nơi hiện tại, nhưng tôi cần phải có được thời gian phản hồi liên tục.

Tôi cho rằng điều này khác với câu hỏi 'tối ưu hóa cho bộ nhớ thấp' ở đây vì tôi có đủ RAM (cho những gì tôi đang cố gắng làm), tôi chỉ cần làm cho máy chủ không bị nghẹt dưới tải nặng.

Bất kỳ đề nghị?

Đối với PHP có 2 điều quan trọng sẽ tăng dung lượng:

1. Bộ nhớ đệm PHP nâng cao (APC) như đã đề cập. Đây là những gì chúng tôi sử dụng tại Yahoo! Có những dự án tương tự khác, nhưng dự án này là em bé của Rasmus.
2. FastCGI thay vì mod_php. Có tranh luận về vấn đề này vì mod_php thường là nhanh nhất. Tuy nhiên, tôi sẽ giả định rằng bạn có một máy chủ Apache duy nhất cung cấp cả nội dung PHP động và tài sản tĩnh (JS, CSS, flash, hình ảnh, PDF, v.v.). Các yêu cầu cho các tài sản tĩnh đó không cần tiêu tốn nhiều bộ nhớ, nhưng vì PHP là một mô-đun nên nó có trong mọi luồng của Apache.

Đối với Apache:

1. Sử dụng MPM công nhân
2. Kích hoạt KeepAlive

Bạn cũng có thể xem xét chuyển đổi từ Apache sang Lighttpd hoặc Nginx . Tôi yêu Apache. Tôi sử dụng các tính năng tiên tiến của nó. Tôi chấp nhận chi phí của nó bởi vì tôi cần những gì nó cung cấp. Đối với ngăn xếp LAMP thông thường, nó là nhiều hơn mức cần thiết và lãng phí tài nguyên.

Đối với MySQL:

1. Những nỗ lực tối ưu hóa của bạn sẽ được đền đáp gấp 10 lần khi dành để phân tích và sửa các truy vấn, thay vì điều chỉnh các giá trị my.cnf của bạn. Tôi không nói rằng việc bộ nhớ đệm, kết nối, v.v. của bạn không quan trọng ... nhưng đối với hầu hết mọi người, đó chỉ là 9% vấn đề.
2. Trong QA của bạn, hãy bật nhật ký truy vấn chung trên staging / dev mysqld của bạn để nắm bắt tất cả các truy vấn được gửi. (KHÔNG làm điều đó trên máy chủ mysql sản xuất của bạn!)
3. Sử dụng GIẢI THÍCH để phân tích các truy vấn. Đặc biệt, nếu bạn đang sử dụng một khung công tác với ORM (tóm tắt DB và ngăn bạn viết SQL của riêng bạn), bạn sẽ cần xóa sạch các THAM GIA ngoại lai, CHỌN không có mệnh đề WHERE, ORDER BYs tạo ra 'bằng cách sử dụng tệp' và truy vấn sử dụng không có chỉ mục.
4. Nếu bạn đang sử dụng MySQL 5.1, hãy tận dụng cấu hình truy vấn .

Các công cụ khác đáng xem xét là mk-visual-giải thích

Tôi đã trích dẫn 10 tài liệu tham khảo tuyệt vời. Những điều này nên làm cho bạn ồn ào. Xin vui lòng cho chúng tôi biết làm thế nào nó bật ra.

Di chuyển các tệp phiên PHP của bạn sang một tmpfs , sử dụng APC (hoặc loại khác) và xóa tất cả các mô-đun PHP mà bạn không cần. Xóa tất cả các mô-đun Apache mà bạn không cần / sử dụng.

Để tạo một tmpfs (một thư mục trong RAM!)

mkdir /tmpfs; chmod 777 /tmpfs
mount -t tmpfs -o size=256M tmpfs /tmpfs

Trong / etc / fstab thêm dòng bên dưới để tạo nó khi khởi động lại!

tmpfs     /tmpfs    tmpfs   size=256m,mode=0777    0       0

Trong /etc/apache2/php.ini điều chỉnh để lưu trữ các phiên của bạn trong RAM (tmpfs)!

session.save_handler = files
session.save_path = "/tmpfs"

Lưu ý: Với các tệp PHP VÀ tệp phiên trong RAM, bạn hầu như không chạm vào đĩa!

Sử dụng expires_module trong apache để trình duyệt sẽ lưu trữ hầu hết mọi thứ.

ExpiresActive On
ExpiresDefault "access plus 90 days"
ExpiresByType image/gif "access plus 90 days"
ExpiresByType image/ico "access plus 90 days"
ExpiresByType image/png "access plus 90 days"
ExpiresByType image/jpeg "access plus 90 days"
ExpiresByType image/x-icon "access plus 90 days"
ExpiresByType text/css "Access plus 90 days"
ExpiresByType text/html "Access plus 90 days"
ExpiresByType application/x-shockwave-flash "Access plus 90 days"
ExpiresByType application/x-javascript "Access plus 90 days"

Không sử dụng tập tin .htaccess ! Thay vào đó, mã cứng chúng trong tập tin cấu hình vhost! Sẽ loại bỏ mạnh mẽ / giảm kiểm tra đĩa cho tất cả các yêu cầu http ... nó thực sự bổ sung.

Options FollowSymLinks 
AllowOverride None

Ví dụ về .htaccess được sử dụng trong tệp vhost.conf của bạn ...

<Directory /home/user/www/site.com/secure>
    Order Allow,Deny
    Deny from All
</Directory>

Vài điều đến với tâm trí.

Opcode cache luôn là một ý tưởng tốt. Tôi thích http://eaccelerator.net/ hơn APC. Nếu bạn chưa phát triển với APC trong suốt quá trình cố gắng thêm nó vào thì hầu như luôn luôn đau đớn. Eaccelerator trong khi không ưa thích chỉ có vẻ hoạt động.

Một proxy ngược cũng là một ý tưởng tốt, nhưng bạn cần xem việc sử dụng RAM. Tôi tìm thấy Apache 2.2 với mpm-worker để sở hữu một lượng RAM khá lớn. Trong trường hợp của bạn, tôi muốn giới thiệu một cái gì đó nhẹ hơn như Nginx và chạy Apache với PHP dưới dạng FASTCGI hoặc chỉ để nó theo quy trình. Ý tưởng với việc sử dụng Varnish, Squid, Nginx, v.v. là để chúng phục vụ nội dung tĩnh, xử lý các kết nối người dùng và chỉ chuyển các yêu cầu PHP tới Apache mà bạn coi là máy chủ ứng dụng.

Nếu bạn đang chạy phiên bản khá gần đây của Mysql 5.1, như ít nhất 5.1.24 thì bây giờ bạn có quyền truy cập vào nhật ký chậm thứ hai phụ. Tôi sẽ bắt đầu long_query_time ở mức 1 hoặc 2 và sau đó hạ xuống 0,5 khi bạn xử lý những cái thực sự dài. Ngoài ra còn có rất nhiều thông tin điều chỉnh chung trên mạng cho Mysql, nhưng bạn không có RAM để làm nhiều việc. Bạn đã tăng bất kỳ cài đặt nào từ mặc định chưa? Hầu hết các tệp my.cnf mặc định được cấu hình để sử dụng khoảng 64 MB RAM. Ít nhất tôi cũng sẽ nâng key_buffer từ 16MB lên 64MB.

Ngoài ra, bạn đang sử dụng bảng Myisam hoặc Innodb? Nếu bạn đang giữ phiên trong DB, bạn sẽ muốn thay đổi bảng phiên thành Innodb (hoặc thay vào đó là cookie) thay vì để lại bảng Mysiam có khóa cấp bảng thay vì khóa cấp hàng. Về cơ bản, bất kỳ bảng nào có nhiều hơn 20% ghi đến 80% số lần đọc là một ứng cử viên để chuyển sang Innodb. Hãy nhớ rằng bạn sẽ cần phải cân bằng dung lượng RAM giữa các bảng Myisam và bảng Innodb vì các bộ đệm cho mỗi bảng được cấu hình riêng biệt.

Và cuối cùng, 512MB RAM khác sẽ đi một chặng đường dài trong thiết lập của bạn hoặc thậm chí một VPS 512 MB khác để chạy Mysql nếu giá rẻ hơn hoặc gần bằng giá. Tôi thực sự nghiêng về một ví dụ thứ hai vì điều đó sẽ nhân đôi số đĩa IO có sẵn. Một trong những vấn đề với máy chủ VPS là IO của bạn không được bảo vệ khỏi những người khác trên cùng một máy chủ vật lý.

Hmmm bài viết của tôi tất cả sắp xếp rải rác, nhưng cung cấp cho bạn rất nhiều nơi để tìm. Chúc may mắn.

• Sử dụng bộ đệm opcode cho php như apc.
• Sử dụng một máy gia tốc http như mực hoặc véc ni.

Trong tình huống bộ nhớ thấp (512Mb là thấp, đối với máy chủ có lưu lượng truy cập cao), bạn nên cân nhắc lựa chọn máy chủ web và công cụ DB.

Lighttp nhẹ hơn so với Apache thường có thể được thực hiện sau nhiều lần điều chỉnh và thậm chí còn có các tùy chọn nhẹ hơn thế. Điều này tất nhiên là không thể nếu có các tính năng Apache mà bạn phụ thuộc vào đó không hỗ trợ trong các máy chủ khác.

sqlite chặt chẽ hơn nhiều so với myQuery và cũng nhanh hơn trong nhiều điều kiện. Kiểm tra xem động cơ bạn đang sử dụng có hỗ trợ điều này không và liệu nó có thử không.

Tùy chọn khác, tùy chọn dễ dàng, là lấy thêm RAM trong VM nếu bạn có đủ khả năng.

Ngoài các đề xuất tuyệt vời ở đây, cần lưu ý rằng tất cả các VPS 'không được tạo ra bằng nhau. Theo kinh nghiệm của tôi, PHP hóa ra là CPU nặng.

Điểm chuẩn Wordpress AB (ab -n 500 -c 25 http://domain.com/index.php ) của nginx / apc / phpfpm / mysql (cục bộ) trên EC2 dẫn đến ~ 2 yêu cầu / giây ở mức nhập cảnh "2GB RAM / 1 Máy chủ đơn vị tính toán ".

Điểm chuẩn tương tự chạy với cùng một ngăn xếp chính xác (được kịch bản triển khai cho hệ điều hành giống hệt nhau) trên Máy chủ đám mây Rackspace 512 MB trả về ~ 80 req / giây. Vì vậy, 4x Ít ram, hiệu suất 40 lần trong thí nghiệm thô sơ này.

Xem hàng đầu trong AB bạn thấy rằng EC2 đơn giản là không thể xử lý đồng thời và ngay lập tức sẽ đạt 100% tải CPU và khóa. Xem hàng đầu trên Máy chủ 512 MB (CPU lõi tứ ảo hóa) có cùng điểm chuẩn, Các lõi sẽ đạt Tải trọng ~ 60% và xử lý trơn tru điểm chuẩn.

VPS cực kỳ dễ dàng để quay vòng và tắt mà không cần cam kết, sẽ không hại gì khi đưa cơ sở hạ tầng mà VM / VPS của bạn nằm trong thử nghiệm!

EDIT 1: Ngoài ra, Trường hợp nhỏ "CPU cao" của EC2 chỉ có thể mang lại ~ 10 / req giây, với CPU vẫn là nút cổ chai. Kết luận của tôi là bạn hy sinh hiệu năng cho sự ổn định / mạnh mẽ với EC2, và tất nhiên có nhiều trường hợp sử dụng đòi hỏi một môi trường như vậy.