Tomcat和Nginx一步到位

最新推荐文章于 2023-06-09 22:54:51 发布

wangxudongx

最新推荐文章于 2023-06-09 22:54:51 发布

阅读量824

点赞数

文章标签： nginx tomcat 运维服务器

本文链接：https://blog.csdn.net/wangxudongx/article/details/102646036

版权

Tomcat和Nginx

Tomcat

Tomcat 服务器是一个免费的开放源代码的Web应用服务器，属于轻量级应用服务器，在中小型系统和并发访问用户不是很多的场合下被普遍使用，是开发和调试JSP程序的首选。对于一个初学者来说，可以这样认为，当在一台机器上配置好Apache服务器，可利用它响应HTML（标准通用标记语言下的一个应用）页面的访问请求。实际上Tomcat是Apache服务器的扩展，但运行时它是独立运行的，所以当你运行tomcat 时，它实际上作为一个与Apache 独立的进程单独运行的。
诀窍是，当配置正确时，Apache 为HTML页面服务，而Tomcat 实际上运行JSP
页面和Servlet。另外，Tomcat和IIS等Web服务器一样，具有处理HTML页面的功能，另外它还是一个Servlet和JSP容器，独立的Servlet容器是Tomcat的默认模式。不过，Tomcat处理静态HTML的能力不如Apache服务器。
Tomcat很受广大程序员的喜欢，因为它运行时占用的系统资源小，扩展性好，支持负载平衡与邮件服务等开发应用系统常用的功能；而且它还在不断的改进和完善中，任何一个感兴趣的程序员都可以更改它或在其中加入新的功能。

此博客是在Tomcat8.5、Nginx1.16版本下实施。

打开manager

这里的manager是tomcat的控制台，可以对tomcat的状态进行监控、deploy应用等，使用需要做些操作。

配置访问manager的IP白名单

配置

/usr/local/apache-tomcat-8.5.45/conf/Catalina/localhost

下的
manager.xml （没有就新建一个）

<?xml version="1.0" encoding="UTF-8"?>
<Context privileged="true" antiResourceLocking="false"
             docBase="${catalina.home}/webapps/manager">
                 <Valve className="org.apache.catalina.valves.RemoteAddrValve" allow="^.*$" />
             </Context>

配置访问manager的用户

配置/usr/local/apache-tomcat-8.5.45/conf
下的
tomcat-users.xml

<role rolename="manager-gui"/>
<role rolename="manager-script"/>
<role rolename="manager-jmx"/>
<role rolename="manager-status"/>
<role rolename="admin-gui"/>
<role rolename="admin-script"/>

<user username="admin" password="admin" roles="manager-gui,manager-script,manager-jmx,manager-status,admin-gui,admin-script"/>
<user username="deploy" password="deploy" roles="manager-script"/>

访问manager

游览器访问：http://192.168.91.129:8080/manager
在这里插入图片描述

调整manager部署时上传文件大小限制

在webapps/manager/WEB-INF路径下
修改web.xml
默认上传文件的大小50MB
在这里插入图片描述
此时调整为：1GB

调整catalina的jvm内存大小

catalina.sh里面的配置都是在运行时加载的，算是运行时调优。

配置参数

配置：/usr/local/apache-tomcat-8.5.45/bin
下的
setenv.sh（没有则新建）

#!/bin/bash

export CATALINA_OPTS="$CATALINA_OPTS -server" 

export CATALINA_OPTS="$CATALINA_OPTS -Xms256m"

export CATALINA_OPTS="$CATALINA_OPTS -Xmx256m"

export CATALINA_OPTS="$CATALINA_OPTS -XX:MaxPermSize=128m"

检测配置

使用：

./catalina.sh run

检测配置是否生效
在这里插入图片描述

调整HTTP接收post请求的最大size

maxPostSize 指定post请求的最大大小，超过限制将会报http请求异常；
默认2MB 既：2097152
指定为-1则是没有限制；
大多数情况下都是因为上传文件操作调整这个参数。

    <Connector port="8926" protocol="HTTP/1.1"
               connectionTimeout="20000"
               redirectPort="8443" maxPostSize="2097152" />

