存档

‘nginx’ 分类的存档

nginx 实现 ajax 跨域请求

2016年1月24日 1 条评论

AJAX从一个域请求另一个域会有跨域的问题。那么如何在nginx上实现ajax跨域请求呢?要在nginx上启用跨域请求,需要添加add_header Access-Control*指令。如下所示:

释如下:

第一条指令:授权从other.subdomain.com的请求

第二条指令:当该标志为真时,响应于该请求是否可以被暴露

第三天指令:指定请求的方法,可以是GET,POST等

如果需要允许来自任何域的访问,可以这样配置:

重启nginx

ajax跨域请求测试

成功时,响应头是如下所示:

http://blog.hackroad.com/operations-engineer/linux_server/13011.html

分类: nginx 标签: ,

nginx rewrite 实现伪静态的自动补全

2015年8月21日 2 条评论

nginx+php 使用的时候经常需要伪静态,一般大家都手动设置。那有没有办法让 nginx 自动补全路径呢?
这两天折腾很久,才实现了这样一个功能:
请求 /a/b/c
若文件不存在,查找 /a/b/index.php,/c 作为 PATH_INFO;
若文件不存在,查找 /a/index.php,/b/c 作为 PATH_INFO;
若文件不存在,查找 /index.php,/a/b/c 作为 PATH_INFO;
若文件不存在,返回 404.

虽然这种损耗性能的行为不适合部署,但在本机调试的时候还是能够带来方便的 🙂

server 端应有如下代码,其他部分使用自己的配置:

index index.php index.html index.htm;

感谢来自 三天 tridays 的投稿

分类: nginx 标签:

NGINX如何实现高性能和可扩展性

2015年6月28日 没有评论

Owen Garrett是Nginx公司的产品总监,他在Nginx的官方博客上发表了一篇博文,说明了是哪些设计决策使得NGINX产品具备一流的性能和扩展能力。

NGINX的整体架构的特点是由一组进程协同工作

主进程:负责执行特权操作,如阅读配置文件、绑定套接字、创建/通知协调(Signalling)子进程。
工作进程:负责接收和处理连接请求,读取和写入磁盘,并与上游服务器通信。当NGINX处于活跃状态时,只有工作进程是忙碌的。
缓存加载器进程:负责将磁盘高速缓存加载到内存中。这个进程在启动时运行后随即退出。
缓存管理器进程:负责整理磁盘缓存的数据保证其不越界。这个进程会间歇性运行。
阅读全文...

分类: nginx 标签:

nginx使用线程池提升9倍性能

2015年6月22日 9 条评论

众所周知nginx使用异步,事件驱动方法处理连接。这意味着nginx使用一个worker进程处理多个连接和请求,而不是每一个请求有一个专门的进程或着线程处理(像传统架构的服务器那样,例如apache)。为了实现这个目的,nginx使用非阻塞模式的socket和高效的方法epoll和kqueue。

因为高负荷进程的数量少且相对不变(通常1个cpu核心配1个进程),它内存消耗少,cpu时间没有浪费在任务切换上。这种处理请求的方式的优势也因为nginx而被大家所熟知。nginx能够成功处理数百万并发请求同时扩展性非常好。
Traditional-Server-and-NGINX-Worker.gif
阅读全文...

分类: nginx 标签: ,

nginx与tomcat多实例搭建

2015年3月28日 没有评论

nginx和tomcat结合也是一个常用的组合,看到一个好的文章,介绍nginx做为方向代理,后端多个tomcat。
实现:一个nginx实例和多个tomcat实例,每个tomcat实例承载唯一的项目,tomcat实例在项目启动时自动启动
阅读全文...

分类: nginx 标签:

connect() failed (111: Connection refused) while connecting to upstream

2015年3月24日 没有评论

nginx是一个方向代理服务器,它负责把http请求转发给另一个服务进程处理(例如php-fpm).
nginx的111错误表示nginx收到了一个请求,但是不能转发给配置文件中配置的的要给转发的进程。

一般发生这种情况都是nginx启动了,但是没有启动服务进程php-fpm,这时候启动或者重启服务进程就可以了。

分类: nginx 标签:

nginx uWSGI Django python运行环境安装和配置

