为什么要使用nginx服务器?
我们大多数的客户在他们的服务器上使用Apache作为Web服务器,尤其是部署在一个基于PHP系统的前端并且使用mod-PHP。
鉴于扩张性和性能方面的原因,我们通常会建议他们改用Nginx和FPM。
Apache是非常强大的Web服务器,模块化结构,也是Web服务端的鼻祖。
除了捆绑一些其他的工具外,Apache已经成为了世上最广泛部署的开源系统,直到最近,世界上大多数网站仍运行着Apache系统。
但是,Apache并不是完美的,并且不再适合大规模系统。
为什么?因为他的进程模式虽然简单而灵活,但并不适合大规模尤其是当要处理像PHP这种需要占用大量内存应用程序代码时。
一个典型的网络应用服务器由两部分组成。
客户端连接部分负责用户浏览器与HTTP连接,保持长时间的TCP/IP协议,通常是1到2分钟。
对于一个大型的系统,服务器可能要同时承担和处理数以万计的并发连接。
这直接与Apache只有 500条进程即500个HTTP连接的处理能力上限相冲突。
而现今的浏览器让这个问题更加严重, 因为现在的浏览器平均每个主机会打开六个网站链接(几年前是两个网站链接)。
所以当超过100个用户同时访问时,Apache就已经满负荷了。
第二部分是应用程序处理部分,这部分承担了代码运算。
在大多数系统中,这部分工作是最消耗RAM和CPU资源的,因此进程数量必须被严格限制,通常是大约每1GB的内存10个进程,或者每个CPU核心两个进程。
因此一台4GB RAM、16内核的服务器最多只能运行32个应用程序进程。
但是,问题的关键是,Apache直接连接前端客户端通讯组件与后端应用程序进程组件。
如此一来,前端部分往往保持长时间的连接,常常达到几分钟,这导致后端部分将持续消耗内存和CPU资源。
目前还没有直接的方法能够在大型系统中找到前后端服务的平衡,因此他们必须被分离开来。
目前有两个主要的解决方法。
第一个方法,也是现有系统上最容易的方法,就是在Apache前端安装负载均衡服务器或者Nginx来处理客户端连接部分。
负载均衡服务器,像HAProxy或者Nginx能轻松处理成千上万条并发的连接,并使Apache能够真正的仅作为后端应用程序工作,来处理32个或是更多的进程。
第二种方案,也是最通用的办法就是用Nginx替换Apache,同时使用PHP-PFM作为应用服务器。
就像之前所提到的,这将分割前端客户端通信部分和后端应用程序部分。
Nginx处理HTTP通讯协议,同时FPM处理后端应用程序部分,和那32个进程进行交互。
然而这几种方法仍然还存在一些问题,主要是如何加载服务器的RPC调用,以及如何释放已经完成的RPC调用。
这两个问题都会在其他的博客中加以详解。
另外,只使用Nginx的解决方法会给那些严重依赖于Apache功能的应用程序带来问题,尤其是特别依赖rewrite rules, .htaccess, 或者mod_security等一些可选组件的应用程序。
在这种情况下,在Apache前端增加安装Nginx是最好的方法。
通常来说,所有新的系统都应该使用Nginx和PHP-FPM来部署。
这能提供高性能增长特性,并且是平衡用户和内存,CPU资源的最佳选择。
已存在的系统可以在前端使用Nginx或者HAProxy以达到同样的效果,以便在当今现代网络环境中为用户提供更优质的服务。
nginx缓存性能怎么样
Nginx缓存对于不少人来说都不是很明朗的一个知识。
那么好我们就借介绍有关优点和缺点的机会把大家带进Nginx缓存的世界。
希望大家在文中能找到自己相关的使用方法。
两种Nginx缓存都有着基本一样的优点和缺点:缺点1:不支持带参数的动态链接,比如read.php?id=1,因为Nginx缓存只保存文件名,所以这个链接只在文件系统下保存为read.php,这样用户访问read.php?id=2时会返回不正确的结果。
同时不支持http://www.sudone.com/这种形式的首页和二级目录http://www.sudone.com/download/,因为Nginx缓存非常老实,会将这样的请求照链接写入文件系统,而这个链接显然是一个目录,所以保存失败。
这些情况都需要写rewrite才能正确保存。
缺点2:Nginx缓存内部没有缓存过期和清理的任何机制,这些缓存的文件会永久性地保存在机器上,如果要缓存的东西非常多,那就会撑暴整个硬盘空间。
为此可以使用一个shell脚本定期清理,同时可以撰写php等动态程序来做实时更新。
缺点3:只能缓存200状态码,因此后端返回301/302/404等状态码都不会缓存,假如恰好有一个访问量很大的伪静态链接被删除,那就会不停穿透导致后端承载不小压力。
缺点4:Nginx不会自动选择内存或硬盘作为存储介质,一切由配置决定,当然在当前的操作系统里都会有操作系统级的文件缓存机制,所以存在硬盘上也不需要过分担心大并发读取造成的io性能问题。
Nginx传统缓存的缺点也是它和squid等缓存软件的不同之特色,所以也可看作其优点。
在生产应用中它常常用作和squid的搭档,squid对于带?的链接往往无法阻挡,而Nginx能将其访问拦住,例如:http://sudone.com/?和http://sudone.com/在squid上会被当做两个链接,所以会造成两次穿透;而Nginx只会保存一次,无论链接变成http://sudone.com/?1还是http://sudone.com/?123,均不能透过Nginx缓存,从而有效地保护了后端主机。
Nginx缓存会非常老实地将链接形式保存到文件系统中,这样对于一个链接,可以很方便地查阅它在缓存机器上的缓存状态和内容,也可以很方便地和别的文件管理器如rsync等配合使用,它完完全全就是一个文件系统结构。
这两种传统缓存都可以在linux下将文件保存到/dev/shm里,一般我也是这么做的,这样可以利用系统内存来做缓存,利用内存的话,清理过期内容速度就会快得多。
使用/dev/shm/时除了要把tmp目录也指向到/dev/shm这个分区外,如果有大量小文件和目录,还要修改一下这个内存分区的inode数量和最大容量:mount -o size=2500M -o nr_inodes=480000 -o noatime,nodiratime -o remount /dev/shm上面的命令在一台有3G内存的机器上使用,因为/dev/shm默认最大内存是系统内存的一半就是1500M,这条命令将其调大成2500M,同时shm系统inode数量默认情况下可能是不够用的,但有趣的是它可以随意调节,这里调节为480000保守了点,但也基本够用了。
在Ubuntu 里有没有什么命令确定 Nginx 配置文件位置
展开全部 当你执行 nginx -t 得时候,nginx会去测试你得配置文件得语法,并告诉你配置文件是否写得正确,同时也告诉了你配置文件得路径:# nginx -tnginx: the configuration file /usr/local/etc/nginx/nginx.conf syntax is oknginx: configuration file /usr/local/etc/nginx/nginx.conf test is successful...
mac版装了nginx怎么卸载
1)MAC卸载软件:Mac 卸载软件的方法相对于 Windows 来说,其实比较简单。
打开 Mac 上的 Finder 应用——点击应用程序——找到自己想要卸载的应用程序——右键点击应用——选择移到废纸篓。
如果系统设置了密码的话,系统会让输入当前系统用户的密码,输入后即可进行上面操作。
2)如果还是卸载不掉的话,那推荐你用卸载能力很强的腾讯电脑管家,管家管理页——软件管理——卸载——选择软件确认卸载就可以了,如果有顽固项残留项管家会提醒你进行清理。
nginx不管怎么修改配置,页面都是默认页面welcome to nginx的解
展开全部 这并不是电脑中毒或者网站被挂马,事实上是电信的原因,NGINX本身是一个服务器。
以前我们输入不存在的网址会跳转到114页面,而现在是 “Welcome to nginx!”这个页面。
请大家放心吧,可以多找几台电脑测试便知。
过段时间就会恢复了。
1、从nginx官网下载软件 我这里下载的是1.8.1 2、解压下载的压缩包,如下图配置好conf文件夹中的 nginx.conf 文件,将需要转发的地址配置上去 3、运行nginx.exe,如果配置正确的话,nginx就会在后台跑起来,这时候打开浏览器,输入http://localhost,如出现下图则恭喜你访问成功,就地址可以成功转发啦。
4、如果想要关闭nginx进程,经测试单结束进程是无法干掉nginx的,只能通过结束进程树的方式关闭。
...
为什么不用nginx 解决
展开全部 我们大多数的客户在他们的服务器上使用Apache作为Web服务器,尤其是部署在一个基于PHP系统的前端并且使用mod-PHP。
鉴于扩张性和性能方面的原因,我们通常会建议他们改用Nginx和FPM。
Apache是非常强大的Web服务器,模块化结构,也是Web服务端的鼻祖。
除了捆绑一些其他的工具外,Apache已经成为了世上最广泛部署的开源系统,直到最近,世界上大多数网站仍运行着Apache系统。
但是,Apache并不是完美的,并且不再适合大规模系统。
为什么?因为他的进程模式虽然简单而灵活,但并不适合大规模尤其是当要处理像PHP这种需要占用大量内存应用程序代码时。
一个典型的网络应用服务器由两部分组成。
客户端连接部分负责用户浏览器与HTTP连接,保持长时间的TCP/IP协议,通常是1到2分钟。
对于一个大型的系统,服务器可能要同时承担和处理数以万计的并发连接。
这直接与Apache只有 500条进程即500个HTTP连接的处理能力上限相冲突。
而现今的浏览器让这个问题更加严重, 因为现在的浏览器平均每个主机会打开六个网站链接(几年前是两个网站链接)。
所以当超过100个用户同时访问时,Apache就已经满负荷了。
第二部分是应用程序处理部分,这部分承担了代码运算。
在大多数系统中,这部分工作是最消耗RAM和CPU资源的,因此进程数量必须被严格限制,通常是大约每1GB的内存10个进程,或者每个CPU核心两个进程。
因此一台4GB RAM、16内核的服务器最多只能运行32个应用程序进程。
但是,问题的关键是,Apache直接连接前端客户端通讯组件与后端应用程序进程组件。
如此一来,前端部分往往保持长时间的连接,常常达到几分钟,这导致后端部分将持续消耗内存和CPU资源。
目前还没有直接的方法能够在大型系统中找到前后端服务的平衡,因此他们必须被分离开来。
目前有两个主要的解决方法。
第一个方法,也是现有系统上最容易的方法,就是在Apache前端安装负载均衡服务器或者Nginx来处理客户端连接部分。
负载均衡服务器,像HAProxy或者Nginx能轻松处理成千上万条并发的连接,并使Apache能够真正的仅作为后端应用程序工作,来处理32个或是更多的进程。
第二种方案,也是最通用的办法就是用Nginx替换Apache,同时使用PHP-PFM作为应用服务器。
就像之前所提到的,这将分割前端客户端通信部分和后端应用程序部分。
Nginx处理HTTP通讯协议,同时FPM处理后端应用程序部分,和那32个进程进行交互。
然而这几种方法仍然还存在一些问题,主要是如何加载服务器的RPC调用,以及如何释放已经完成的RPC调用。
这两个问题都会在其他的博客中加以详解。
另外,只使用Nginx的解决方法会给那些严重依赖于Apache功能的应用程序带来问题,尤其是特别依赖rewrite rules, .htaccess, 或者mod_security等一些可选组件的应用程序。
在这种情况下,在Apache前端增加安装Nginx是最好的方法。
通常来说,所有新的系统都应该使用Nginx和PHP-FPM来部署。
这能提供高性能增长特性,并且是平衡用户和内存,CPU资源的最佳选择。
已存在的系统可以在前端使用Nginx或者HAProxy以达到同样的效果,以便在当今现代网络环境中为用户提供更优质的服务。
listen
这个不是命令吧,这个是参数啊!listen_port翻译中文就是监听端口,这个一般出现在服务器上的服务端软件的配置文件中,比如Nginx mysql这些,有的是直接port=?? 这个监听端口,监听的是传输层的端口,比如Nginx默认监听的就是80端口,这种可以自己修改的,80端口是用于网页访问的,你打开网页时,其实就是去访问了某台服务器的80端口。
传输层是IP协议的一层,呃................太多了,不说了不说了
怎么在nginx中添加外网ip?
添加方法:1、检查一下主机的防火墙或策略,是否把80端口禁用了。
2、如果客户端和服务器不在同一个网段,需要在路由器设置映射或者路由功能。
3、检查设置nginx.conf里面,有没有deny相关的设置。
4、在服务端本地打开http://127.0.0.1,看看能不能访问,确定nginx正常启动。
Nginx是一个高性能的HTTP和反向代理服务器,也是一个IMAP/POP3/SMTP服务器。
Nginx是由Igor Sysoev为俄罗斯访问量第二的Rambler.ru站点开发的,供俄国大型的入口网站及搜索引擎Rambler使用。
第一个公开版本0.1.0发布于2004年10月4日。
其将源代码以类BSD许可证的形式发布,因它的稳定性、丰富的功能集、示例配置文件和低系统资源的消耗而闻名。
Nginx特点是占有内存少, 并发能力强。
中国大陆使用nginx网站用户有:百度、京东、新浪、网易、腾讯、淘宝等。
2011年6月1日,nginx1.0.4发布。
Nginx 可以在大多数 UnixLinux OS 上编译运行,并有 Windows 移植版。
Nginx 的1.4.0稳定版已经于2013年4月24日发布,一般情况下,对于新建站点,建议使用最新稳定版作为生产版本,已有站点的升级急迫性不高。
Nginx 的 源代码使用 2-clause BSD-like license。
Nginx 是一个很强大的高性能 Web和 反向代理服务器,它具有很多非常优越的特性:在连接高并发的情况下,Nginx是 Apache服务器不错的替代品:Nginx在美国是做虚拟主机生意的老板们经常选择的软件平台之一。
能够支持高达 50,000 个并发连接数的响应,感谢Nginx为我们选择了 epoll and kqueue作为开发模型。
nginx 负载均衡 服务器有多个站点,改怎么设置选择我需要的
负载均衡是我们大流量网站要做的一个东西,下面我来给大家介绍在Nginx服务器上进行负载均衡配置方法,希望对有需要的同学有所帮助哦。
负载均衡先来简单了解一下什么是负载均衡,单从字面上的意思来理解就可以解释N台服务器平均分担负载,不会因为某台服务器负载高宕机而某台服务器闲置的情况。
那么负载均衡的前提就是要有多台服务器才能实现,也就是两台以上即可。
测试环境由于没有服务器,所以本次测试直接host指定域名,然后在VMware里安装了三台CentOS。
测试域名 :a.comA服务器IP :192.168.5.149 (主)B服务器IP :192.168.5.27C服务器IP :192.168.5.126部署思路A服务器做为主服务器,域名直接解析到A服务器(192.168.5.149)上,由A服务器负载均衡到B服务器(192.168.5.27)与C服务器(192.168.5.126)上。
域名解析由于不是真实环境,域名就随便使用一个a.com用作测试,所以a.com的解析只能在hosts文件设置。
打开:C:WindowsSystem32driversetchosts在末尾添加192.168.5.149 a.com保存退出,然后启动命令模式ping下看看是否已设置成功从截图上看已成功将a.com解析到192.168.5.149IPA服务器nginx.conf设置打开nginx.conf,文件位置在nginx安装目录的conf目录下。
在http段加入以下代码upstream a.com {server 192.168.5.126:80;server 192.168.5.27:80; }server{listen 80;server_name a.com;location / {proxy_pass http://a.com;proxy_set_header Host $host;proxy_set_header X-Real-IP $remote_addr;proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;} }保存重启nginxB、C服务器nginx.conf设置打开nginx.confi,在http段加入以下代码server{listen 80;server_name a.com;index index.html;root /data0/htdocs/www; }保存重启nginx测试当访问a.com的时候,为了区分是转向哪台服务器处理我分别在B、C服务器下写一个不同内容的index.html文件,以作区分。
打开浏览器访问a.com结果,刷新会发现所有的请求均分别被主服务器(192.168.5.149)分配到B服务器(192.168.5.27)与C服务器(192.168.5.126)上,实现了负载均衡效果。
B服务器处理页面C服务器处理页面假如其中一台服务器宕机会怎样?当某台服务器宕机了,是否会影响访问呢?我们先来看看实例,根据以上例子,假设C服务器192.168.5.126这台机子宕机了(由于无法模拟宕机,所以我就把C服务器关机)然后再来访问看看。
访问结果:我们发现,虽然C服务器(192.168.5.126)宕机了,但不影响网站访问。
这样,就不会担心在负载均衡模式下因为某台机子宕机而拖累整个站点了。
如果b.com也要设置负载均衡怎么办?很简单,跟a.com设置一样。
如下:假设b.com的主服务器IP是192.168.5.149,负载均衡到192.168.5.150和192.168.5.151机器上现将域名b.com解析到192.168.5.149IP上。
在主服务器(192.168.5.149)的nginx.conf加入以下代码:upstream b.com {server 192.168.5.150:80;server 192.168.5.151:80; }server{listen 80;server_name b.com;location / {proxy_pass http://b.com;proxy_set_header Host $host;proxy_set_header X-Real-IP $remote_addr;proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;} }保存重启nginx在192.168.5.150与192.168.5.151机器上设置nginx,打开nginx.conf在末尾添加以下代码:server{listen 80;server_name b.com;index index.html;root /data0/htdocs/www; }保存重启nginx完成以后步骤后即可实现b.com的负载均衡配置。
主服务器不能提供服务吗?以上例子中,我们都是应用到了主服务器负载均衡到其它服务器上,那么主服务器本身能不能也加在服务器列表中,这样就不会白白浪费拿一台服务器纯当做转发功能,而是也参与到提供服务中来。
如以上案例三台服务器:A服务器IP :192.168.5.149 (主)B服务器IP :192.168.5.27C服务器IP :192.168.5.126我们把域名解析到A服务器,然后由A服务器转发到B服务器与C服务器,那么A服务器只做一个转发功能,现在我们让A服务器也提供站点服务。
我们先来分析一下,如果添加主服务器到upstream中,那么可能会有以下两种情况发生:1、主服务器转发到了其它IP上,其它IP服务器正常处理;2、主服务器转发到了自己IP上,然后又进到主服务器分配IP那里,假如一直分配到本机,则会造成一个死循环。
怎么解决这个问题呢?因为80端口已经用来监听负载均衡的处理,那么本服务器上就不能再使用80端口来处理a.com的访问请求,得用一个新的。
于是我们把主服务器的nginx.conf加入以下一段代码:server{listen 8080;server_name a.com;index index.html;root /data0/htdocs/www; }重启nginx,在浏览器输入a.com:8080试试看能不能访问。
结果可以正常访问既然能正常访问,那么我们就可以把主服务器添加到upstream中,但是端口要改一下,如下代码:upstream a.com {server 192.168.5.126:80;server 192.168.5.27:80;server 127.0.0.1:8080; }由于这里可以添加主服务器IP192.168.5.149或者127.0.0.1均可以,都表示访问自己。
重启Nginx,然后再来访问a.com看看会不会分配到主...
转载请注明出处51数据库 » nginx 软件命令