Tomcat线程调整

    <!--The connectors can use a shared executor, you can define one or more named thread pools-->
    <!--  声明一个线程池
    <Executor name="tomcatThreadPool" namePrefix="catalina-exec-"
        maxThreads="150" minSpareThreads="4"/>
    -->
    
    <!-- A "Connector" using the shared thread pool-->
    <!-- 使用线程池的Connector
    <Connector executor="tomcatThreadPool"
               port="8080" protocol="HTTP/1.1"
               connectionTimeout="20000"
               redirectPort="8443"
               acceptCount="1000" 
     />
    -->

Http/1.1 Connector提供的配置项：

URIEncoding URI字节转化成String的时候的编码方式，默认为ISO-8859-1，如果页面需要支持中文，一般可以将其设置为UTF-8或者GBK,GB2312。

maxPostSize POST方法能够提交的数据的最大大小，如果没有声明或者设置为小于等于0，则表示POST提交的数据大小是不限制的，默认值是2Megabytes.

acceptCount 等待队列的长度，默认值是100。

connectionTimeout Connector接受一个连接后等待的时间(milliseconds)，默认值是20000。

keepAliveTimeout 在Connector关闭连接前，Connector为另外一个请求Keep Alive所等待的微妙数，默认值和 connectionTimeout 一样。

更多线程配置请看》

Executor的主要属性包括：

name：该线程池的标记
maxThreads：线程池中最大活跃线程数，默认值200（Tomcat7和8都是）
minSpareThreads：线程池中保持的最小线程数，最小值是25
maxIdleTime：线程空闲的最大时间，当空闲超过该值时关闭线程（除非线程数小于minSpareThreads），单位是ms，默认值60000（1分钟）
daemon：是否后台线程，默认值true
threadPriority：线程优先级，默认值5
namePrefix：线程名字的前缀，线程池中线程名字为：namePrefix+线程编号

catalina的IO优化

tomcat有四种IO模式可供选择：
BIO：同步阻塞
NIO：同步非阻塞
NIO２（AIO）：异步阻塞
APR：

Connector的protocol选择

Tomcat8.5有四种Protocol可供选择：
HTTP/1.1
NIO
NIO2
APR

指定的protocol取值及对应的协议如下：

HTTP/1.1：默认值，使用的协议与Tomcat版本有关

org.apache.coyote.http11.Http11Protocol：BIO

org.apache.coyote.http11.Http11NioProtocol：NIO

org.apache.coyote.http11.Http11Nio2Protocol：NIO2

org.apache.coyote.http11.Http11AprProtocol：APR

如果没有指定protocol，则使用默认值HTTP/1.1，其含义如下：在Tomcat7中，自动选取使用BIO或APR(如果找到APR需要的本地库，则使用APR，否则使用BIO);在Tomcat8中，自动选取使用NIO或APR(如果找到APR需要的本地库，则使用APR，否则使用NIO)。

使用NIO2 Protocol

在 conf/server.xml 更改配置

<Connector port="8080" protocol="org.apache.coyote.http11.Http11Nio2Protocol"
                connectionTimeout="20000"
                redirectPort="8443" />

使用

./catalina.sh run

测试配置。
在这里插入图片描述

使用APR

Tomcat可以使用Apache Portable Runtime来提供卓越的性能及可扩展性，更好地与本地服务器技术的集成。Apache Portable Runtime是一个高度可移植的库，位于Apache HTTP Server 2.x的核心。APR有许多用途，包括访问高级IO功能（如sendfile，epoll和OpenSSL），操作系统级功能（随机数生成，系统状态等）以及本地进程处理（共享内存，NT管道和Unix套接字）。
这些功能不仅仅是一个后端集中的技术，还可以让Tomcat成为通用的网络服务器，可以实现与本地的其他Web技术更好的集成，并使Java成为一个完整的网络服务器平台。

环境准备

openssl-devel
apr-devel
gcc
make

编译tomcat-native

在tomcat的bin目录下

tar -zxvf tomcat-native.tar.gz

切换到

apache-tomcat-8.5.45/bin/tomcat-native-1.2.23-src/native

编译tomcat-native

./configure && make && make install

安装完成之后

----------------------------------------------------------------------
Libraries have been installed in:
   /usr/local/apr/lib