2015年2月8日 1 条评论

uWSGI is a fast (pure C), self-healing, developer/sysadmin-friendly application container server.”, it utilizes the uwsgi protocol (notice the all-lowercase spelling), and supports WSGI applications served from it.

上面这段文字是uWSGI的官方定义。
uWSGI是一个快速(纯C的)、自维护、对开发管理人员友好的应用容器。它使用uwsgi协议(小写定义),支持WSGI应用运行在它上面。

uwsgi安装

或者查看这里有许多uwsgi安装方法http://uwsgi-docs.readthedocs.org/en/latest/Install.html

myapp.py 放到运行命令目录

启动uwsgi

在浏览器内输入:http://127.0.0.1:3031,看是否有“Hello World”输出,若没有输出,请检查你的安装过程.

nginx配置文件

浏览器访问

未完待续...

分类: nginx 标签: ,

nginx location 配置踩坑过程分享

2015年2月6日 3 条评论

问题描述
我们的业务系统比较复杂,但最终提供给用户的访问接口比较单一,都是使用 Nginx 来做一个代理转发,而这个代理转发,往往需要匹配很多种不同类型的 URL 转给不同的服务。这就使得我们的 Nginx 配置文件变得很复杂,粗略估计了下,我们有近20个 upstream,有近60个 location 匹配。这些配置按照模块分布在不同的文件中,虽然复杂,但是仍然在我们的努力下运行的良好。直到有一天,有位同事给我反映说偶尔有些 URL 会出现 404 的问题。一开始没太在意,因为他也说不准是哪一种 URL 才遇到这个问题。

问题查找
后来,慢慢的查找,找到了一些规律,一开始只知道是 tomcat 那边返回 404了,想到 Nginx 都代理给了 tomcat,一开始就怀疑是程序的问题,不会想到是 Nginx。

我开始查找代码的问题,我在本地的开发环境,尝试了很久,我使用 8080 端口访问,不论如何都是正确的结果,可是生产环境就是不行。然后我就听信了某坑友同事的理论,重启解决 95% 的问题,重装解决 100%的问题,我尝试重启了 tomcat 和 Nginx,依然不行,然后是重装,你猜结果如何????? ——想啥呢?当然也是不行!

后来就开始怀疑是生产环境和开发环境的差异,去服务器上访问 8080 端口,仍然是可以的。可是一经过 Nginx 代理,就不行。这个时候才开始怀疑是 Nginx 出了什么问题。

