Điểm:0

Apache với PHP FPM và yêu cầu tăng đột biến, cách đặt cấu hình tối ưu?

lá cờ vu

Tôi đã đủ may mắn khi trang web của mình được lan truyền rộng rãi, và tất nhiên là máy chủ chưa sẵn sàng cho việc đó.

Thật không may, thiết lập của tôi khá tệ, một máy chủ duy nhất có Apache, PHP (Laravel), Mongodb và redis.

Phần phụ trợ (laravel) chủ yếu phục vụ API REST. Tôi hiện có hơn 1000 người dùng đồng thời đang cố gắng sử dụng trang web và mọi thứ tải rất chậm. MongoDB dường như đang hoạt động tốt, vì tôi có thể truy cập nó thông qua thiết bị đầu cuối và các truy vấn được giải quyết ngay lập tức. Điều làm tôi lo lắng là cấu hình Apache/PHP FPM.

Máy chủ của tôi: 8 nhân, RAM 16GB

Tôi đã thử chơi với các cấu hình PHP FPM nhưng không cải thiện được nhiều. Để bây giờ tôi có nó trên tĩnh với 300 max_con.

Trên Apache tôi đang sử dụng sự kiện MPM với cấu hình này:

<IfModule mpm_event_module>
ServerLimit 40
    StartServers             2
    MinSpareThreads      50
    MaxSpareThreads      100
    ThreadLimit          64
    ThreadsPerChild      50
    MaxRequestWorkers     1000
    MaxConnectionsPerChild   0
</IfModule>

sử dụng hàng đầu Tôi có cái này, có vẻ tốt với tôi: nhập mô tả hình ảnh ở đây

Bất cứ ai có thể chỉ cho tôi đi đúng hướng?

lá cờ np
Bạn có sử dụng OPcache cho PHP không? Bạn cũng có thể cân nhắc chuyển sang nginx hoặc OpenLiteSpeed. Dựa trên ý kiến, nhưng chúng vẫn thường mở rộng quy mô tốt hơn nhiều cho tải cao.
lá cờ vu
Tôi không sử dụng OPCache, liệu nó có lợi ngay cả khi PHP chỉ phục vụ một API không? Tôi có mongo là DB và một lớp bộ nhớ đệm redis. Đối với nginx và OPS, tôi đang tìm kiếm một giải pháp ngắn hạn hơn là di chuyển mọi thứ. Nhưng cảm ơn vì lời đề nghị
lá cờ np
Laravel là một framework khá tiên tiến và OPCache thực sự có thể cải thiện thời gian thực thi của nó. Mức sử dụng CPU của bạn khá gần với 100% và hầu hết trong số đó được sử dụng bởi các quy trình apache, nhưng vẫn có rất nhiều công nhân php-fpm ở đó. Việc cài đặt và định cấu hình khá dễ dàng nên tôi đoán nó đáng để thử. Tôi không thấy bất kỳ sự chờ đợi i/o nào nên nút cổ chai phải nằm trong quá trình xử lý của CPU.
lá cờ vu
Sẽ thử nó sau đó! Để kiểm tra, tôi đã thử nâng cấp máy chủ lên 32 nhân và 192GB ram, cho chắc ăn. Bằng cách thay đổi một chút cấu hình, tôi đã đạt được 1500 người dùng đồng thời và sau đó trang web bắt đầu chậm lại, chỉ 30 GB được sử dụng trong tổng số 192 GB, thật kỳ lạ
lá cờ np
Thành thật mà nói, tôi không có bất kỳ kinh nghiệm nào với các công nhân MPM mới hơn của Apache, như sự kiện một. Vì vậy, sẽ không được đoán ở đây. Nhưng với các phiên bản cũ hơn và các tác phẩm khác, nó luôn chậm đối với bất kỳ tải đáng kể nào đối với tôi. Tôi đã luôn chọn nginx nếu tôi mong đợi bất kỳ tải đáng kể nào. Sau khi tôi đã thử OLS, tôi thường cố gắng gắn bó với nó. Nó có vấn đề riêng, nhưng hiệu suất khôn ngoan, nó thực sự là một phần mềm tuyệt vời. Và tôi thích nó có thể phân tích các quy tắc viết lại .htaccess kiểu apache (không may chỉ dành cho mod_rewrite, nhưng nó thường là đủ).

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.