[Question] lighttpd hay nginx |
15/05/2009 04:13:26 (+0700) | #1 | 180596 |
kimkhue
Member
|
0 |
|
|
Joined: 07/05/2009 00:11:52
Messages: 10
Offline
|
|
Mình đang chạy 1 site up ảnh trên d.server và thời gian gần đây đang phát triển tốt , và mình nhận thấy apache không còn phù hợp với server của mình nữa nên mình đang phân vân ko biết nên chuyển sang highttpd hay nginx lúc này.
Site của mình dùng code của Mihalism http://www.my-image-host.com/ |
|
|
|
|
[Question] highttpd hay nginx |
15/05/2009 05:13:57 (+0700) | #2 | 180607 |
|
azteam
Member
|
0 |
|
|
Joined: 17/03/2007 21:12:46
Messages: 177
Location: /dev/null
Offline
|
|
kimkhue wrote:
Mình đang chạy 1 site up ảnh trên d.server và thời gian gần đây đang phát triển tốt , và mình nhận thấy apache không còn phù hợp với server của mình nữa nên mình đang phân vân ko biết nên chuyển sang highttpd hay nginx lúc này.
Site của mình dùng code của Mihalism http://www.my-image-host.com/
Không biết highttpd bạn nói đến là webserver gì? |
|
|
|
|
[Question] Re: highttpd hay nginx |
15/05/2009 05:14:44 (+0700) | #3 | 180608 |
kimkhue
Member
|
0 |
|
|
Joined: 07/05/2009 00:11:52
Messages: 10
Offline
|
|
|
|
[Question] Re: highttpd hay nginx |
15/05/2009 07:00:01 (+0700) | #4 | 180622 |
lequi
Member
|
0 |
|
|
Joined: 29/04/2007 18:13:32
Messages: 77
Offline
|
|
Lighthttpd có những ưu điểm hơn Apache như:
- Sử dụng tài nguyên hơn Apache
- Ưu thế trong xử lý tập tin tĩnh
- Hỗ trợ FastCGI và SCGI rất tốt
Những nhược điểm:
- Mình nhớ không nhầm là không hỗ trợ .htaccess làm rules cho người dùng (rewrite...)
nên không có ưu thế làm share hosting
- Mọi thay đổi cấu hình phải restart hệ thống.
- Thiếu nhiều modules, như mod_security, mod_auth_external, mod_whatever, không hỗ trợ SVN server.
trên đây là một số ưu nhược điểm mà mình được biết, ai biết thêm bổ sung thêm.
Mình xin trích dẫn 1 đoạn của _id ở VBF
Nhận xét một web server có lightweight hay không thì phải dựa vào nhiều tiêu chí, không thể nói đơn thuần nó *mạnh hơn* là được, việc GC có thể config thông qua giao diện web chỉ đảm bảo được tính chất Manageability của một lightweight web server. Hiện tại các web server phổ biến hầu hết đều không hơn nhau mấy (nginx, lighthttpd, Apache, IIS), chúng đều được phát triển để theo kịp xu hướng chung của sự phát triển công nghệ (hardware vs OS). Một lightweight http server cần đảm bảo:
_Performance: Một request sẽ được nó (web server) xử lí trong bao lâu.
_Scalability: Server có thể xử lí cùng lúc nhiều request dồn dập với tốc độ như nhau hay không? Client thứ nhất truy cập trang web với thời gian load là 0.2s thì user thứ 1000 cũng phải được đối xử như thế, đó là tính bền bỉ mà một web server cần có.
_Security: một web server chỉ làm nhiệm vụ là một web server và không hơn. Web server phải đảm nhiệm được việc authenticate user và phục vụ được cái https request. Web server này có dễ bị nhân nhượng hoặc tổn thương không?
_Availability: Web server phải đảm bảo được tính bền bỉ, sẵn sàng trong mọi trường hợp. Trong đó đưa ra các dự báo về các tác động ảnh hường đến khả năng "từ chối dịch vụ" của nó.
_Compliance to standards: hoạt động cũng như cách phục vụ của web server có tuân theo các tiêu chuẩn RFC hay không. Tôi tin chắc hầu hết các bạn ở đây chưa một lần đọc qua 1 dòng của bất cứ bản RFC nào.
_Flexibility: tính dẻo dai, có thể hoạt động trong bao lâu, có thể phục vụ một lúc bao nhiêu request đối với một nền tảng phần cứng tiêu chuẩn nào đó, có thể xử lí điều tác các dynamic content page (php, asp...)...
_Platform requirements: web server này có cần phải chạy trên một nền tảng phần cứng, OS đặc biết không? Hay đặt đâu chạy đó, tương thích tốt với hầu hết các phần cứng và hệ điều hành mà nó support...
_Cuối cùng mới là tính chất Manageability.
Apache và nginx là 2 web server xứng đáng với các tiêu chí trên.
Đây cũng là một đoạn trên hostingfu.com:
I have been using Lighttpd for almost a year and Nginx for a month on my servers. I know that they were created to be massively scalable, solving the C10k problem. However their asynchronised-IO model and small memory foot-print also make them suitable as alternative HTTP servers for memory-limited VPS. Alternative = Anything but the current defacto Apache.
I will be writing more about Lighttpd and Nginx later during the year, but will try to use this post to draw some comparison between Nginx, the new darling of these light-weight web servers, and Lighttpd, many Web 2.0 developers’ all time favourite.
Lighttpd
I have been running Lighttpd (pronounced “lighty”) on my home servers and development boxes since the beginning of 2006. It is a great replacement for Apache if you have the whole box to yourself, i.e. you don’t need to worry about supporting .htaccess files that your users might use. Currently this website is hosted on lighttpd-1.4.13 on a Gentoo VPS.
Pros
•Light weight. Clean restart of 1.4.13 takes no more than 2Mb RSS on this 64bit VPS. It binds the port, drops the privilege and that’s it! A single process does all the tricks even when you have hundreds of concurrent connections. No more pre-fork MPM with mis-configured MaxClient that sends you to swap hell.
•Speed. Very fast static file serving. Very fast FastCGI serving. Very fast proxy serving.
•Modules, and lots of them. Good comprehensive documentation as well. It even has SCGI for your Quixote apps.
•Mod_magnet. Wanna a scripting engine right inside your web server? Mod_magnet integrates Lua into lighttpd, so your World of Warcraft scripting skillz can be put into better use.
•Community. It has got a Blog, a Wiki/bug tracker and a forum. It is easy to find help when you need one.
Cons
•Stability (or lack of according to the RoR folks). I had quite a lot of issues using Lighttpd as proxy+HTTPS front-end for our Python stuff, but the same app runs fine with just lighttpd + proxy without HTTPS.
•Mod_rewrite (or again, lack of it). Built-in rewriting engine sucks, and porting Apache mod_rewrite rules over can be non-trivial sometimes. Update: Here’s an article I have written on Drupal clean URL on Nginx and Lighttpd, which looks at the URL rewrite options of these two web servers.
•Memory leak. The RSS of my lighty process grows by about 1.5Mb per day, but then I don’t have lots of traffic (less than 50k requests a day). At the end I just need to restart it once a week. Many people have far worse memory leaking issues I heard.
Nginx
I have been running Nginx (pronounced “engine X”) on my development box and two of my VPS’s since December 2006. It is Russian, fast and very configurable. I am currently using 0.5.5 for my sites, but don’t be deceived by its version number — it is very stable.
Pros
•Light weight. It is not as light weight as lighttpd when it clean-starts. At least two processes are needed — one master process running as root that binds to the port, and one or more worker processes that handle the actual requests. Around 7Mb RSS together on my 64bit VPS (and only 4.5Mb on 32bit VPS). Still beats Apache hands down.
•Fast. Some benchmarks have shown that Nginx has a slight edge over Lighttpd, but so far I haven’t been able to notice any. Again, much faster than Apache over static file serving or proxying, especially when you turn up the value of keep alive (more than 1 minute for example).
•Modules. There are many modules available on Nginx. Some very useful, and some are just plain weird. While lighttpd has Lua embedded, you can now also embed the whole Perl interpretor inside Nginx.
•Better Rewrite Module. A much better rewrite module than Lighttpd that supports complex conditions. Porting mod_rewrite rules from Apache is actually now feasible without touching the apps themselves.
•Stable and not leaking. Been running Nginx on a production site doing PHP-FastCGI, and have no issue what so ever.
Cons
•Lack of community. Where can I find help regarding Nginx? There’s only IRC as far as I know. And while the lead developer writes beautiful code, all documentation were initially in Russian which was a big stumbling block before the English docs came along.
•No CGI support. Oh well, maybe I am the only one who still hacks small CGI scripts. Apparently Nginx does not spawn CGI or FastCGI processes, which means you need to either (1) convert it into external-spawn FastCGI, or (2) proxy to another web server that does CGI.
•No simple virtual host support. Lighttpd has mod_simple_vhost and mod_evhost to let you quickly deploy lots of name-based virtual hosts. You can somehow do the same with using $server_name in root and a wild-card in server_name, but it’s still not as clean as lighttpd. At the end you will find Nginx configuration files much more verbose if you run lots of small sites off a single web server.
•No X-sendfile support. I found Lighttpd’s X-sendfile support very useful when my scripts need to send back large files, and was disappointed to find out that Nginx does not have it. X-Accel-Redirect is different as it requires extra configuration on web server, which makes your web-app less portable.
Conclusion
I don’t think I am a suitable judge to say which one is better, as (1) I have only been running Nginx for a month, and (2) my level of traffic does not really stress test these high-performing web servers. At the moment I think I like Nginx better purely because it does not leak, and its rewrite module that enables me to run many off-the-shelf open source PHP apps with clean URL.
Again, I might change my mind in 3 months time when I find out more warts about Nginx. We will see.
Link: http://hostingfu.com/article/nginx-vs-lighttpd-for-a-small-vps |
|
|
|
|
|