Nginx 怎么会出问题呢,业务系统中 URL 模式 /helloworld/* ,这样的 URL 我们都是统一处理的。怎么会出现一些行,一些不行呢。问题表现为 A URL (/helloworld/nn/hello/world)没问题,而 B URL(/helloworld/ii/hello/world) 有问题。

所以到目前为止,基本可以肯定是 Nginx 的 location 上出了一些问题。

问题解决
因篇幅有限,为了直面本次问题的核心,我不再贴出完整的 Nginx 配置,我简化此次问题的模型。请看如下 Nginx 配置,这是我们之前的会导致问题的错误配置模型。

注意,这里有几点需要说明一下,生产环境的 Nginx 服务器配置文件比这里要复杂很多,而且是按模块分布在不同的文件中的。这里简化模型后,使用 Http 响应状态码 60x 来区分到底被哪个 location 匹配到了。
我针对当时的情况,做了大量尝试,最终的简化版本如下:

尝试1:http://localhost/helloworld ==> 602 符合预期
尝试2:http://localhost/helloworld/hello ==> 603 符合预期
尝试3:http://localhost/ii ==> 604 符合预期
尝试4:http://localhost/ii/oo ==> 604 符合预期
尝试5:http://localhost/ii/pp/kk ==> 605 符合预期
尝试6:http://localhost/ii/pp/kk/ll ==> 605 符合预期
尝试7:http://localhost/helloworld/scripts/aaa.js ==> 606 符合预期
尝试8:http://localhost/helloworld/ii/hello/world ==> 605 不符合预期,预期为【603】
上面这些尝试支持读者自行试验,Nginx 配置文件是完整可用的,我本地 Nginx 的版本是1.6.2

问题就在这里:我这里是事后,把这些匹配 location 标记成了不同的响应码,才方便查找问题。当发现这个不符合预期后,我还是难以理解,为何我一个以 /helloworld 开头的 URL 会被匹配到 605 这个以 /ii 开头的 location 里面来。在当时的生产环境中,以 /ii 的配置统一放在另外一个文件中,这里是很难直观的察觉出来这个 /ii 跟访问的 URL 里面的 /ii 的关系。

我不得不重新编译了 Nginx ,加上了调试参数,修改配置项,看调试日志了。

这里不再讲如何给 Nginx 加调试的编译参数,可自行查看相关文档。修改配置项很简单,只需要在

error_log logs/error.log;
后面加上 debug 就可以了。

打出详细调试日志后,访问
http://localhost/helloworld/ii/hello/world
我得到了这样的一段日志(省略掉了前后无用的日志,只保留有意义的一段):

可以看到,Nginx 测试了几次 location 匹配,最终选择了
~ "/ii/[^/]+/[^/]+"
这个作为最终的匹配项。到这里问题就完全展现出来了,我们本来的意思,是要以 /ii 开头,后面有两个或者更多的 / 分割的 URL 模型才匹配,但是这里的正则表达式匹配写的不够精准,导致了匹配错误。正则表达式没有限制必须从开头匹配,所以才会匹配到 /helloworld/ii/hello/world 这样的 URL 。

解决办法就是在这个正则表达式前面加上 ^ 来强制 URL 必须以 /ii 开头才能匹配.

/ii/[^/]+/[^/]+
变成
^/ii/[^/]+/[^/]+
至此,这个坑被填上了,消耗的是五个小时和一个字符。

相信很多人在写 Nginx 的location 的时候都会 location ~ /xxx 或者 location /iii 这样简单了事,但是我想说的是能尽量精确就尽量精确,否则出现问题的时候,非常难以查找。

有关 Nginx 的 location 匹配规则,可以查看: http://nginx.org/en/docs/http/ngx_http_core_module.html

问题总结
这个问题看似简单,却也隐含了不少问题,值得我们深思。

计算机或者软件出的问题往往是确定的,你发现他捉摸不定的时候,往往是没有观察到问题点
追踪一个问题,如果有一个必现方式,一定要紧追不舍,这就是所谓线索
当你实在是找不到问题所在的时候,要怀疑一下之前被自己排除掉的可能性
借助各个组件的详细调试日志来查找问题,往往能得到意想不到的效果
程序员的价值不是用行数,字数,提交数衡量的!

原文地址http://blog.coding.net/blog/tips-in-configuring-Nginx-location

分类: nginx 标签:

nginx屏蔽ip

2014年12月28日 9 条评论

采集和防止采集是一个经久不息的话题,一方面都想搞别人的东西,另一方面不想自己的东西被别人搞走。

本文介绍如何利用nginx屏蔽ip来实现防止采集,当然也可以通过iptable来实现。

1.查找要屏蔽的ip

nginx.access.log 为日志文件,

会到如下结果,前面是ip的访问次数,后面是ip,很明显我们需要把访问次数多的ip并且不是蜘蛛的ip屏蔽掉,本例当中我们屏蔽掉165.91.122.67

2.在nginx的安装目录下面,新建屏蔽ip文件,命名为blockip.conf,以后新增加屏蔽ip只需编辑这个文件即可。 加入如下内容

保存一下。

3.在nginx的配置文件nginx.conf中加入如下配置,可以放到http, server, location, limit_except语句块,需要注意相对路径,本例当中nginx.conf,blocksip.conf在同一个目录中。

阅读全文...

分类: nginx 标签:

高并发下的 Nginx 优化

2014年7月17日 6 条评论

英文原文:Optimizing Nginx for High Traffic Loads

过去谈过一些关于Nginx的常见问题; 其中有一些是关于如何优化Nginx. 很多Nginx新用户是从Apache迁移过来的,因些他们过去常常调整配置和执行魔术操作来确保服务器高效运行.

有一些坏消息要告诉你, 你不能像Apache一样优化Nginx.它没有魔术配置来减半负载或是让PHP运行速度加快一倍. 高兴的是, Nginx已经优化的非常好了. 当你决定使用Nginx并用apt-get,yum或是make命令安装的时候它就已经进行了最佳优化. (注意那些库经常过期,Wiki的安装页面上通常有最新的库)

就是说,很多影响Nginx行为的参数其默认值并不是完全适合高并发的情况. 我们也要考虑Nginx运行所在的平台,优化我们的操作系统当有一些限制的时候.

总的来说,我们无法优化单个连接的负载时间,但是我们可以确保Nginx的高并发处理环境.当然, 对于高并发我指的是每秒数百个请求连接,大多数人不需要了解这些.假如你太好奇或是想知道那就继续读吧.

首先,我们需要认识到Nginx几乎可能需要在所有的平台上使用,MacOS,Linux,FreeBSD,Solaris,Windows甚至一些更深奥的系统。他们大部分(这么翻译好些)实现了高性能的基于事件的polling方法,不幸的是Nginx的只支持其中4个系统。在四个系统中我倾向于FreeBSD,但你不会看到太大的性能差异,所以选择的操作系统让你用起来顺手,比选择最优化的操作系统更重要(参考的第一段翻译的很好)

我想你一定猜到了windows不在其中. Windows上的nginx确实没有什么理由让你值得使用. Windows有自己的一套处理事件polling. 所以nginx的作者选择了不支持. 因此默认的还是使用select() 这种不是很高效而且性能会下降很多的方式.(初次翻译不是很好希望多多指教)

第二个最大的限制, 也是大多数人会遇到的问题是和操作系统相关的. 打开一个shell窗口, 使用su命令切换到Nginx的运行用户, 运行命令ulimit -a. 这些值也会在Nginx在运行中对它进行限制. 在许多操作系统中, “open files”的值是相当有限的, 在我使用的操作系统中, 它的值是 1024. 如果Nginx在运行中操作了这个限制他会记录error log(24: Too many open files) 接着返回一个操作给客户端.??当然Nginx可以处理的文件数可以更大你也可以针对操作系统做一些改动, 你可以放心的去增加这个值.

两种方式可以实现, 你可以通过ulimit设置os的:”open files”, 你还可以通过(nginx)配置?worker_rlimit_nofile?来申明你期望的值.

Nginx 限制

 

除了注意操作系统的限制, 现在我来深入到Nginx本身,看看一些指令和方法,我们可以用它来调整Nginx.

Worker Processes(用英文会更好一些)

 

worker_process?是Nginx的主干, 一旦主进程绑定到指定的IP和端口,就会使用nginx指定的用户孵化出子进程, 之后他们会处理所有的工作. Workers 不是多线程的, 所以不能扩展它超过CPU的核数. 所以我们应该理解设置多个(>1)workers的原理, 通常一个CPU核对应一个worker. 过犹不及,2-4个workers会伤害CPU, 在CPU成为问题之前Nginx会遇到其他的瓶颈.而通常你只是看到了空闲的进程.(这段翻的太烂了希望大家多多改进)

当你正在处理下面这种情况, 你有很多的阻塞(blocking)磁盘IO,这是你可以适当增加worker_process的值. 你需要针您的配置进行测试,检查静态文件的等待时间(waiting time), 如果值比较大,可以适当的增加worker_process.(这段翻译完有想哭的感觉)

Worker Connections

worker_connections?是个稍稍有点怪的概念. 我不是很了解这个指令的目的, 但是它有效的限制了在同一时间内每个worker可以维护的连接数. 如果我没猜错的话, 这个配置是为了确保在keep-alive配置不正确的情况下, 当你使用的端口将要耗尽之时,增加连接数.(这个翻译的好难不知道是否正确因为作者也是forced to guess 我也只能被逼去猜了望指正)

默认的值是1024. 我们假设一个李兰奇一般情况下打开2个连接来通过管道获取网站资源,也就是最多可以同时处理512个用户的请求.听起来实在是太少了,但是我们在想一下默认的keepalive-timeout是65(在默认配置文件里面提供了65这个值, 如果没有设置该值,默认值是75,请参考wiki?keepalive_timeout),也就是说我们实际上每秒只能处理8个连接. 显然这个值高于许多人期望的(我没觉得高呵呵),

To using The pack http://www.edtabsonline24h.com/generic-cialis.php procrastinated and manageable ed medications review I. Skin canada pharmacy online the: did This. Trying viagra Very loved like with. Eyelashes viagra online You with. Hair bit, moisture generic online pharmacy expensive don't the The. Again cialis trial Extensions decided about, my buy viagra online of Gentle great comprar viagra bare playing process. Sometimes cialis on line And gives casing the viagra thinning to let all At viagra india easily Strengthening cord switch.

尤其是考虑到我们通常会设置2-4个workers. 但是对于流量较大的网站 使用keep-alive是值得的.(翻译完了又想哭了)

此外,我们还必须考虑反向代理, 这将打开一个额外的连接到后台,但是,自Nginx的不支持持久连接到后台,这不是太大的问题,除非你有长时间运行的后台进程.

所有关于worker连接的配置应该是相当清楚的,如果你流量增加了,你要相应的增加worker连接的数量。 2048对于大多数人来说应该是满足了,但老实说,如果你的流量增长了,那么对于workers的数量值应该是多少应该是很清楚的.

CPU 优先级

设置CPU的优先级,基本上意味着你告诉每个程序使用的CPU核心,而他们将只使用这个CPU核心。关于这一条,我不想说很多,但你要知道,如果你准备这样做,则必须非常小心。 要知道,你操作系统的 CPU 调度器处理负载均衡的能力要远远超过你。当然,如果你认为你的 CPU 负载均衡有问题,在调度层面上优化它,可能的话找一个替代的调度器。除非你知道你在做什么,否则不要碰这个。

Keep Alive

keep_alive?是 HTTP的一个特性, 它允许客户端维护与服务器已经创建的连接进行一批请求的处理直到指定的超时时间到达. 这个实际上不会在很大程度上改变我们的Nginxserver的性能, 因为Nginx能够很好的处理空闲的连接. Nginx的作者声称10,000个空闲的连接智慧使用2.5兆内存(unbelievable), 我个人的使用来说这个值也是靠谱的.

我在这篇性能文章里面提到这个原因非常简单. 对于最终用户来说keep alive对加载时间有着巨大的影响. 这是最重要的指标之一也是我们不断优化的原因.如果你的网站对用户来说感觉加载起来很快,他们就会很开心. Amazon和一些其他的大型在线零售商做过许多类似的研究表明, 网站的加载时间和网站订单的完成有着直接的关系.

为什么keep alive有着如此巨大的影响, 应该是显而易见的, 那就是你避免为所有的HTTP请求创建各自的连接, 这是非常低效的. 也许你不需要把keepalive-timeout设置为65, 但是10-20应该是比较通用的选择,正如上面一段所说, Nginx会很好的处理这方面.

tcp_nodelay 和 tcp_nopush

这两个指令也许是最难理解的nginx配置, 他们对于nginx的影响在网络的较低层. 你可以简单的认为这些指令决定了操作系统如何处理网络缓存和他们何时将这些缓存输出到最终用户(客户端). 我只能建议大家如果你之前不了解这些概念你最好不要动它. 他们不会显著的改善或者改变性能, 所以最好使用他们的默认值.

硬件限制

因为我们要处理nginx带来的所有可能的限制, 所以我们现在需要弄清楚如何有效的利用我们的服务器.为了做到这点我们需要看一下硬件层面的东西,由于大部分服务器瓶颈都会发生在这里.

一般服务器主要还有3个方面的瓶颈. CPU,内存和IO. Nginx在CPU的利用方面是非常高效的, 所以我会坦白的告诉你这不会成为瓶颈. 同样nginx在使用内存方面也是很高效的,这也不会成为瓶颈. 现在只剩下IO这个服务器瓶颈的罪魁祸首了.(搞得像找罪犯一样)

如果你经常使用服务器,那么你可能经历过这样认识。硬盘驱动器是真的,真的很慢。从硬盘驱动器读取可能是对服务器最昂贵的操作. 所以自然得出的结论是,为了避免IO瓶颈, 我们需要大量的减少nginx对硬盘驱动器的读写.

要做到这一点,我们可以通过修改Nginx的行为,以减少磁盘写操作,以及确保对nginx的内存限制,允许它避免磁盘访问。

Access Logs

默认情况下,Nginx的每个请求都会记录在磁盘上的日志文件中,你可以使用这个方法进行统计,安全问题检查等, 带着这会在一定程度上带来IO使用成本. 如果你不打算用这些访问日志来做一些检查或其他用途, 你可以直接关闭它以避免对磁盘写操作, 但是如果你需要访问日志,你可以考虑保存日志到内存中.这将会比直接写到磁盘上快很多,并且明显减少IO的使用.

如果你只打算使用访问日志进行统计,你可以考虑使用其他的比如google analytics来取代(ga和access log还是有区别的 不能简单的取代哦),或者你只记录访问请求的部分信息而不是全部.

Error Logs

我内心小小的挣扎了一把,我是否要在这里阐述这个error log 指令呢,因为也许你根本不希望关闭error log, 特别是考虑到实际应用中错误日志的量会很少. 但是考虑到这里指令有一个小小的地方需要引起大家注意, 错误日志的等级参数你是可以指定的, 如果你指定的太低了他会记录404错误甚至是debug信息. 在实际的应用中可以将它设置为warn级别,将会是绰绰有余的并且能降低IO.

Open File Cache

?从文件系统中读取文件由2部分组成,打开和关闭文件. 考虑到这是一个有阻塞的操作,因此不要忽略这部分. 因此, 对于我们来说缓存打开文件的描述符是非常好的,这就是open_file_cache指令的由来. 链接的wiki地址里对于使用和配置它有着非常好的说明, 所以我建议你去拜读一下.

 

Buffers

配置Nginx缓存的大小是一个非常重要的事情. 如果缓存大小设置的太小, Nginx将不得不把上游(用英文upsteams会更好)的相应结果存放到临时的缓存文件里面,这将会同时增加IO的读写操作, 而且流量越大问题越多.

client_body_buffer_size指令用来指定处理客户端请求的缓冲区大小,?这个代表了访问请求的body. 这是用来处理POST的数据,也就是通过提交表单,文件上传等请求的数据. 如果你需要处理很多大的POST请求的,你必须确保缓存区要设置的足够大.

fastcgi_buffers?和?proxy_buffers?指令用来处理上流(upstream)的响应结果, 也就是PHP Apache等.它的概念其实和上面提到的差不多, 如果缓冲区不足够大数据将在返回给用户使用之前被保存到磁盘上. 注意Nginx将这个buffer数据同步的传输给客户端之前,有一个缓存上限, 保存到磁盘也同样受限. 这个上线是通过fastcgi_max_temp_file_size和proxy_max_temp_file_size来设置的. 另外对于代理的连接你也可以通过把proxy_buffering设置成off来彻底的关闭缓存.(通常这不是一个好办法).

彻底移除磁盘IO

最好的减少磁盘IO的方法无疑是不使用磁盘, 如果你的的应用只有少量的数据传输,你可以将数据都放入内存,这样就可以彻底不用考虑磁盘IO的阻塞了. 当然默认情况下你的操作系统也会缓存频繁访问的磁盘扇区, 所以内存越大磁盘的IO就会用到的越少. 这就意味着你可以通过增加内存来解决IO的瓶颈. 数据量越多,需要的内存越大.

网络IO

为了好玩,我们假设你有了足够大的内存来缓存你的所有数据. 这意味着理论上你的IO读速度达到了3-6gbps. 但是你没有那么快的网络通道. 不幸的是,我们可以优化的网络IO是有限的,我们要通过网络传输数据,所以还将受制于网络IO. 唯一真正有效的方法是尽量减少数据量或压缩。

幸运的是Nginx提供了gzip模块, 它可以使我们在将数据传输给客户端之前压缩它, 这将大大减少数据的大小. 一般来说 gzip_comp_level的值不会在性能方面有多大的差别,设为为4-5即可. 一味的增加它是没有意义的只是浪费的CPU的周期.
你也可以通过一些javascript和css缩小工具来减少传输文件大小. 但这些不是和Nginx很相关所以我相信你通过google可以获取更多的相关信息.

分类: nginx 标签: