Mysql rất chậm trên Dịch vụ ứng dụng Azure w/PHP (Wordpress)

Tôi đang cố gắng khắc phục sự cố với kết nối Dịch vụ ứng dụng Azure với Cơ sở dữ liệu Azure rất chậm.

Sau khi Wordpress chuyển đổi thành dịch vụ lưu trữ OVH giá rẻ, tôi nhận thấy TTFB cực kỳ dài: tăng từ 300-400 mili giây lên 1500-3000 mili giây.

Tôi đã thu hẹp vấn đề thành dịch vụ ứng dụng - sự cố kết nối cơ sở dữ liệu. Để xác định vấn đề, tôi đã tạo bản cài đặt Wordpress sạch. Theo P3 - Plugin Performance Profiler, cài đặt WP sạch sẽ tạo ra 38 truy vấn cơ sở dữ liệu.

Với plugin thống kê hiệu suất CPU PHP/MySQL, tôi đã chạy MySql Test:

• Dịch vụ ứng dụng Azure: 20-50 truy vấn db/giây
• Lưu trữ OVH giá rẻ: hơn 200 truy vấn db/giây

Tôi nghĩ rằng vấn đề khá rõ ràng nếu ngăn xếp Azure 200 USD/tháng chậm hơn khoảng 20 lần so với 10 USD OVH (tuy nhiên: tôi đã phát hiện ra rằng thậm chí ~40 truy vấn db mỗi giây có thể dẫn đến TTFB khoảng 300 mili giây, điều mà tôi đang hướng tới ).

Để khắc phục sự cố này, tôi đã thử các kiểm tra/thay đổi sau:

• Các gói dịch vụ ứng dụng khác nhau (từ nhà phát triển đến P2v3)
• các máy chủ Cơ sở dữ liệu Azure khác nhau (từ rẻ nhất đến ~300 usd/tháng)
• PHP 7.4 và PHP 8.0
• Apache và nginx (tự động đi kèm với thay đổi php 7/8)
• Cơ sở dữ liệu Azure Máy chủ đơn và linh hoạt
• Cơ sở dữ liệu Azure cho MySQL và cho MariaDB
• dịch vụ ứng dụng để kết nối cơ sở dữ liệu qua IP công cộng và qua tích hợp vnet
• đặt cơ sở dữ liệu trong cùng một vùng khả dụng
• kết nối ứng dụng/cơ sở dữ liệu ssl và không ssl
• chuyển hướng cơ sở dữ liệu với mysqlnd_azure
• đã thử độ bền kết nối
• Wordpress trong bộ chứa docker Dịch vụ ứng dụng

Không có điều nào ở trên thực hiện bất kỳ thay đổi đáng kể trong hiệu suất. "Cách khắc phục" duy nhất "hoạt động" là bật bộ đệm. Nếu bộ đệm bị tấn công, TTFB là khoảng 100 ms như mong đợi.

Tôi cũng đã đo điểm chuẩn AWS Elastic Beanstalk/RDS và Google App Engine/CloudSQL và chúng hoạt động hoàn hảo (~250 ms TTFB ngay khi mở hộp). Máy ảo Azure (PHP + Apache) được kết nối với cùng một Cơ sở dữ liệu Azure hoạt động tốt (<300ms TTFB).

Tôi không có ý kiến. Tôi đang thiếu gì? Nói rõ hơn: Tôi không cố gắng đạt được thời gian phản hồi một chữ số hoặc hiệu suất cuối cùng - 300 mili giây có thể chấp nhận được đối với cài đặt WP sạch.

Tôi cũng gặp tình huống giống như vậy. Azure rất rất chậm và không có gì hoạt động?

PP_1, Ý bạn là gì khi bật bộ đệm? Bạn có nghĩa là các plugin như WP Rocket?

Có cùng một vấn đề ở đây. tôi đã thực hiện một số thử nghiệm kết nối với phiên bản bộ chứa thông qua web ssh và điều tôi nhận thấy là phải mất php 200-300ms chỉ để tải plugin. h nên kết luận cuối cùng của tôi là Azure có vấn đề với php.

Tôi rất tò mò muốn biết liệu có ai đã đạt được hiệu suất tốt trên Azure mà không cần lưu vào bộ đệm (với php trên linux).

Cuối cùng, chúng tôi đã định cấu hình ứng dụng bằng một tập lệnh khởi động cấu hình lại NGIX để tích cực lưu vào bộ nhớ đệm các trang, phù thủy hoạt động tốt đối với một số trang web của chúng tôi, nhưng nó không phải là lý tưởng.Hiện tại, chúng tôi có TTFB là 50 mili giây cho các trang được lưu trong bộ nhớ cache.

Một vài điều cần xem xét vì chúng không được đề cập trong câu hỏi.

1. Đảm bảo ứng dụng web và cơ sở dữ liệu nằm trong cùng một khu vực. Điều này có vẻ cơ bản nhưng tôi đã thấy nó trước đây.
2. Cho phép Luôn luôn trong cài đặt cho Dịch vụ ứng dụng Azure. Luôn luôn: Giữ cho ứng dụng được tải ngay cả khi không có lưu lượng truy cập. Khi Luôn bật không được bật (mặc định), ứng dụng sẽ được tải sau 20 phút mà không có bất kỳ yêu cầu gửi đến nào. Ứng dụng không được tải có thể gây ra độ trễ cao cho các yêu cầu mới do thời gian khởi động của ứng dụng. Khi nào Luôn luôn được bật, bộ cân bằng tải giao diện người dùng sẽ gửi yêu cầu GET đến ứng dụng gốc cứ sau 5 phút.Ping liên tục ngăn không cho tải ứng dụng.
3. Ôn tập Các phương pháp hay nhất về dịch vụ ứng dụng.