- Có những cách nào khi biên dịch PHP? (Ở đây, tiêu chí mà tôi muốn nói đến là: cách thức hoạt động của PHP sau khi cài xong, chứ không phải là chia theo kiểu: cài từ source, cài từ binary) 

Mình đã từng cài PHP theo vài lối mòn sau : - PHP theo dạng modun, được webservice gọi đến để dịch mã .php , có thể kể đến như .so của apache, hoặc .dll bên IIS window.  

quanta wrote:

- Có những cách nào khi biên dịch PHP? (Ở đây, tiêu chí mà tôi muốn nói đến là: cách thức hoạt động của PHP sau khi cài xong, chứ không phải là chia theo kiểu: cài từ source, cài từ binary) 

Bùng nhùng quá không hiểu gì hết :D Mới vô thì hỏi về "cách biên dịch", sau thì lại "cách hoạt động", rồi câu sau lại là "cách cài đặt"...híc...example 1 phát cho rõ đi nào. 

- PHP dạng thực thi CGI hoặc FastCGI, không thực sự hiểu sâu về nó, nhưng nôm na là PHP hoạt động ở dạng thực thi,tự chạy tiến trình để dịch mã .php và có các cơ chế khác nhau để trả ngược kết quả về webservice  

- PHP theo dạng modun, được webservice gọi đến để dịch mã .php , có thể kể đến như .so của apache, hoặc .dll bên IIS window.  

Xét về bảo mật, mình coi phân quyền cấp OS là cao nhất, cụ thể ở mức tiến trình và quyền truy cập file <có gì sai tên gọi chăng> vì thế mình hay sử dụng cách thứ 2 hơn, tiến trình apache và php được triệu gọi riêng biệt, các mã .php được php xử lý còn file static thì apache trả lời luôn. Hơn nữa do được khởi tạo sãn nên cách này có vẻ hiệu quả và bền bỉ hơn việc cứ mỗi request đến lại một lần triệu gọi và nạp php vào bộ nhớ. Hơn nữa, tiến trình PHP được spawn với ID riêng biệt nên có thể giới hạn vùng truy cập và tránh làm ảnh hưởng giữa các site với nhau.  

BachDuongTM wrote:

- PHP theo dạng modun, được webservice gọi đến để dịch mã .php , có thể kể đến như .so của apache, hoặc .dll bên IIS window.  

Về phương diện bảo mật, việc config Apache và php theo mình nghĩ mới là quan trọng, hơn nữa trong quá trình cài đặt, nhưng vấn đề về bảo mật cho apache *nếu được ngó tới* cộng với việc chú ý php, thì ở mức modile và ứng dụng không khác là mấy. :P  

Vì thế này nên request mới được xử lí chậm hơn chứ, việc khởi tạo một module của một ứng dụng với việc khởi tạo riêng một ứng dụng thì mình nghĩ về trước làm hao phí tài nguyên server ít hơn :*-  

Bảo mật là bài toán vô cùng, cá nhân mình chú trọng mức thấp nhất là OS cụ thể ở mức tiến trình và quyền truy cập file, giả định apache hoặc php bi bug thì hệ thống ít bị phá hoại nhất có thể. 

OK bác, ý tôi muốn chia như sau: - PHP được cài như một CGI interpreter - PHP được cài dưới dạng module của Apache: trong này lại chia thành static module và dynamic module 

Về bảo mật: chia ra làm 2 trường hợp * Shared hosting: - module: quên chuyện bảo mật với nó đi ;-) - CGI: bảo mật tốt hơn, nhưng vì dạng CGI khá "nặng", cho dù là với FCGI-like cho nên với các shared hosting "rẻ tiền" thì CGI không được ưa chuộng lắm vì chẳng mấy chốc là nó làm server "sụm bà chè". 

smilie Đó là sự khác biệt giữa đọc tài liệu và test thực tế. Có nhiểu recommed khác nhau và recomend của mình là đừng vội tin thằng nào hết <theo logic là gồm cả mình > :-O :-O :D  

Cảm ơn các bác đã thảo luận :). Em có 1 thắc mắc nhỏ từ câu hỏi của quanta mà chưa ai trả lời, đó là "có công cụ nào để kiểm chứng?". Mỗi phương pháp biên dịch PHP đều có ưu điểm và nhược điểm theo như BachDuongTM, nbthanh và Mr.Bi phân tích. Vậy có cách nào để có thể "quan sát" được mức độ ảnh hưởng của từng yếu tố đến 2 vấn đề là hiệu suất và bảo mật của webserver ko? 

Về performance: module > CGI-like Cụ thể hơn thì module = thread, CGI = process; thread thì light-weight hơn process cái đó rõ rồi. Còn cụ thể như thế nào thì lại...tùy vào OS :-) 

Cái này còn phải xem lại àh nha. Khi nói php là modun thì được hiểu là nó là một thành phần của web service, còn việc web service chạy theo kiểu nào thì còn xem xét tiếp. Apache có thể chạy theo kiểu proc , theard hoặc hybird đó nha. Nói rằng thread chạy nhanh hơn process chỉ đúng với điều kiện process đó shutdown và start liên tục, nếu process đó không bị kill mà ở trạng thái idle đợi request thì cũng chưa bít đâu. 

Về bảo mật: chia ra làm 2 trường hợp * Shared hosting: - module: quên chuyện bảo mật với nó đi ;-) - CGI: bảo mật tốt hơn, nhưng vì dạng CGI khá "nặng", cho dù là với FCGI-like cho nên với các shared hosting "rẻ tiền" thì CGI không được ưa chuộng lắm vì chẳng mấy chốc là nó làm server "sụm bà chè". 

Sure, CGI nặng hơn , tuy nhiên nặng về RAM và hiện tại RAM không hẳn là yếu tố đắt đỏ với 1 server 4g- 8g- 16g .Server sụm chủ yếu do hightload hoặc giới hạn về số request xử lý thôi. 

* Dedicated hosting: Module lightweight hơn CGI-like nhiều, nên tôi thì sẽ luôn chọn dạng module (ít ra cũng...chống DOS tốt hơn ;-) ). Cái này thì nghĩ cả ngày cũng không ra nó liên quan gì đến DOS, khổ chủ vào giải thích xíu 

Lỗi của mình rất là to lớn , đó là việc đang bàn xem php ở dạng module với CGI thì lại đâm ngang apache, và thế là mỗi người một ý sai lệch. Và vì nó lệch nên mình cũng bàn xéo một tý nhé - Với apache : chạy theo kiểu CGI sẽ nặng hơn , điều này hoàn toàn đúng, nhưng chỉ đúng với apache thôi, chính xác hơn là đúng với cơ chế xử lý hiện tại của apache. Mình đang bàn về web service mà, ngoài apache còn một số khác nữa chứ.  

............. Vấn đề là tại thời điểm hiện tại, nút thắt của một máy chủ web thông dụng và đơn lẻ nằm ở ổ cứng chứ không phải là RAM hay CPU nữa.Vì thế nếu nói về biên dịch php để tiết kiệm RAM hoặc biên dịch PHP hoạt động thế nào đó tốn ram hơn thì vấn đề đó không phải là quá quan trọng,mà quan trọng là khả năng đáp ứng chung .  

Đó là sự khác biệt giữa đọc tài liệu và test thực tế ... Server sụm chủ yếu do hightload hoặc giới hạn về số request xử lý thôi.  

Vấn đề là tại thời điểm hiện tại, nút thắt của một máy chủ web thông dụng và đơn lẻ nằm ở ổ cứng chứ không phải là RAM hay CPU nữa. 

learn2hack wrote:

Cảm ơn các bác đã thảo luận :). Em có 1 thắc mắc nhỏ từ câu hỏi của quanta mà chưa ai trả lời, đó là "có công cụ nào để kiểm chứng?". Mỗi phương pháp biên dịch PHP đều có ưu điểm và nhược điểm theo như BachDuongTM, nbthanh và Mr.Bi phân tích. Vậy có cách nào để có thể "quan sát" được mức độ ảnh hưởng của từng yếu tố đến 2 vấn đề là hiệu suất và bảo mật của webserver ko? 

Về hiệu suất, l2h có thể dùng 'món' này: http://httpd.apache.org/docs/2.0/programs/ab.html 

quanta wrote:

Về hiệu suất, l2h có thể dùng 'món' này: http://httpd.apache.org/docs/2.0/programs/ab.html 

có món nào ngon hơn ko? ví dụ như trong win thì có WAPT: tạo kịch bản, chỉ định những trang nào sẽ test? bao nhiêu user sẽ phi vào? bao nhiêu request? 

- Trong các mô hình khác, một trong số mình cài đặt là sử dụng lighttpd + php , khi đó quá trình khởi tạo php được tiến hành ban đầu, các tiến trình php đựoc khởi tạo và ở trạng thái chờ. Ứng với mỗi request, lighttpd không gọi modun php mà chuyển giao trực tiếp qua socket đến tiến trình php đang đợi sẵn. Và vì không cần thêm các quá trình trung gian nữa, nên thời gian đáp ứng request của PHP nhanh hơn 20% so với kiểu load modun apache. 

