<![CDATA[Latest posts for the topic "CGI, FCGI & ISAPI"]]> /hvaonline/posts/list/23.html JForum - http://www.jforum.net CGI, FCGI & ISAPI /hvaonline/posts/list/35448.html#218178 /hvaonline/posts/list/35448.html#218178 GMT CGI, FCGI & ISAPI

LlyKil wrote:
Chào mọi người. Mình đang tối ưu cho webserver sử dụng Windows Server 2003 và chạy Plesk. Webserver hỗ trợ CGI, FastCGI và ISAP. Theo mình thấy: - CGI thì web load rất chậm vì CGI chiếm nhiều tài nguyên - ISAPI quá tuyệt, nhanh nhưng lâu lâu nó phát sinh "PHP has encountered an Access Violation at 7D611952" và lỗi này mình thử search google mà vẫn chưa thấy giải pháp cho nó - FastCGI cũng nhanh không kém nhưng khi request đến server, data nó phản hồi về không phải chia ra nhiều đợt mà phải xử lý hết tất cả sau đó nó mới trả về 1 lần. Bây giờ nếu muốn nhanh thì mình phải chọn ISAPI hoặc FCGI nhưng ISAPI thì xuất hiện cái lỗi kia. Giờ chỉ còn FCGI là mình thấy ổn nhất nhưng kiểu phản hồi lại data khi mình request nó không chia ra nhiều đợt. Vậy làm sao để FCGI có thể chia ra nhiều đợt như CGI hay ISAPI. Cảm ơn mọi người. 
Tôi không hiểu ý bồ đoạn màu đỏ ở trên. "Chia ra làm nhiều đợt" là sao?]]>
/hvaonline/posts/list/35448.html#218200 /hvaonline/posts/list/35448.html#218200 GMT
CGI, FCGI & ISAPI /hvaonline/posts/list/35448.html#218297 /hvaonline/posts/list/35448.html#218297 GMT CGI, FCGI & ISAPI

LlyKil wrote:
Ví dụ đơn giản thế này, khi mình cho 1 vòng lặp echo 'abc'; khoảng 1000 lần. Khi chạy từ browser http://abc.com/abc.php chẳng hạn. Nó xử lý và trả kết quả về 1 lượt chứ không hiện kết quả theo từng lượt cho đên hết. 
Cái này là do chế độ KeepAlive trên apache và chế độ dùng absolute URL hay relative URL chớ chẳng phải do FCGI đâu. Vả lại trình duyệt bình thường và người dùng bình thường thì không có chuyện vòng lặp 1000 lần rồi.]]>
/hvaonline/posts/list/35448.html#218299 /hvaonline/posts/list/35448.html#218299 GMT
CGI, FCGI & ISAPI /hvaonline/posts/list/35448.html#218381 /hvaonline/posts/list/35448.html#218381 GMT CGI, FCGI & ISAPI

LlyKil wrote:
Bởi vì nếu mình chuyển qua CGI hay ISAPI thì nó hoạt động đúng như mình nói. Để mình minh hoạ. Ví dụ ta có 1 đoạn code sau for ($i = 1; $i <= 10; $i++) { echo $i; sleep(1); } Nếu mình chuyển sang CGI/ISAPI thì cách trả kết quả của nó như sau: Sau 1s: 1 Sau 2s: 12 Sau 3s: 123 ... Sau 10s: 12345678910 Nhưng nếu mình lại chuyển sang FCGI thì cách trả kết quả của nó: Sau 1s, 2s, 3s, ... 9s: (không có gì) Sau 10s: 12345678910  
Bồ thảy lên cấu hình cụ thể của FCGI của bồ xem?]]>
/hvaonline/posts/list/35448.html#218474 /hvaonline/posts/list/35448.html#218474 GMT
CGI, FCGI & ISAPI /hvaonline/posts/list/35448.html#219384 /hvaonline/posts/list/35448.html#219384 GMT CGI, FCGI & ISAPI

LlyKil wrote:
[Types] php:26333=Plesk_php5 php5:26333=Plesk_php5 phtml:26333=Plesk_php5 [Plesk_php5] ExePath=C:\Parallels\Plesk\Additional\PleskPHP5\php-cgi.exe Đây là cấu hình của FCGI. 
Chịu thua. Mấy thông tin này quá ít để có thể góp ý được gì.]]>
/hvaonline/posts/list/35448.html#219385 /hvaonline/posts/list/35448.html#219385 GMT
CGI, FCGI & ISAPI /hvaonline/posts/list/35448.html#219407 /hvaonline/posts/list/35448.html#219407 GMT CGI, FCGI & ISAPI