If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use the `-LLIBDIR'
flag during linking and do at least one of the following:
   - add LIBDIR to the `LD_LIBRARY_PATH' environment variable
     during execution
   - add LIBDIR to the `LD_RUN_PATH' environment variable
     during linking
   - use the `-Wl,-rpath -Wl,LIBDIR' linker flag
   - have your system administrator add LIBDIR to `/etc/ld.so.conf'

See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.
----------------------------------------------------------------------

setenv.sh配置

JAVA_OPTS="$JAVA_OPTS -Djava.library.path=/usr/local/apr/lib"

setclasspath.sh 配置

在tomcat/bin/下的
setclasspath.sh 的最后添加

LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$CATALINA_HOME/lib
export LD_LIBRARY_PATH

server.xml配置

 <Connector port="8080" protocol="org.apache.coyote.http11.Http11AprProtocol"
 70                connectionTimeout="20000"
 71                redirectPort="8443" />
 72     # 企业apr生命周期监听器（不使用SSL）
 73     <Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="off" />

成功启动日志。
在这里插入图片描述

Tomcat8.5下的Session共享

Tomcat8.5 实现Session共享有两种常用方案：

Tomcat Cluster 方案，这个是tomcat内置方案。
Redis管理Session方案。

Tomcat Cluster共享session

第一个特别需要强调的是，Tomcat cluster只适合同一台机器上的tomcat，而且要项目名称一致。这个两个条件，缺一不可。
这种方式实际上就是组播模式。
tomcat间是以IP组播发送变更的数据，将数据发送到集群组的其他成员。这个IP就是那个228.0.0.4。

Tomcat Cluster共享Session的方案应用场景太窄，就不说了。

如果这个方案符合自己业务的应用场景大家可以参考这篇博客。》Session共享（一） tomcat 自带集群session共享实现

Redis管理Session

所需jar可以在此下载》tomcat85-redis-session

依赖库准备

需要准备3个jar包，放到tomcat/lib目录下。

commons-pool2-2.2.jar
jedis-2.5.2.jar
tomcat8.5-redis-session-manager.jar

Tomcat8.5上下文配置

增加tomcat/conf/context.xml配置。

<Valve className="com.s.tomcat.redissessions.RedisSessionHandlerValve"/>
<Manager className="com.s.tomcat.redissessions.RedisSessionManager" 
                  host="127.0.0.1"
                  port="6379"
                  database="0" 
                  password="123456"
                  maxInactiveInterval="60" />
<!-- redis有设置AUTH（密码），这里需要加password，没有设置AUTH就不用加password。 -->

部署webapp

验证session共享至少需要部署两个tomcat。
在这里插入图片描述
将仓库里web下的东西部署到tomcat/webapp下（如：ROOT）

两个tomcat都部署好之后开始验证。

验证session共享

依次启动两个tomcat8.5
此时应该看到如下日志：

com.s.tomcat.redissessions.RedisSessionManager.startInternal Attached to RedisSessionHandlerValve
com.s.tomcat.redissessions.RedisSessionManager.initializeSerializer Attempting to use serializer :com.s.tomcat.redissessions.JavaSerializer
com.s.tomcat.redissessions.RedisSessionManager.startInternal Will expire sessions after 1800 seconds

代表tomcat85-redis-session库加载成功。

开始测试

1、访问站点A的index2.jsp
在这里插入图片描述
2、访问站点B的index2.jsp

3、访问站点A的index.jsp（写内容到session域里）

4、再去访问站点B的index2.jsp

全程两个站点的session id 是一个，在A站session域里写的内容在B站也能读到，可得知验证成功。

Idea远程调试Tomcat

首先在start.sh加入一条配置（以8000端口打开调试）：

declare -x CATALINA_OPTS="-server -Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=8000"

Idea配置
在这里插入图片描述

在这里插入图片描述

Tomcat启动异常日志"AjpMessage.processHeader Invalid message received with signature"

异常日志：

02-Nov-2020 10:45:22.180 SEVERE [ajp-nio-8919-exec-9] org.apache.coyote.ajp.AjpMessage.processHeader Invalid message received with signature [18501]
02-Nov-2020 10:45:22.189 SEVERE [ajp-nio-8919-exec-5] org.apache.coyote.ajp.AjpMessage.processHeader Invalid message received with signature [18501]
02-Nov-2020 10:45:22.209 SEVERE [ajp-nio-8919-exec-10] org.apache.coyote.ajp.AjpMessage.processHeader Invalid message received with signature [18501]
02-Nov-2020 10:45:22.434 SEVERE [ajp-nio-8919-exec-11] org.apache.coyote.ajp.AjpMessage.processHeader Invalid message received with signature [18501]
02-Nov-2020 10:45:22.622 SEVERE [ajp-nio-8919-exec-37] org.apache.coyote.ajp.AjpMessage.processHeader Invalid message received with signature [18501]
02-Nov-2020 10:45:22.667 SEVERE [ajp-nio-8919-exec-12] org.apache.coyote.ajp.AjpMessage.processHeader Invalid message received with signature [18501]
02-Nov-2020 10:45:22.839 SEVERE [ajp-nio-8919-exec-14] org.apache.coyote.ajp.AjpMessage.processHeader Invalid message received with signature [18501]
02-Nov-2020 10:45:23.359 SEVERE [ajp-nio-8919-exec-15] org.apache.coyote.ajp.AjpMessage.processHeader Invalid message received with signature [18501]
02-Nov-2020 10:45:23.369 SEVERE [ajp-nio-8919-exec-16] org.apache.coyote.ajp.AjpMessage.processHeader Invalid message received with signature [18501]
02-Nov-2020 10:45:23.558 SEVERE [ajp-nio-8919-exec-17] org.apache.coyote.ajp.AjpMessage.processHeader Invalid message received with signature [18501]
02-Nov-2020 10:45:23.621 SEVERE [ajp-nio-8919-exec-18] org.apache.coyote.ajp.AjpMessage.processHeader Invalid message received with signature [18501]

原因：

AJP缺address配置项

<Connector port="8919" protocol="AJP/1.3" redirectPort="8939" />

解决方法：

<Connector port="8919" protocol="AJP/1.3" address="127.0.0.1" redirectPort="8939" />

Nginx

Nginx（发音同 engine x）是一款轻量级的 Web 服务器/反向代理服务器及电子邮件（IMAP/POP3）代理服务器，并在一个BSD-like 协议下发行，可以在 UNIX、GNU/Linux、BSD、Mac OS X、Solaris，以及 Microsoft Windows 等操作系统中运行。
Nginx 由俄罗斯的程序设计师 Igor Sysoev 所开发，最初供俄国大型的入口网站及搜寻引擎 Rambler（俄文：Рамблер）使用。其特点是占有内存少，并发能力强（用于解决 C10K 问题），事实上 nginx 的并发能力确实在同类型的网页服务器器中表现较好。
Nginx 是一款面向性能设计的 HTTP 服务器，相较于 Apache、lighttpd 具有占有内存少，稳定性高等优势。与旧版本（<=2.2）的 Apache 不同，nginx 不采用每客户机一线程的设计模型，而是充分使用异步逻辑，削减了上下文调度开销，所以并发服务能力更强。整体采用模块化设计，有丰富的模块库和第三方模块库，配置灵活。在 Linux 操作系统下，nginx 使用 epoll 事件模型，得益于此，nginx 在 Linux 操作系统下效率相当高。同时 Nginx在OpenBSD 或 FreeBSD 操作系统上采用类似于 epoll 的高效事件模型 kqueue。
Nginx 可大量平行处理。在官方测试的结果中，能够支持五万个平行连接，而在实际的运作中，可以支持二万至四万个平行链接。

此博客是在Tomcat8.5、Nginx1.16版本下实施。

Nginx官方手册

Nginx中文参考文档

Nginx中文文档

Nginx1.16安装

CentOS下安装nginx有两种途径：
yum
源码安装

首先把nginx依赖组件都装上

yum install gcc zlib zlib-devel pcre-devel openssl openssl-devel

yum安装

yum install nginx

源码安装

从官网下载nginx源码包》 nginx官网下载页

解压包

nginx-1.16.1.tar.gz

然后到/root/nginx-1.16.1目录：

  ./configure  --prefix=/usr/local/nginx --sbin-path=/usr/local/nginx/nginx --conf-path=/usr/local/nginx/nginx.conf --pid-path=/usr/local/nginx/nginx.pid

在这里插入图片描述

make && make install

负载均衡

轮询

一个简单的负载均衡的示例，把www.domain.com均衡到本机不同的端口，也可以改为均衡到不同的地址上。
http {
: upstream myproject {
: server 127.0.0.1:8000 weight=3;
: server 127.0.0.1:8001;
: server 127.0.0.1:8002;
: server 127.0.0.1:8003;
: }

: server {
: listen 80;
: server_name www.domain.com;
: location / {
: proxy_pass http://myproject;
: }
: }
}

权重

 upstream cluster {
	  server	127.0.0.1:18080	weight=1;
	  server	127.0.0.1:28080	weight=2;
	}

ip_hash

Nginx中的ip_hash技术能够将某个ip 的请求定向到同一台后端web机器中,这样一来这个ip 下的客户端和某个后端 web机器就能建立起稳固的session.

ip_hash机制能够让某一客户机在相当长的一段时间内只访问固定的后端的某台真实的web服务器,这样会话就会得以保持,在网站页面进行login的时候就不会在后面的web服务器之间跳来跳去了,也不会出现登录一次的网站又提醒重新登录的情况.

Ip_hash是在upstream配置中定义的:

upstream nginx.example.com{

server 192.168.74.235:80;
server 192.168.74.236:80;

ip_hash;
}

Ip_hash机制缺陷:

(1).nginx不是最前端的服务器

ip_hash要求nginx一定是最前端的服务器,否则nginx得不到正确ip,就不能根据ip作hash. Eg: 使用的是squid为最前端.那么nginx取ip时只能得到squid的服务器ip地址,用这个地址来作分流肯定是错乱的

(2).nginx的后端还有其它负载均衡

假如nginx后端还有其它负载均衡,将请求又通过另外的方式分流了,那么某个客户端的请求肯定不能定位到同一台session应用服务器上,这么算起来,nginx后端只能直接指向应用服务器,或者再搭一人squid,然后指向应用服务器. 最好的办法是用location作一次分流,将需要session的部分请求通过ip_hash分流,剩下的走其它后端去.

url_hash

upstream backend {
    hash $request_uri consistent;
    server backend1.example.com;
    server backend2.example.com;
}

fair

nginx-upstream-fair 这个三方模块最后一次更新是11年前，经测试官方仓库与新版nginx不再兼容了。此时需要修改源码重新编译才能给nginx1.14以后的版本使用

nginx1.16 版本选择我给大家准备编译之后的版本-支持nginx1.16，其它版本未知。
nginx1.16-upstream-fair-module

nginx1.14之前 的版本选择下载fair第三方模块》nginx-upstream-fair

fair采用的不是内建负载均衡使用的轮换的均衡算法，而是可以根据页面大小、加载时间长短智能的进行负载均衡。

Installation:

–

./configure  --prefix=/usr/local/nginx --sbin-path=/usr/local/nginx/nginx --conf-path=/usr/local/nginx/nginx.conf --pid-path=/usr/local/nginx/nginx.pid  --add-module=/root/nginx-upstream-fair-master

在这里插入图片描述

未安装nginx、想覆盖之前安装的nginx：

make && make install

在这里插入图片描述

已安装nginx并不想完全覆盖此前的安装：

make

安装完之后转到nginx安装目录

./nginx -V

在这里插入图片描述
可以看到 fair 模块已经被安装。

Usage:

–

Change your Nginx config file’s upstream block to include the ‘fair’ directive:

upstream mongrel {
    fair;
    server 127.0.0.1:5000;
    server 127.0.0.1:5001;
    server 127.0.0.1:5002;
  }

淘宝团队使用的nginx负载均衡节点健康检查模块

nginx_upstream_check_module 更专业的负载均衡器内节点的健康检查。这个由淘宝技术团队开发的 nginx 模块 nginx_upstream_check_module，通过它可以用来检测后端 realserver 的健康状态。如果后端 realserver 不可用，则所有的请求就不会转发到该节点上。

这个模块的装配请大家参考这位博主的文章》 Nginx安装负载均衡配置 fair check扩展

请求转发

不携带header

       location / {
            proxy_pass       http://cluster;
            proxy_redirect   default;
        }

携带header

      location  /pdemo/ {
            proxy_pass  http://127.0.0.1:8080;
            proxy_set_header   Host             $host;
            proxy_set_header   X-Real-IP        $remote_addr;
            proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
        }

拼接request

      location  /ppdemo/ {
            proxy_pass  http://172.19.202.223:8080/demo/Temp.do?insideCode=$request_uri;
            proxy_set_header   Host             $host;
            proxy_set_header   X-Real-IP        $remote_addr;
            proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
        }

动静分离

    #拦截后台请求
      location / {
        proxy_pass http://localhost:8888;
        proxy_set_header X-Real-IP $remote_addr;
      }

      #拦截静态资源
      location ~ .*\.(html|htm|gif|jpg|jpeg|bmp|png|ico|js|css)$ {
        root /Users/dalaoyang/Downloads/static;
       }

    }

}

配置调优

Nginx运行工作进程数量

Nginx运行工作进程个数一般设置CPU的核心或者核心数x2。如果不了解cpu的核数，可以top命令之后按1看出来，也可以查看/proc/cpuinfo文件 grep ^processor /proc/cpuinfo | wc -l

[root@lx~]# vi/usr/local/nginx1.10/conf/nginx.conf

worker_processes 4;

[root@lx~]# /usr/local/nginx1.10/sbin/nginx-s reload
[root@lx~]# ps -aux | grep nginx |grep -v grep
root 9834 0.0 0.0 47556 1948 ?     Ss 22:36 0:00 nginx: master processnginx
www 10135 0.0 0.0 50088 2004 ?       S   22:58 0:00 nginx: worker process
www 10136 0.0 0.0 50088 2004 ?       S   22:58 0:00 nginx: worker process
www 10137 0.0 0.0 50088 2004 ?       S   22:58 0:00 nginx: worker process
www 10138 0.0 0.0 50088 2004 ?       S   22:58 0:00 nginx: worker process

Nginx运行CPU亲和力

比如4核配置：

worker_processes 4;
worker_cpu_affinity 0001 0010 0100 1000

比如8核配置：

worker_processes 8;
worker_cpu_affinity 00000001 00000010 00000100 0000100000010000 00100000 01000000 10000000;

worker_processes最多开启8个，8个以上性能提升不会再提升了，而且稳定性变得更低，所以8个进程够用了。

Nginx最大打开文件数

worker_rlimit_nofile 65535;

这个指令是指当一个nginx进程打开的最多文件描述符数目，理论值应该是最多打开文件数（ulimit -n）与nginx进程数相除，但是nginx分配请求并不是那么均匀，所以最好与ulimit -n的值保持一致。

注：文件资源限制的配置可以在/etc/security/limits.conf设置，针对root/user等各个用户或者*代表所有用户来设置。

soft nofile 65535
hard nofile 65535
用户重新登录生效（ulimit -n）

Nginx事件处理模型

events {
  use epoll;
  worker_connections 65535;
  multi_accept on;
}

nginx采用epoll事件模型，处理效率高。

work_connections是单个worker进程允许客户端最大连接数，这个数值一般根据服务器性能和内存来制定，实际最大值就是worker进程数乘以work_connections。

实际我们填入一个65535，足够了，这些都算并发值，一个网站的并发达到这么大的数量，也算一个大站了！

multi_accept 告诉nginx收到一个新连接通知后接受尽可能多的连接，默认是on，设置为on后，多个worker按串行方式来处理连接，也就是一个连接只有一个worker被唤醒，其他的处于休眠状态，设置为off后，多个worker按并行方式来处理连接，也就是一个连接会唤醒所有的worker，直到连接分配完毕，没有取得连接的继续休眠。当你的服务器连接数不多时，开启这个参数会让负载有一定的降低，但是当服务器的吞吐量很大时，为了效率，可以关闭这个参数。

开启高效传输模式

http {
  include mime.types;
  default_type application/octet-stream;
  ……

  sendfile on;
  tcp_nopush on;
  ……
}

Include mime.types ：媒体类型,include 只是一个在当前文件中包含另一个文件内容的指令。

default_type application/octet-stream ：默认媒体类型足够。

sendfile on：开启高效文件传输模式，sendfile指令指定nginx是否调用sendfile函数来输出文件，对于普通应用设为 on，如果用来进行下载等应用磁盘IO重负载应用，可设置为off，以平衡磁盘与网络I/O处理速度，降低系统的负载。注意：如果图片显示不正常把这个改成off。

tcp_nopush on：必须在sendfile开启模式才有效，防止网路阻塞，积极的减少网络报文段的数量（将响应头和正文的开始部分一起发送，而不一个接一个的发送。）

主要目的是保护服务器资源，CPU，内存，控制连接数，因为建立连接也是需要消耗资源的。

keepalive_timeout 60;
tcp_nodelay on;
client_header_buffer_size 4k;
open_file_cache max=102400 inactive=20s;
open_file_cache_valid 30s;
open_file_cache_min_uses 1;
client_header_timeout 15;
client_body_timeout 15;
reset_timedout_connection on;
send_timeout 15;
server_tokens off;
client_max_body_size 10m;

keepalived_timeout ：客户端连接保持会话超时时间，超过这个时间，服务器断开这个链接。

tcp_nodelay：也是防止网络阻塞，不过要包涵在keepalived参数才有效。

client_header_buffer_size 4k：客户端请求头部的缓冲区大小，这个可以根据你的系统分页大小来设置，一般一个请求头的大小不会超过 1k，不过由于一般系统分页都要大于1k，所以这里设置为分页大小。分页大小可以用命令getconf PAGESIZE取得。

open_file_cache max=102400 inactive=20s ：这个将为打开文件指定缓存，默认是没有启用的，max指定缓存数量，建议和打开文件数一致，inactive 是指经过多长时间文件没被请求后删除缓存。

open_file_cache_valid 30s：这个是指多长时间检查一次缓存的有效信息。

open_file_cache_min_uses 1 ：open_file_cache指令中的inactive 参数时间内文件的最少使用次数，如果超过这个数字，文件描述符一直是在缓存中打开的，如上例，如果有一个文件在inactive 时间内一次没被使用，它将被移除。

client_header_timeout ：设置请求头的超时时间。我们也可以把这个设置低些，如果超过这个时间没有发送任何数据，nginx将返回request time out的错误。

client_body_timeout设置请求体的超时时间。我们也可以把这个设置低些，超过这个时间没有发送任何数据，和上面一样的错误提示。

reset_timeout_connection ：告诉nginx关闭不响应的客户端连接。这将会释放那个客户端所占有的内存空间。

send_timeout ：响应客户端超时时间，这个超时时间仅限于两个活动之间的时间，如果超过这个时间，客户端没有任何活动，nginx关闭连接。

server_tokens ：并不会让nginx执行的速度更快，但它可以关闭在错误页面中的nginx版本数字，这样对于安全性是有好处的。

client_max_body_size：上传文件大小限制。

gzip 调优

使用gzip压缩功能，可能为我们节约带宽，加快传输速度，有更好的体验，也为我们节约成本，所以说这是一个重点。

Nginx启用压缩功能需要你来ngx_http_gzip_module模块，apache使用的是mod_deflate。

一般我们需要压缩的内容有：文本，js，html，css，对于图片，视频，flash什么的不压缩，同时也要注意，我们使用gzip的功能是需要消耗CPU的！

gzip on;
gzip_min_length 2k;
gzip_buffers   4 32k;
gzip_http_version 1.1;
gzip_comp_level 6;
gzip_typestext/plain text/css text/javascriptapplication/json application/javascript application/x-javascriptapplication/xml;
gzip_vary on;
gzip_proxied any;

gzip on; #开启压缩功能
gzip_min_length 1k ：设置允许压缩的页面最小字节数，页面字节数从header头的Content-Length中获取，默认值是0，不管页面多大都进行压缩，建议设置成大于1K，如果小与1K可能会越压越大。

gzip_buffers 4 32k ：压缩缓冲区大小，表示申请4个单位为32K的内存作为压缩结果流缓存，默认值是申请与原始数据大小相同的内存空间来存储gzip压缩结果。

gzip_http_version 1.1 ：压缩版本，用于设置识别HTTP协议版本，默认是1.1，目前大部分浏览器已经支持GZIP解压，使用默认即可。

gzip_comp_level 6 ：压缩比例，用来指定GZIP压缩比，1压缩比最小，处理速度最快，9压缩比最大，传输速度快，但是处理慢，也比较消耗CPU资源。

gzip_types text/css text/xml application/javascript ：用来指定压缩的类型，‘text/html’类型总是会被压缩。默认值: gzip_types text/html (默认不对js/css文件进行压缩)

压缩类型，匹配MIME型进行压缩；

不能用通配符 text/*；

text/html默认已经压缩 (无论是否指定)；

设置哪压缩种文本文件可参考 conf/mime.types。

gzip_vary on ：varyheader支持，改选项可以让前端的缓存服务器缓存经过GZIP压缩的页面，例如用Squid缓存经过nginx压缩的数据。

wangxudongx

关注

0
点赞
踩
3

收藏

觉得还不错? 一键收藏
0
评论
Tomcat和Nginx一步到位

tomcat和nginxtomcat打开manager配置访问manager的IP白名单配置访问manager的用户访问manager调整catalina的jvm内存大小配置参数检测配置catalina的IO优化Connector的protocol选择tomcat打开manager配置访问manager的IP白名单配置/usr/local/apache-tomcat-8.5.45/con...
复制链接

扫一扫