登录论坛

查看完整版本 : Linux 【求助】Nginx 真的这么夸张?


天天向上
2009-11-10, 01:36 AM
好久没看技术文章,也一直在用freebsd+php+mysql+apache ,因为一直都稳定,所以没管他,N年没管... 最后因为管理的网站访问量加大了,服务器负载高了,所以开始搞点资料研究一下. 发现Nginx...

Nginx 比apache 好10倍多? 真的假的????? 如果真的,我马上学生,准备换了.请前辈指点一下.有没有什么优点和误点呀?

谢谢了.

seedsquall
2009-11-10, 03:33 AM
apache按现在的说法是上个世纪的产品了,呵呵。好不好用试试不就知道了?用了保证你相见恨晚。别的地方不知道,apache的时代在我们这里已经过去了...nginx配置简单,性能不俗。

巫神
2009-11-10, 05:30 AM
要看具体应用的 在某些应用 比如RoR lighttpd和nginx的确是比apache有着很大的效率优势

但是不要小看了apache长期的社区效用 稳定性 企业应用的话可能多几个node上apache 也比单台上lighttpd和nginx好

如果我更偏向于 lighttpd 因为patch什么要比nginx看上去好点

要是企业应用 还是会用负载均衡 用apache 省心

xiaolong
2009-11-10, 07:27 AM
正在切换nginx中,初步使用感觉良好。

受不鸟
2009-11-10, 09:25 AM
小弟主要用于广告网,freebsd服务器+ apache+ mysql + php 的... -o- 不知道,要不要换... 产生用...

同时问一下,有没有freebsd下安装的详细教学?

查了一下,都是lunx下的...

齐晴
2009-11-10, 11:22 AM
要是还没有严重性能问题不建议更换

designer
2009-11-10, 01:19 PM
要是还没有严重性能问题不建议更换 前辈说的对,生产服务器,以稳定为主. 不过要先学习一下,回头能用...:D

飞雪心
2009-11-10, 03:16 PM
个人估计对php的提升不会像RoR那么大

花姑娘
2009-11-10, 05:14 PM
RoR 是什么呀?前辈...

Nginx 对静太页面效果好???

£小艾£
2009-11-10, 07:11 PM
ruby on rails

翦水瞳
2009-11-10, 09:08 PM
但是这个 Nginx 真的这么利害?? 对到 mysql + php 或 Nginx , 不会因为mysql而影响到速度???

我同时问了N个了,10个里有9个说,Nginx 的性能是吹的....

甘道夫
2009-11-10, 11:05 PM
好不好自己测下呗

贪狼星
2009-11-11, 01:03 AM
没设备搞... 所以问一下前辈们... 是否有必要换...

龙宝宝
2009-11-11, 03:00 AM
不实际测试的话 我建议一定不要换

xiaobieli
2009-11-11, 04:57 AM
只有根据自己的应用具体测试后,才能决定到底哪个更适合自己,这也是linux管理员的基本要求。而不是简单的人云亦云。

所以,Linux系统管理,不仅仅是会安装,写点shell就行了的。

默默
2009-11-11, 06:54 AM
nginx在内存消耗上比apache少得多,处理静态文件比apache效率高。

bluetooth
2009-11-11, 08:52 AM
nginx在内存消耗上比apache少得多,处理静态文件比apache效率高。 前辈这么说,是有所研究了? :D

傻瓜
2009-11-11, 10:49 AM
nginx在内存消耗上比apache少得多,处理静态文件比apache效率高。 嗯,我们公司就是用nginx做的静态内容服务器


楼主可以考虑跟我们一样,把动态内容与静态内容分开,静态的可以用nginx

阿迪达斯
2009-11-11, 12:46 PM
嗯,我们公司就是用nginx做的静态内容服务器


楼主可以考虑跟我们一样,把动态内容与静态内容分开,静态的可以用nginx 静态的用nginx 和用 apache 基本一样吧?? :D

就是想了解一下用过的前辈,基本 PHP+MYSQL+FREEBSD 的情况下,用APAHCE和 NGINX 那个 牛一点...