LlyKil wrote:
Thực ra vấn đề này hơi khó giải thích vì đây chỉ là chi tiết nhỏ trong cách "trả lời" request. Cụ thể thì mình đã mô tả như trên. Tuy không ảnh hưởng gì đến quá trình xử lý hay trả kết quả từ webserver về nhưng mình cũng muốn tìm hiểu. Mình chỉ thắc mắc là vì sao nếu chuyển sang CGI hay ISAPI thì không như vậy. Có lẽ đây là đặc tính/kiểu riêng của FCGI. Cảm ơn conmale đã reply cho thread này. 
Lý do nó là vì server không hơi đâu mà trả về client từng byte data mà nó phải có 1 buffer để lưu lại output từ script, khi đầy buffer nó trả về 1 lần luôn thì hiệu xuất sẽ tốt hơn nhiều so với việc cứ có byte nào thì trả về byte đó. Thông thường thì với CGI, server nó giao lại hết execution cho CGI nên gần như CGI script có data gì là server nó trả lại cho client ngay nên bạn thấy data nó ra từ từ. ISAPI thì tôi không rõ lắm, nhưng FCGI thì mặc định nó đã có cái output buffer rồi nên nó sẽ không trả về client từ byte đâu mà đợi đầy buffer (hoặc script kết thúc) nó mới trả về luôn 1 lần. Mà nhìn qua thì có vẻ như server của bạn là Win, chạy IIS? Nếu không có nhu cầu chạy ASP/.NET mà chỉ chạy PHP thôi thì sao không sử dụng Apache?]]>
/hvaonline/posts/list/35448.html#219409 /hvaonline/posts/list/35448.html#219409 GMT
CGI, FCGI & ISAPI

nbthanh wrote:

LlyKil wrote:
Thực ra vấn đề này hơi khó giải thích vì đây chỉ là chi tiết nhỏ trong cách "trả lời" request. Cụ thể thì mình đã mô tả như trên. Tuy không ảnh hưởng gì đến quá trình xử lý hay trả kết quả từ webserver về nhưng mình cũng muốn tìm hiểu. Mình chỉ thắc mắc là vì sao nếu chuyển sang CGI hay ISAPI thì không như vậy. Có lẽ đây là đặc tính/kiểu riêng của FCGI. Cảm ơn conmale đã reply cho thread này. 
Lý do nó là vì server không hơi đâu mà trả về client từng byte data mà nó phải có 1 buffer để lưu lại output từ script, khi đầy buffer nó trả về 1 lần luôn thì hiệu xuất sẽ tốt hơn nhiều so với việc cứ có byte nào thì trả về byte đó. Thông thường thì với CGI, server nó giao lại hết execution cho CGI nên gần như CGI script có data gì là server nó trả lại cho client ngay nên bạn thấy data nó ra từ từ. ISAPI thì tôi không rõ lắm, nhưng FCGI thì mặc định nó đã có cái output buffer rồi nên nó sẽ không trả về client từ byte đâu mà đợi đầy buffer (hoặc script kết thúc) nó mới trả về luôn 1 lần. Mà nhìn qua thì có vẻ như server của bạn là Win, chạy IIS? Nếu không có nhu cầu chạy ASP/.NET mà chỉ chạy PHP thôi thì sao không sử dụng Apache? 
Trước tiên mình cảm ơn bạn đã giải đáp giúp thắc mắc. *Ở trên mình đã nói mình sử dụng server Win và chạy Plesk (Plesk sử dụng IIS). Vì mình đã lỡ install Plesk nên giờ lại lười unsinstall để làm lại. Thế còn FCGI mình có thể set buffer để nó trả kết quả xử lý về từ từ được chứ?]]>
/hvaonline/posts/list/35448.html#219414 /hvaonline/posts/list/35448.html#219414 GMT
CGI, FCGI & ISAPI ResponseBufferLimit=0 vào file config của FCGI :D Cảm ơn mọi người đã quan tâm nhé.]]> /hvaonline/posts/list/35448.html#219417 /hvaonline/posts/list/35448.html#219417 GMT