Messages posted by: nbthanh

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 smilie

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.

C/C++ là ngôn ngữ lập trình.
Turbo C++, VC++... là các tool (cụ thể là IDE) để hỗ trợ cho việc lập trình bằng ngôn ngữ C/C++.

Có thể ví C/C++ là "xe máy" chung chung còn Turbo C++/VC++ là "yahama", "suzuki"...
Bạn học bằng tool gì cũng được, miễn cốt lõi là bạn phải nắm được cái cốt lõi của ngôn ngữ C/C++.

hoanghung3d wrote:

các bác ơi sai chủ đề rồi , e không nói về xu hướng công nghệ web mà e nói dịch vụ web như blog hay youtube ý. e muốn biết xu hướng dịch vụ năm 2008 va năm 2009 thôi không phải xu hướng công nghệ đâu

Vậy thì ngó bộ khó trả lời rồi. Vì nếu mà có 1 người biết được năm tới cái nào "ăn khách" thì họ đã là tỉ phú rồi bạn ơi smilie

Z0rr0 wrote:

- SOA (software as service): thay vì người dùng phải cài đặt ứng dụng trên desktop, họ có thể sử dụng trực tiếp ứng dụng từ web, ví dụ văn phòng ảo, virtual office, google office ...

SaaS mới đúng chứ hè: http://en.wikipedia.org/wiki/Software_as_a_service

Z0rr0 wrote:

- RIA (rich internet application): ứng dụng web sẽ mang tính cộng đồng (social), giàu tính năng và giao diện đẹp

RIA: ứng dụng web sẽ "gần giống" với desktop application hơn. Nhưng còn nó có mang tính cộng đồng hay không thì là 1 vấn đề khác, không dính tới RIA.

Z0rr0 wrote:

- Web và các ứng dụng của nó có thể được truy xuất phổ biến mạnh từ thiết bị cầm tay, thậm chí từ Tivi. Bên tui vừa làm xong demo 1 project web truy xuất từ Tivi tham gia triển lãm CES tại Mỹ tuần này.

Vụ này thì đúng, nhưng chỉ là không biết ở VN có phổ biến không.

quanta wrote:

Anh conmale cho em hỏi: giải pháp gửi sms đến mobile anh dùng trong trường hợp này là gì? Hiện tại em kiếm được thằng http://systembash.com/content/smssend-zabbix-clickatell. Em thử thì nó cũng gửi được nhưng... không thấy nội dung đâu cả (chỉ có "Bạn vừa nhận được một test message từ ...), còn thi thoảng lại bị:

SmsSend Error : error sending message

Alert kiểu này chắc không ổn.

Giải pháp của anh conmale chưa chắc đã thực hiện được ở VN, mà cũng có khi phải trả tiền mới được (connection string nằm trong script) nên cũng không chắc 100% là anh conmale có thể public ra được.

Hint: Đừng nhỉ kiểu đơn giản gởi SMS là phải có 1 cái SMS từ con monitor server đi đến mobile của mình với msg do mình định sẵn thì sẽ ra cách thôi smilie

Ví dụ 1: Mobifone ở Vn chẳng hạn, cho phép login vào trang web rồi send SMS --> viết 1 chương trình nho nhỏ tự động login vào trang web mobifone rồi 'submit' cái form đi.

Ví dụ 2: đăng ký 1 account yahoo đặc biệt, chẳng hạn như nick 'serverhvadown', rồi khi server hva down thiệt thì dùng nick này 'buzz' nick chính của mình 1 phát (lib để viết yahoo client thì có đầy trên mạng!). Còn nick chính của mình thì để ở chế độ "I'm on mobile" và nhớ đăng ký cái số mobile của mình với Yahoo (cách nào có thể thực hiện được ở bên chỗ anh conmale, chưa chắc được ở VN).

Ví dụ 3, ví dụ 4, v.v...và v.v... Đừng cố nghĩ theo kiểu 'sách vở' quá là ra giải pháp liền thôi smilie

Nhiều "bạn nhỏ" ping chỉ là để lấy địa chỉ IP của server!
Có lần 1 "bạn nhỏ" chat với tôi "hỏi thăm" địa chỉ IP của server, tôi trả lời "cứ ping là ra đó mà!". Một lúc sau bạn ấy quay lại nói là "ping không được'. Tôi mới hỏi lại "không được là thế nào? gởi kết quả ping lên thử?". Thế rồi kết quả như sau:
Code:

C:\>ping www.hvaonline.net
Pinging www.hvaonline.net [124.146.189.165] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 124.146.189.165:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss)

Tôi mới bảo "đấy địa chỉ IP đấy 124.xxx.xx.xxx". Thế rồi nhận được câu trả lời "nhưng nó có ping được đâu smilie

anh cứ giấu nghề mãi!". Tiếp theo là 1 lô một lốc giận hơn năn nỉ ỉ ôi nào là giấu nghề rồi nào là "anh khinh em newbie'' rồi đủ thứ hầm bà lắng khác nữa. Giận quá...block nick luôn smilie

Cái này thì tôi đồng ý với beatboxvn. Một lỗi dù là nhỏ nhặt về mặt kỹ thuật nhưng dẫn đến sự thất thoát các thông tin nhạy cảm của khách hàng thì nó phải được chú ý xem xét một cách nghiêm túc.
Lỗi này nó còn nguy hại ở chỗ là vì màn hình DTDD nó nhỏ, nên nhìn vào phần address chỉ thấy được khúc đầu, tức là phần xxx.google.com --> user càng dễ chết.

K4i wrote:

60487 wrote:

Chào mọi người!
1. Có ai làm web theo kiểu hướng đối tượng trong PHP không? Nếu biết thì xin chỉ giúp cho mình trong PHP làm thế nào để sử dụng một biến kiểu đối tượng (như Java).

Một câu hỏi thông minh: MVC là cái gì, Web 3-tier là cái gì rồi hãy nghĩ đến việc làm web theo kiểu hướng đối tượng

Ngược lại mới đúng! Nắm vững OOP (học bò) đã rồi hãy lo tiếp tới mấy cái khác (học chạy)!

Chưa xài Mantis nhưng BugZilla khá tốt.

Swap không bắt buộc (must) phải có nhưng nên có. Vì nếu không có swap space, khi system bị run out of physical memory thì nó sẽ crash hoặc treo ==> ai muốn điều này xảy ra nhỉ smilie

BachDuongTM wrote:

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ố .

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

BachDuongTM wrote:

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,...

Build static hay build dynamic gì thì module cũng chỉ được load 1 lần, chỉ có khác là load trước, hoặc load sau (on-demand/lazy) mà thôi.

BachDuongTM wrote:

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.

Điều này hoàn toàn sai! Apache lúc nào nó cũng phải "phân loại" request như bạn nói, khi thấy 1 request được đăng ký handle bởi 1 module nào đó thì Apache sẽ chuyển sang cho module đó xử lý. Nếu mà module đó là build dynamic thì ở cái request đầu tiên Apache sẽ load cái module đó lên; còn lại từ request thứ 2 trở về sau thì static hay dynamic cũng thế.
Và đây là cơ chế hoạt động của Apache, áp dụng chung cho các module chứ không riêng gì PHP module!

BachDuongTM wrote:

...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....

Tại sao lại dính gì tới chuyện khởi tạo lại Apache process nhỉ? 1 năm, 1 tháng, 1 tuần hay 1 ngày bạn restart/reload lại Apache mấy lần?

BachDuongTM wrote:

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ý.

Không hiểu bạn nói gì luôn. Câu trước thì tự nhiên bạn bắt "khởi tạo lại Apache process", trong khi ở điều kiện ổn định có khi cả tháng Apache mới phải restart lại 1 lần. Vậy giờ tôi cũng bắt "khởi tạo lại FastCGI" thì bạn nghĩ sao?

Và cuối cùng, đề nghị bạn đừng nên lôi topic đi lung tung 1 cách không cần thiết như thế. Nếu bạn chưa nắm được topic đang bàn về vấn đề gì...bạn nên vui lòng đọc lại trang 1, quanta đã có nói rõ là topic này đang bàn về vấn đề gì.
Ở đây chúng ta đang nói về cách biên dịch & sử dụng PHP:
- Module (static, dynamic)
- CGI
- FastCGI

Các web server thông dụng đều hỗ trợ cả 3 "cách" trên cả. Apache là 1 web server thông dụng (nếu không muốn nói là thông dụng nhất) nên được lấy ra làm ví dụ. Bạn đi lôi lighttpd ra nữa thì không có ý nghĩa gì cả vì ở đây chúng ta chỉ bàn về:
Module vs CGI vs FastCGI
chứ không phải đang bàn về
Module+Web Server X vs CGI+Web Server Y vs FastCGI+Web Server Z
Qui chung về 1 webserver nào đó thì mới có cơ sở để mà thảo luận so sánh.

BachDuongTM wrote:

- 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.

1. Module chỉ phải load 1 lần chứ không phải mỗi khi có request là load module!
2. Process được tạo sẵn để chờ request thì thread của module không thể được tạo sẵn để chờ request hay sao?
3. Truyền dữ liệu qua lại giữa 2 process, chưa kể cộng thêm cơ chế nếu phải chuyển user id từ apache sang user id của mỗi process thì lại nhanh hơn việc truyền dữ liệu giữa 2 thread trong cùng 1 process?
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 smilie

gõ nguyên dòng lệnh /etc/init.d/httpd start
hoặc nếu đã đang đứng ở thư mục /etc/init.d rồi thì gõ ./httpd start

Mà cái AccessFlieName nó cần 1 tham số sao bạn không có gì hết vậy?

BachDuongTM wrote:

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.

CGI mode thì mỗi khi có request Apache phải chạy external application (=process) để sử lý cái request đó. Như vậy thì Apache dù có hoạt động mở mô hình nào đi nữa thì:
PHP cài ở dạng Apache module, mỗi khi có requess thì: Apache[proc/thread/hibrid]
PHP cài ở dạng CGI, mỗi khi có requess thì: Apache[proc/thread/hibrid] + 1 external process

Như vậy thì lúc nào cài kiểu module cũng lightweight hơn kiểu CGI. Và các external process này rõ ràng là start/stop liên tục theo mỗi request.
FastCGI thì số lượng external process có giảm thiểu, nhưng vẫn không tránh khỏi.

BachDuongTM wrote:

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.

Process "nặng" hơn thread bao nhiêu bạn có biết?
Mà bạn nghĩ rằng 4g-16Gb là lớn lắm sao? Con laptop cùi ghẻ bạn tôi dùng cũng đã có 4Gb RAM rồi. Con server đặt trong góc phòng ở cty tôi số RAM của nó cũng lớn hơn con số 16Gb nhiều lắm, mà chưa ai trong cty tôi dám nói là "RAM không là yếu tố đắt đỏ" cả.

BachDuongTM wrote:

* 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

Với 1 giải pháp lightweight hơn thì giả sử 1 sec server handle được 1000 request.
Với 1 giải pháp nặng nề hơn thì giả sử 1 sec server handle được 500 request.

Như vậy nếu muốn DOS đạng làm tăng server load/làm hết resource ở server/etc thì kẻ tấn công phải tốn sức gấp đôi chứ nhỉ smilie

quanta wrote:

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

Rõ hơn rồi đây smilie

Static module và Dynamic module không khác nhau là mấy trên phương diện sử dụng, chỉ khác nhau nhiều ở phần "cài đặt".

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 smilie

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 smilie

- 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è".

* 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 smilie

). Tuy nhiên, nếu script viết không tốt, hoặc kẻ tấn công bằng cách nào đó làm "treo" PHP thread thì có thể sẽ làm treo nguyên cả Apache. Nhưng đây cũng không phải là vấn đề...lớn lắm vì nếu nguyên site toàn là PHP, thì nếu kẻ tấn công không làm Apache chết, nhưng làm toàn bộ PHP script của bạn chết thì site của bạn cũng đâu có phục vụ user được chi.

Về cách cài đặt: cái này thì ngay trong PHP Manual cũng có chỉ rõ rồi smilie

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 smilie

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.

Báo nào mà lá cải thế?

Nếu bạn xài ADSL chẳng hạn thì IP do ISP cung cấp nằm ở ADSL modem chứ nó có nằm ở trên máy bạn đâu mà gõ ipconfig làm chi.
Có chăng là bạn tắt modem rồi mở lại thì có khi có được IP khác.

cuongbk wrote:

Mình nghĩ MySQL và MSSQL có lẽ là ko quan trọng, cái quan trọng là cách kết nối nó thế nào thôi, nhưng đến giờ vẫn chưa kết nối được, không hiểu tại sao??

2 hệ CSDL khác nhau, các hàm kết nối và thông số kết nối cũng khác nhau.
Mấy cái đó bạn không cho là quan trọng vậy thì cái gì bạn mới cho là quan trọng?

Tùy vào bản MSSQL mà bạn đang cài, nếu là bản express thì $server phải là '192.168.1.68\SQLExpress'

seraphpl wrote:

Mà kì lạ, sao bản Zip nhẹ hơn mà đầy đủ extention hơn (có sẵn php_mysql.dll, libmysql.dll....), không bị mấy cái lỗi này. Còn bản .msi thì nặng hơn gấp đôi vậy mà sao không đầy đủ extension và bị lỗi lung tung?
Nếu zip gọn và đầy đủ hơn thì người ta để bản .msi làm chi nhỉ?

Bản MSI là bản "installer", ngoài bản thân PHP nó còn chứa cái chương trình installer (được đóng gói dạng MSI).
Còn bản ZIP chỉ chứa 1 mình PHP, và bạn download về rồi phải tự unzip và cấu hình bằng tay smilie

Nó báo lỗi rõ ràng mà:
- file php_mbstring.dll thì là thư viện của PHP nên bạn copy vào thư mục ext là đúng
- còn cái libmysql.dll thì đâu phải! Cái này thì bạn có thể copy vào: cùng thư mục vớ với file php.exe, hoặc bỏ vào system32

ISP thì có thể họ tính dung lượng cách khác, vì bạn đâu có download trực tiếp từ host của bạn, mà bạn vào internet (download/upload từ site khác) thông qua họ.

ken_shin wrote:

nói vậy thì chỉ có nước chạy ra cho mấy đứa bán host chửi nó 1 trân cho bõ tức ( không biết có chửi lại nó ko hay bị nó chgửi) thiệt tình làm ăn gì mà gian lân không hà.đúng là dan vn .

Host nào chả vậy chứ riêng gì VN hay nước ngoài. Mà host VN thì chương trình quản lý băng thông cũng là của nước ngoài mà smilie

Cách tính dựa trên response từ header là tương đối chính xác nhanh và đỡ mất công tính toán nhất.
Với lại trong đa số trường hợp, 1 file HTML hay GIF vài chục Kb trở lại thì client chưa kịp "ngắt" là toàn bộ nội dung file đã bay ra khỏi server rồi.
Còn nếu bạn host file tới 400Mb mà bị "rút ruột" kiểu này thì ráng chịu vậy, thiểu số phải theo đa số chứ smilie

ken_shin wrote:

thank cái này mới trước giờ không biết.hình như hơi hiểu rùi.
nhưng nghĩ lại thì nếu sever bắt đầu response là tính băng thông . dù client nó cứ request và từ chối không nhận response
thì sever vẫn mất băng thông trên đường đi (mình ở vn chơi đứa nào bên us chắc hiệu quả lém vì đường xa) nhưng với 1 file 400mb thì làm sao hao hết trên đường đi được mình nghĩ cùng lắm là vài mb (chắc không tới đâu).nếu cứ mỗi request mà mất 400mb thì hóa ra bên quản lý host họ ăn gian băng thông của khách hàng rùi.

Bạn download file trên internet bạn có để ý thấy là file chưa load xong nhưng ở client biết được dung lượng file là bao nhiêu để tính giờ download?
Lý do là vì trong phần header của response từ server nó có thông tin file size. Như vậy, nếu host dựa vào thông số này để tính băng thông thì thế nào? Host nó phải tính cái nào có lợi cho nó chứ. Còn chuyện client request nhưng chỉ đọc xong header rồi ngắt thì...bạn ráng chịu à smilie