路过
2009-11-11, 02:43 PM
内存占用上比apache省得比较多,PHP只能fastcgi,个人觉得不如apache那样编译进去放心。毕竟fastcgi的TCP连接也可能成为瓶颈

抓抓
2009-11-11, 04:41 PM
建议你先简单分析一下,高负荷的瓶颈在哪里,通常,有针对性的优化比一般性的折腾要有效些

蓝色jj
2009-11-11, 06:38 PM
稳定为主,可以测试一下nginx的效果,然后再迁移

5free
2009-11-11, 08:35 PM
毕竟fastcgi的TCP连接也可能成为瓶颈, 对的...

帆布鞋
2009-11-11, 10:32 PM
在linux下fastcgi的开销远比apache的多线程小,所以php编译到apache模块中没有优势。windows下刚好相反
可以放狗搜C10K相关的信息:
http://www.kegel.com/c10k.html

nginx的性能我只测过静态页面,比apache快3-5倍,并且系统开销小很多
至于说到稳定性,可能需要时间的考验。即便是apache也不是所有的版本都稳定的,所以许多网址不会轻易更换apache的版本

蜗牛也是牛
2009-11-12, 12:30 AM
在linux下fastcgi的开销远比apache的多线程小,所以php编译到apache模块中没有优势。windows下刚好相反可以放狗搜C10K相关的信息:
http://www.kegel.com/c10k.html
nginx的性能我只测过静态页面,比apache快3-5倍,并且系统开销小很多...... 恩,前辈说的很有道理.关键还是要稳定性呀... :D

小仁
2009-11-12, 02:27 AM
静态的用nginx 和用 apache 基本一样吧?? :D

就是想了解一下用过的前辈,基本 PHP+MYSQL+FREEBSD 的情况下,用APAHCE和 NGINX 那个 牛一点...
不是说了吗,静态用nginx系统开销要小很多

小棉袄
2009-11-12, 04:24 AM
10倍夸张了,很多问题要综合考量。 而且fastcgi跑php有时候还有些问题,压力大的业务fastcgi没配好的话,nginx容易出502错误, 尽量还是apache吧,除非要用到nginx的一些特性。

重新启动
2009-11-12, 06:21 AM
10倍夸张了,很多问题要综合考量。 而且fastcgi跑php有时候还有些问题,压力大的业务fastcgi没配好的话,nginx容易出502错误, 尽量还是apache吧,除非要用到nginx的一些特性。 这个可能是因为nginx性能太强,于是瓶颈后移到mysql/php上了。Apache又慢又稳定,瓶颈在apache上于是慢而不死502.

dafansheep
2009-11-12, 08:19 AM
谢谢前辈们的指点,经过这么多人的研究.

我认为,用 Nginx 来做web 服务, 只用于处理 HTML 的网站(或是生成HTML)或是页面. 不安装,或不用 MYSQL+PHP , 是最最最理想的高性能服务器!!

同时问一下,如果配置一个服务器,

FREEBSD+NGINX , 来处理html网站(HTML页面+一些小的JPG小图标+一些JS脚本什么的), 是不是对 CPU 的要求不用很高, 关键要内存大??

pc0758
2009-11-12, 10:16 AM
nginx是多个进程下跑多个线程进行web服务的,内存消耗比prefork的apache要少很多。
具体选型看具体应用的需求和架构,一般如果中小型流量的网站,apache绝对够用了。

