Trước hết, phương pháp thử nghiệm của bạn không thể chứng minh kết nối tổng hợp vì mỗi cuộc gọi, một khách hàng curl được sinh ra và sau đó nó chết. Giống như những người chết không nói nhiều, một quá trình chết không thể giữ một kết nối còn sống.
Bạn có khách hàng làm phiền máy chủ proxy của bạn.
Client ====== (A) =====> ProxyServer
Hãy gọi kết nối này A. Máy chủ proxy của bạn không có gì, nó chỉ là một chương trình biểu diễn. Các máy chủ đẹp trai và chăm chỉ là rất khiêm tốn mà ông ẩn đằng sau.
Client ====== (A) =====> ProxyServer ====== (B) =====> WebServer
Ở đây, nếu tôi không sai, kết nối bảo mật là A, không phải B?
Lặp lại điểm đầu tiên của tôi, trong bài kiểm tra của bạn, bạn đang tạo một ứng dụng khách riêng cho từng yêu cầu. Mỗi khách hàng cần một kết nối riêng biệt. Kết nối là điều xảy ra giữa ít nhất hai bên. Một bên lá và kết nối bị mất.
Được rồi, chúng ta hãy quên curl ngay bây giờ và cùng nhau xem những gì chúng tôi thực sự muốn làm.
Chúng tôi muốn có SSL trên A và chúng tôi muốn Bên giao thông càng nhanh càng tốt. Với mục đích này, chúng tôi đã tách ra bên B để nó không làm cho A chậm hơn nữa, đúng không?
Kết nối tổng hợp? Không có những thứ như kết nối tổng hợp tại A. Mỗi khách hàng đến và đi làm cho rất nhiều tiếng ồn. Điều duy nhất có thể giúp bạn giảm tiếng ồn này là "Keep-Alive" có nghĩa là giữ kết nối còn sống từ một máy khách trong một khoảng thời gian ngắn để khách hàng này có thể yêu cầu các tệp khác sẽ được yêu cầu này yêu cầu . Khi chúng ta hoàn thành, chúng ta đã xong.
Đối với các kết nối trên B, các kết nối sẽ được gộp lại; nhưng điều này sẽ không mang lại cho bạn bất kỳ hiệu suất nào kể từ khi cài đặt một máy chủ, bạn không có phần này của quá trình tạo tiếng ồn.
Làm cách nào để chúng tôi giúp hệ thống này chạy nhanh hơn?
Nếu hai máy chủ này nằm trên cùng một máy, chúng ta nên loại bỏ máy chủ show-off và tiếp tục với máy chủ web chăm chỉ của chúng tôi. Nó cho biết thêm rất nhiều công việc không cần thiết cho hệ thống.
Nếu đây là những máy riêng biệt, thì bạn đang trở nên tốt đẹp với máy chủ web bằng cách lấy ít nhất là sự hấp thụ (đối với ssl) từ anh chàng tội nghiệp này. Tuy nhiên, bạn thậm chí còn đẹp hơn.
Nếu bạn muốn tiếp tục trên Apache, hãy chuyển sang mpm_worker từ mpm_prefork. Trong trường hợp có hơn 300 yêu cầu đồng thời, điều này sẽ hoạt động tốt hơn nhiều. Tôi thực sự không có ý tưởng về khả năng của phần cứng của bạn; nhưng nếu xử lý 300 yêu cầu là khó khăn, tôi tin rằng sự thay đổi nhỏ này sẽ giúp hệ thống của bạn rất nhiều.
Nếu bạn muốn có một hệ thống thậm chí còn nhẹ hơn, hãy xem nginx là một thay thế cho Apache. Nó là rất easy to setup để làm việc với PHP và nó sẽ có hiệu suất tốt hơn.
Khác với mặt trước của mọi thứ, cũng xem xét kiểm tra máy chủ cơ sở dữ liệu của bạn. Kết nối tổng hợp sẽ tạo sự khác biệt thực sự ở đây. Hãy chắc chắn rằng nếu cài đặt PHP của bạn được cấu hình để tái sử dụng các kết nối đến cơ sở dữ liệu. Ngoài ra, nếu bạn đang lưu trữ các tệp tĩnh trên cùng một hệ thống, hãy di chuyển chúng ra trên máy chủ web khác hoặc thậm chí tốt hơn bằng cách di chuyển các tệp tĩnh sang hệ thống đám mây có CDN như số S3 + CloudFront hoặc Rackspace's CloudFiles của AWS. Ngay cả khi không có CloudFront, S3 sẽ làm bạn hài lòng. Giải pháp của Rackspace đi kèm với Akamai!
Đưa ra các tệp tĩnh sẽ làm cho máy chủ web của bạn "oh chuyện gì đã xảy ra, sự im lặng này là gì? Ohhh trời!" vì bạn đã đề cập đây là một trang web và các trang web có nhiều tệp tĩnh cho mỗi trang html được tạo động hầu hết thời gian.
Tôi hy vọng bạn có thể cứu người nghèo khỏi công việc sát thủ.
Cảm ơn câu trả lời. Điều này đã giúp tôi rất nhiều để hiểu liệu kết nối tổng hợp thậm chí có thể sử dụng MPM_prefork. Quảng cáo tài liệu Apache ngay cả khi đăng nhập mod_proxy ở cấp độ gỡ lỗi không phải là rất hùng hồn về việc liệu các kết nối có được sử dụng lại hay không. Trong trường hợp của tôi, hóa ra nó không phải là Proxy ngược nhưng máy chủ phụ trợ là Vấn đề. Nó phát hiện trình duyệt là một MSIE bằng cách kiểm tra tiêu đề HTTP 'User-Agent' và do đó đóng kết nối SSL ở cuối mỗi yêu cầu. Đó là lý do tại sao proxy ngược lại không bao giờ tái sử dụng các kết nối SSL đến máy chủ phụ trợ. – BertNase
500 là của bạn, như bình luận của bạn đã giúp tôi hiểu những gì đang xảy ra, Tôi sẽ đăng câu trả lời để chỉ ra, những gì đã giải quyết các vấn đề trong trường hợp của tôi. – BertNase