Tôi chưa có điểm chuẩn nhưng tôi có thể khai thác một số trong số chúng nếu bạn muốn. Apache Worker + FPM chắc chắn nhanh hơn khi sử dụng một số tập lệnh PHP đơn giản để kiểm tra. Điều kỳ lạ là chúng tôi không nhận thấy sự gia tăng tốc độ như vậy khi đo điểm chuẩn cho một ứng dụng dựa trên Zend Framework, nhưng điều đó có thể là do sự kỳ quặc của ứng dụng hơn là bất kỳ điều gì khác [cần nhiều công việc/điều tra hơn ở đây. ]
Hy vọng điều này là hữu ích
Giacôbê
chưa đọc
Theo kinh nghiệm của chúng tôi, nếu bạn muốn phân phối bất kỳ loại ứng dụng PHP nào có
quốc tế hóa bằng cách sử dụng hệ thống gettext GNU phổ biến [và ngay
hiện tại có .
engine since GNU gettext library is not yet thread-safe [because GNU
gettext process environment variables can be set by any thread which
will drive the underlying GNU gettext library and these would affect
every thread in the process].
Nếu bạn không quan tâm đến việc quốc tế hóa hoặc sử dụng hệ thống
phổ biến nhất để dịch, GNU gettext, thì bạn có thể chọn bất kỳ loại công cụ
máy chủ web nào .
Cá nhân tôi sẽ không bao giờ chạy động cơ có ren trong sản xuất.
Các vấn đề ô nhiễm chéo là khó theo dõi nhất.
Và tôi muốn có sự cách ly hoàn toàn giữa các kết nối, điều này giúp
việc theo dõi sự cố trở nên đơn giản hơn nhiều. Cho đến nay, sự khác biệt rất nhỏ về
hiệu suất bị lấn át bởi hiệu quả cách ly và gỡ lỗi
có được khi sử dụng công cụ máy chủ web không phân luồng.
-Gerry
Chào mọi người,
Tôi có một vài câu hỏi về hiệu suất của các ứng dụng web PHP trong
tải và tôi sẽ đánh giá cao nếu có bất kỳ ai muốn chia sẻ
.Thông tin lai lịch
Trong các môi trường đa quy trình, chẳng hạn như FastCGI, Apache Prefork MPM, v.v., PHP
cần thực thi các hàm MINIT và MSHUTDOWN cho tất cả các tiện ích mở rộng đã tải
on every request.Trong môi trường đa luồng, chẳng hạn như Apache Worker MPM, với Zend Thread
An toàn được bật,
PHP chỉ cần thực thi MINIT và .
extension and not each time a new thread is created to serve a request.Tạo quy trình mới cũng tốn kém hơn so với tạo
luồng mới.Trong so sánh trực tiếp giữa các tập lệnh chỉ được thực thi một lần ở chế độ ZTS và
các tập lệnh được thực hiện một lần ở chế độ không phải ZTS,
Tôi nhận thấy .
be the main reason why most people go with the non-ZTS enabled setups.
Nhưng lý do cho sự khác biệt nhỏ về tốc độ này là do
sự khác biệt trong cấu trúc dữ liệu đối với toàn cầu đối với chế độ ZTS và không phải ZTS.Các lý do khác mà mọi người viện dẫn để sử dụng thiết lập không theo luồng bao gồm
tính ổn định mà tôi đoán chúng ta không nên thực sự lo lắng nếu
không theo luồng .Vì việc tạo quy trình mới thường tốn kém hơn so với tạo
luồng mới, tôi tin rằng dưới tải cao, php ở chế độ ZTS [đa luồng
environment] will perform better than an identical setup in NTS mode
[multi-process].Vấn đề
Tôi nhận thấy rằng Zend Server đang sử dụng PHP ở chế độ FastCGI [NTS đa xử lý]
và tôi đang dự tính thiết lập apache ở chế độ worker [chế độ luồng] và
compiling php in ZTS mode instead.Có ai đã thực hiện bất kỳ điểm chuẩn kiểm tra tải nào so sánh hai thiết lập
[Đa quy trình so với Đa luồng] không?Có tiện ích mở rộng PHP nào gây ra sự cố trong môi trường luồng mà tôi
nên tránh không?Có bất kỳ thông tin nội bộ nào hoặc bất kỳ lý do nào khác khiến tôi nên chọn
ZTS thay vì NTS hoặc ngược lại không?Bất kỳ thông tin phản hồi hữu ích sẽ được đánh giá cao
Cảm ơn
chưa đọc Xin chào, Đối với các ứng dụng đa luồng trong sản xuất, toàn bộ java land chạy Trân trọng, Theo kinh nghiệm của chúng tôi, nếu bạn muốn phân phối bất kỳ loại ứng dụng PHP nào có
Tôi đã dành rất nhiều thời gian vào năm ngoái để đo lường hiệu suất của php trên
fastcgi đa luồng so với một luồng.
Tôi đã sử dụng máy chủ web iplanet [thay vì apache] để đo lường. Trong số
các ứng dụng php đơn luồng rất gần [tốt hơn] so với các phiên bản
đa luồng nhưng khi chúng tôi bắt đầu tối ưu hóa php cho môi trường đa luồng,< . Có rất nhiều phạm vi cải thiện đa luồng
overall results were extremely positive [>35% faster than single threaded php
for an ecommerce apps]. There is a lot of scope of improving multi-threaded
php. Một số lĩnh vực chúng tôi đã xem xét là.
khi xử lý yêu cầu.
bên trong các máy chủ đa luồng và chạy rất tốt. Tuy nhiên, php chưa bao giờ
được tối ưu hóa cho các máy chủ web đa luồng nên nó chạy đẹp hơn rất nhiều trong
môi trường fastcgi đơn luồng.
Basant.
quốc tế hóa bằng cách sử dụng hệ thống gettext GNU phổ biến [và ngay
hiện tại có .
engine since GNU gettext library is not yet thread-safe [because GNU
gettext process environment variables can be set by any thread which
will drive the underlying GNU gettext library and these would affect
every thread in the process].
Nếu bạn không quan tâm đến việc quốc tế hóa hoặc sử dụng hệ thống
phổ biến nhất để dịch, GNU gettext, thì bạn có thể chọn bất kỳ loại công cụ
máy chủ web nào .
Cá nhân tôi sẽ không bao giờ chạy động cơ có ren trong sản xuất.
Các vấn đề ô nhiễm chéo là khó theo dõi nhất.
Và tôi muốn có sự cách ly hoàn toàn giữa các kết nối, điều này giúp
việc theo dõi sự cố trở nên đơn giản hơn nhiều. Cho đến nay, sự khác biệt rất nhỏ về
hiệu suất bị lấn át bởi hiệu quả cách ly và gỡ lỗi
có được khi sử dụng công cụ máy chủ web không phân luồng.
-Gerry
Chào mọi người,
Tôi có một vài câu hỏi về hiệu suất của các ứng dụng web PHP trong
tải và tôi sẽ đánh giá cao nếu có bất kỳ ai muốn chia sẻ
.Thông tin lai lịch
Trong các môi trường đa quy trình, chẳng hạn như FastCGI, Apache Prefork MPM, v.v., PHP
cần thực thi các hàm MINIT và MSHUTDOWN cho tất cả các tiện ích mở rộng đã tải
on every request.Trong môi trường đa luồng, chẳng hạn như Apache Worker MPM, với Zend Thread
An toàn được bật,
PHP chỉ cần thực thi MINIT và .
extension and not each time a new thread is created to serve a request.Tạo quy trình mới cũng tốn kém hơn so với tạo
luồng mới.Trong so sánh trực tiếp giữa các tập lệnh chỉ được thực thi một lần ở chế độ ZTS và
các tập lệnh được thực hiện một lần ở chế độ không phải ZTS,
Tôi nhận thấy .
be the main reason why most people go with the non-ZTS enabled setups.
Nhưng lý do cho sự khác biệt nhỏ về tốc độ này là do
sự khác biệt trong cấu trúc dữ liệu đối với toàn cầu đối với chế độ ZTS và không phải ZTS.Các lý do khác mà mọi người viện dẫn để sử dụng thiết lập không theo luồng bao gồm
tính ổn định mà tôi đoán chúng ta không nên thực sự lo lắng nếu
không theo luồng .Vì việc tạo quy trình mới thường tốn kém hơn so với tạo
luồng mới, tôi tin rằng dưới tải cao, php ở chế độ ZTS [đa luồng
environment] will perform better than an identical setup in NTS mode
[multi-process].Vấn đề
Tôi nhận thấy rằng Zend Server đang sử dụng PHP ở chế độ FastCGI [NTS đa xử lý]
và tôi đang dự tính thiết lập apache ở chế độ worker [chế độ luồng] và
compiling php in ZTS mode instead.Có ai đã thực hiện bất kỳ điểm chuẩn kiểm tra tải nào so sánh hai thiết lập
[Đa quy trình so với Đa luồng] không?Có tiện ích mở rộng PHP nào gây ra sự cố trong môi trường luồng mà tôi
nên tránh không?Có bất kỳ thông tin nội bộ nào hoặc bất kỳ lý do nào khác khiến tôi nên chọn
ZTS thay vì NTS hoặc ngược lại không?Bất kỳ thông tin phản hồi hữu ích sẽ được đánh giá cao
Cảm ơn
chưa đọc
"Israel Ekpo" israelekpo@gmail. com đã viết trong tin nhắn
tin tức. AANLkTi=ixWQkKovKYuLuQckDvkLQY2nYEyG6PJfZAn-G@mail. gmail. com.
Trong các môi trường đa quy trình, chẳng hạn như FastCGI, Apache Prefork MPM, v.v.,
PHP
cần thực thi các hàm MINIT và MSHUTDOWN cho tất cả các lần tải .
extensions
on every request.
Bạn nói không đúng ở đây. Một quy trình có thể xử lý khá nhiều yêu cầu và
MINIT/MSHUTDOWN chỉ được thực thi một lần.
Vì vậy, chi phí MINIT/MSHUTDOWN không thể bỏ qua.
Tạo quy trình mới cũng tốn kém hơn so với tạo
luồng mới.
Đúng, nhưng hiếm khi cần tạo chúng trong cả hai trường hợp. Vì vậy, chi phí
sáng tạo hầu như không đóng vai trò gì.
Điều đóng vai trò là chuyển ngữ cảnh khi một số yêu cầu chồng chéo được
xử lý. Với chủ đề nó ít tốn kém hơn.
Tuy nhiên, việc chuyển đổi vẫn là một chi phí lớn khi bạn chạy một máy chủ có 1K hoặc 10K
các yêu cầu chồng chéo.
Nếu bạn nói về 10 hay 40 - hầu như không có sự khác biệt.
Trong so sánh trực tiếp giữa các tập lệnh chỉ được thực thi một lần ở chế độ ZTS
và
các tập lệnh được thực thi một lần ở chế độ không phải ZTS,