陋者
2009-11-12, 12:13 PM
谢谢前辈们的指点,经过这么多人的研究.我认为,用 Nginx 来做web 服务, 只用于处理 HTML 的网站(或是生成HTML)或是页面. 不安装,或不用 MYSQL+PHP , 是最最最理想的高性能服务器!!同时问一下,如果配置一个服务器,FREEBSD+NGINX , 来处理html网站(HTML页面+一些小的J...... nginx 对CPU和内存要求不高
若是使用NCACHE,可以考虑多些内存

爸爸
2009-11-12, 02:10 PM
nginx是多个进程下跑多个线程进行web服务的,内存消耗比prefork的apache要少很多。
具体选型看具体应用的需求和架构,一般如果中小型流量的网站,apache绝对够用了。 大型网站,我正在学习,计划全部生成html . 每天大约有30万IP,350万的Page View .:D

xiaolong
2009-11-12, 04:08 PM
看看這個, Lighttpd 與 Nginx 的比較

http://hostingfu.com/article/nginx-v...or-a-small-vps (http://hostingfu.com/article/nginx-vs-lighttpd-for-a-small-vps)

is286
2009-11-12, 06:05 PM
nginx?还以为是类unix操作系统呢..:D
2年不接触这一块了,又出新东西了?

无剑
2009-11-12, 08:02 PM
350万PV跑大量静态html + 部分动态内容光apache也是很轻松的,具体看应用的设计。

关键是,要考虑架构的可线性扩展性,单机性能的优略到一定访问量以后区别甚至可以忽略的(当然细调的话,能省下很多成本),否则等到了几百万独立IP,千万级的PV以后,死的很难看的。 :D

绯村十二少
2009-11-12, 09:59 PM
用APACHE好多年,一般用作设备流量读取的初始界面,连NGINX的名字都没听过,汗啊。
看来要跟进一下时代的潮流了。

JOJO卓
2009-11-12, 11:57 PM
看看這個, Lighttpd 與 Nginx 的比較

http://hostingfu.com/article/nginx-v...or-a-small-vps (http://hostingfu.com/article/nginx-vs-lighttpd-for-a-small-vps)
看了一點,感覺 lighttpd 比Nginx 綜合能力要高一點??? :D

淑女E
2009-11-13, 01:54 AM
看看這個, Lighttpd 與 Nginx 的比較

http://hostingfu.com/article/nginx-v...or-a-small-vps (http://hostingfu.com/article/nginx-vs-lighttpd-for-a-small-vps)
这个文章太老了

看看评价nginx的
Cons
* Lack of community.
现在有
* No CGI support.
支持的
* No simple virtual host support.
支持的
* No X-sendfile support.
支持的

饭特稀
2009-11-13, 03:51 AM
这个文章太老了

看看评价nginx的
Cons
* Lack of community.
现在有
* No CGI support.
支持的
* No simple virtual host support.
支持的
* No X-sendfile sup...... 前辈,有没有最最最新的资料??? :D

windchill
2009-11-13, 05:48 AM
前辈,有没有最最最新的资料??? :D 看官网
http://wiki.nginx.org/
http://wiki.nginx.org/NginxChs

nevermind
2009-11-13, 07:46 AM
资料太少... 交流的人也太少. CCF 要不要搞一个 Nginx群??

边缘
2009-11-13, 09:43 AM
资料太少... 交流的人也太少. CCF 要不要搞一个 Nginx群?? 官网上文档基本也够看了,邮件列表是个不错的选择,学习一下别人的经验,看一下别人的问题是咋解决的

菡鸢儿
2009-11-13, 11:40 AM
看官网文档基本就ok了

xiaobieli
2009-11-13, 01:37 PM
现在一直在用 Nginx 当做 Cache server

啃得猪
2009-11-13, 03:35 PM
那个说10倍的文章稍微夸张了点,但是性能有明显提高倒是真的。

感觉处理纯静态的文件还是蛮有优势的,比apache明显占用资源少,缺点是url rewrite要哟要重写不能通用。

无剑
2009-11-13, 05:32 PM
Nginx 纯静态 单台一天试过1亿PV..

一加一
2009-11-13, 07:29 PM
Nginx 纯静态 单台一天试过1亿PV.. 前天正式安裝了 Nginx , 系統 Freebsd .

全部軟件: FreeBSD+FTP+NGINX

全部用來跑 HTML 的純靜態頁面 ( 頁面由另一台PHP+MYSQL生成 )

目前運行了二天,一直在關查....

二個字 : 非常爽

:D


有幾點要特別注意的,

在安裝 Nginx 時, 默認裡是沒有 SUB-DOMAIN 選擇的,要打上鉤 . 我就是因為沒有打上這個東西, 最後配置 nginx.conf 的 域名時,出了很多問題. 不支持泛域名... -_-

後來重新config 安裝了. 但是對 Nginx.conf 裡的 域名 配置還是有點問題. 不過,目前正常,不敢再亂搞:

-----------------------host and domain--------------------------------------

server {
listen 80;
server_name .domain1.com;

location / {
root /usr/home/web/domain1;
index index.html;
access_log off;
}
}

server {
listen 80;
server_name .domain2.com;

location / {
root /usr/home/web/domain2;
index index.html;
access_log off;
}
}

server {
listen 80;
server_name .domain3.com;

location / {
root /usr/home/web/domain3;
index index.html;
access_log off;
}
}

server {
listen 80;
server_name state.domain.com state.domain2.com;

location / {
stub_status on;
access_log off;
}
}
-----------------------host and domain--------------------------------------

其中 , server_name .domain3.com; 中的 .domain3.com 意思是 *.domain3.com , 查了很多資料,不知道為什麼,按自帶的說明裡配置不行,進入域名後會直接到默認首頁,就是剛安裝好APACHE一樣的歡迎頁面...

之前是這樣配置的,不行:

server {
listen 80;
server_name domain1.com alias my1.domain1.com my2.domain1.com;

location / {
root /usr/home/web/domain1;
index index.html;
access_log off;
}
}

不知道為什麼,以上配置. 輸入domain1.com alias my1.domain1.com都進入歡迎頁面 , 只有my2.domain1.com進入目錄...

看了官方教學, 這樣配置 server_name domain1.com my1.domain1.com my2.domain1.com; 也一樣 只有my2.domain1.com進入目錄...

不懂.

pc0758
2009-11-13, 09:26 PM
二個字 : 非常爽 5个字^^

饭特稀
2009-11-13, 11:24 PM
的确看一些资料吹得挺玄乎,不知效果

^闪闪^
2009-11-14, 01:21 AM
今天发现:
Active connections: 291
server accepts handled requests
16630948 16630218 31070465
Reading: 6 Writing: 179 Waiting: 106

成功创建 少了730个... 也就是说有 730个握手失败?

active connections -- 对后端发起的活动连接数

server accepts handled requests -- nginx 总共处理了 16630948 个连接, 成功创建 16630218 次握手 (中间730个握手失败), 总共处理了 31070465 个请求 (平均每次握手处理了 1.8个数据请求)

想问一下,一般是什么情况会 730个握手失败 ??? 是Nginx配置并发问题?还是服务器?还是对方的网络有问题???

阿水
2009-11-14, 03:18 AM
我的理解是handeled是说处理完成的吧
730个应该是HTTP会话过程意外终止的

虾米
2009-11-14, 05:15 AM
我的理解是handeled是说处理完成的吧
730个应该是HTTP会话过程意外终止的 会话过程意外终止,这个是用户的问题,还是我服务器的问题??:D

另一台 apache 服务器上一年来,也有17000多个. 累计.

游来有趣
2009-11-14, 07:13 AM
accepts 应该表示的是socket连接已经建立完成
handled 是client发送的数据(HTTP请求)已经进行了对应的处理

之间的差异有可能是client连接成功但是没有发送任何有效数据或者是发送数据超时造成的

造成差异的具体原因多种多样,比如对一个放在公网的web server来说应该有不少人用各种扫描工具之类的的进行扫描吧,如果是自己在内网测试的话,也有可能是某些时刻服务器负载过大造成一些连接出现问题或者来不及响应之类的吧
个人认为应该问题不大

之前对apache和nginx的代码有过一些研究,nginx在大并发(1万以上)的情况下肯定是比apache要有优势的。因为nginx和lighttpd这些新的web server在linux下用的是epoll,FreeBSD下用的是kqueue,比apache的select/poll效率高很多

如果web server的并发数较少,比如只有几百个,那么apache和nginx的性能差距并不大,而且apache的多进程模型会更加稳定,当然nginx也可以配置成为多进程模式

yiyi
2009-11-14, 09:10 AM
謝謝前輩的分析,真的是說的非常的有經驗.
基本上了解了.

謝謝前輩指點.

绯村十二少
2009-11-14, 11:07 AM
又看了下新版的apache(>2.2),发现新的event MPM模式使用的是epoll和kqueue,在网络连接数和大并发的情况下可以使用,更正一下

sommm
2009-11-14, 01:04 PM
nginx还算是不错了,我遇到的问题就是和java的app server配合的时候没有模块支持,用proxy模式的时候很多应用会出问题。

青蛙怕怕
2009-11-14, 03:02 PM
google 上看了一下,好像都吹的很神乎嘛

蓬舟
2009-11-14, 04:59 PM
生产环境用了一个月了,确实不错,今天升级到0.7.59了

ringhi
2009-11-14, 06:56 PM
算算也用了1個多月了,不錯... 沒問題....

garconcn
2009-11-14, 08:53 PM
我做个一个实际测试双核双CPU浪潮服务器,4G内存。
使用Discuz7的论坛索引页面进行测试,模拟1024个连接,连续访问10000次。

有推导出相关结论:

1. 性能上来说NGINX还是要比Apache(Prefork)有优势。但主要是高并发连接的情况下。
Apache配置文件经过优化后(1024 Thread,4096 MaxClient)能够达到Nginx
的水平(24个worker进程,64个php-cgi进程),而且8192个连接nginx也保持稳定。
Apache的话2048个连接的测试就通过不了。

2. 在上述负载下NGINX的的出错率一直比较高,2%-5%非2xx的错误。Apache的确是
如楼上某位所言,负载高(uptime达到了32,nginx是3),但是不出错。一个非2xx
的错误都没有。

3. 上述差别其实就是select()和epool模式的差别所在,所以可比性并不强。应该将
Aapache的epoll MPM的性能与之做比较。

4. 静态页面方面,一个1K左右的HTML,nginx吞吐是Apache的3倍,但是系统负载
只有Apache的1/3(Uptime 0.9 vs 0.35)

对应的测试过程记录文件在附件里。

无剑
2009-11-14, 10:51 PM
nginx在内存消耗上比apache少得多,处理静态文件比apache效率高。 ngix 处理动态页面的速度也不快的。
ngix 主要是做cache 来使用的。
apache 的优点是稳定,高负荷可以稳定运行。
ngix,lighttppd 性能较好,不稳定,高负荷下容易崩溃。

babysitter
2009-11-15, 12:48 AM
ngix 处理动态页面的速度也不快的。
ngix 主要是做cache 来使用的。
apache 的优点是稳定,高负荷可以稳定运行。
ngix,lighttppd 性能较好,不稳定,高负荷下容易崩溃。 多高的负载会崩溃?

BigBull
2009-11-15, 02:45 AM
CPU保持在80以下,内存要够。虚拟缓存不要太大。

moneywood
2009-11-15, 04:42 AM
最近正在找个服务器配置做python服务。

服务器目前只能用windows2k3,现在用了apache, 服务响应不理想,想换个试试.正在找nginx文档

netbird
2009-11-15, 06:40 AM
nginx 跑静态页面速度比 Apache 快10倍多

但是跑PHP 各有特点,Apache 调教好后跑 PHP 比 Nginx 稳定的多

所以一般都是 Nginx+mcache+apache 的架构!

齐晴
2009-11-15, 08:37 AM
受教了,刚好一个项目,用nginx试试先。。。

溺水的鱼
2009-11-15, 10:34 AM
我现在是二台服务器,一台服务器是:
freebsd+php+mysql+apache 做程序的后台,用于生成html 网站的页面.
另一台服务器是:
freebsd+nginx , 就只用来跑WEB服务,做为前台.
是不是太浪费了?二个完全可以并一起?

顶风尿八丈
2009-11-15, 12:31 PM
真是越来越跟不上时代了,已然火星了,第一次听到Nginx

旧繁
2009-11-15, 02:29 PM
这玩意已经被很多大门户采用了 侧面证明其有效性