4. PHP chạy trên lighttpd như bạn nói là ở mode FastCGI. Apache HTTPD cũng hỗ trợ FastCGI, tuy nhiên với cài đặt mặc định thì thường lighttpd + FastCGI nhanh hơn Apache + FastCGI vì lighttpd nói chung là lightweight hơn Apache. Nhưng bạn cũng thấy đây là vấn đề của webserver + FastCGI, đâu có dính gì nhiều tới PHP ;-) 

1. Module chỉ phải load 1 lần chứ không phải mỗi khi có request là load module! 

Nếu php được build static với apache thì điều này thậm chí là không còn, tuy nhiên thời gian để khởi tạo thành công 1 process lại lâu hơn. Còn nếu ở dạng modun động, apache cần time để phân loại request rồi mới quyết định có gọi php modun hay không. Sau khi đã load ổn, thì tiến trình đó sẽ vẫn tiếp tục hoạt động tốt, tuy nhiên nếu phải khởi tạo lại apache process thì quá trình trên lại lặp lại.Và vì thế, việc nạp hay không nạp vẫn luôn làm thời gian tiêu tốn nhiều hơn là việc khởi tạo sẵn tiến trình và chờ đợi request xử lý.

4. PHP chạy trên lighttpd như bạn nói là ở mode FastCGI. Apache HTTPD cũng hỗ trợ FastCGI, tuy nhiên với cài đặt mặc định thì thường lighttpd + FastCGI nhanh hơn Apache + FastCGI vì lighttpd nói chung là lightweight hơn Apache. Nhưng bạn cũng thấy đây là vấn đề của webserver + FastCGI, đâu có dính gì nhiều tới PHP ;-) 

Nếu tính PHP chỉ là thời gian từ khi php biên dịch đến khi biên dịch xong, thì mình không có thông tin gì về time giữa modun và cgi, chắc là như nhau. Suy cho cùng, vậy topic có kết luận gì về các cách biên dịch php. Thời gian chỉ là 1 trong số nhiều yếu tố . 

1. Module chỉ phải load 1 lần chứ không phải mỗi khi có request là load module! 

Nếu php được build static với apache thì điều này thậm chí là không còn,... 

Còn nếu ở dạng modun động, apache cần time để phân loại request rồi mới quyết định có gọi php modun hay không. 

...tuy nhiên nếu phải khởi tạo lại apache process thì quá trình trên lại lặp lại.... 

Và vì thế, việc nạp hay không nạp vẫn luôn làm thời gian tiêu tốn nhiều hơn là việc khởi tạo sẵn tiến trình và chờ đợi request xử lý. 

Nếu tính PHP chỉ là thời gian từ khi php biên dịch đến khi biên dịch xong, thì mình không có thông tin gì về time giữa modun và cgi, chắc là như nhau. Suy cho cùng, vậy topic có kết luận gì về các cách biên dịch php. Thời gian chỉ là 1 trong số nhiều yếu tố . 

Nếu không có thông tin gì về thời gian xử lí cũng như performance của 2 cách biên dịch php trên, bạn có thể đi một vòng google và kiểm chứng, mình chắc là có rất nhiều người có dư kinh nghiệm hơn cả bạn và mình rất nhiều cũng viết ra những bài tương tự như so sánh 2 cách biên dịch trên từ rất lâu, nhưng với tất cả những gì mọi người nói ra ở trên thực sự chưa đủ cho bạn thấy là bạn đã sai hay sao? 

Tôi đề nghị bạn nên nghiên túc xem xét lại...kiến thức của mình!  

<?php
echo "Hello world!\n";
echo $a;
echo "Goodbye!\n";
?>

Hello world! PHP Notice: Undefined variable: a in test1.php on line 3 Goodbye! 

<?php
echo "Hello world!\n";
no_defined_func();
echo "Goodbye!\";
?>

Hello world! PHP Fatal error: Call to undefined function no_defined_func() in test2.php on line 3 

<?php
echo "Hello world!\n";
no_defined_func(();
echo "Goodbye!\n";
?>

PHP Parse error: syntax error, unexpected ')' in test3.php on line 3 

Phải chăng đó là các cách biên dịch của PHP mà bạn muốn đề cập tới? 

myquartz wrote:

Phải chăng đó là các cách biên dịch của PHP mà bạn muốn đề cập tới? 

Có lẽ là...không :-) Topic đang bàn về vấn đề "compile php (engine) trên Linux" thì đúng hơn chứ hoàn toàn không nói đến vấn đề 1 PHP script được thực thi như thế nào. 

việc build LAMP, tức là build Apache+PHP,