2年前 (2016-11-15)  Linux安全运维    抢沙发
文章评分 1 次,平均分 5.0

1.mysql5和mysql6 有什么区别

mysql-server-5.5:默认引擎改为Innodb,提高了性能和扩展性,提高实用性(中继日志自动恢复)

mysql-server-5.6:InnoDB性能加强,InnoDB死锁信息可以记录到 error 日志,方便分析,MySQL5.6支持延时复制,可以让slave跟master之间控制一个时间间隔,方便特殊情况下的数据恢复。

3.nginx用于md5加密的模块是什么

nginx_file_md5

4.lvs调优参数

CONFIG_IP_VS_TAB_BITS 该表用于记录每个进来的连接及路由去向的信息,取值范围[12,20]

LVS的调优建议将hash table的值设置为不低于并发连接数。例如,并发连接数为200,Persistent时间为200S,那么hash桶的个数应设置为尽可能接近200x200=40000,2的15次方为32768就可以了

内核参数优化

net.ipv4.tcp_tw_recyle=1

net.ipv4.tcp_tw_reuse=1

net.ipv4.tcp_max_syn_backlog=8192

net.ipv4.tcp_keepalive_time=1800

net.ipv4.tcp_fin_timeout=30

net.core.rmem_max=16777216

net.core.wmem_max=16777216

net.ipv4.tcp_rmem=4096 87380 16777216

net.ipv4.tcp_wmem=4096 65536 16777216

net.core.netdev_max_backlog=3000

二、系统参数优化

2.1 关闭网卡LRO和GRO

现在大多数网卡都具有LRO/GRO功能,即 网卡收包时将同一流的小包合并成大包 (tcpdump抓包可以看到>MTU 1500bytes的数据包)交给 内核协议栈;LVS内核模块在处理>MTU的数据包时,会丢弃;

因此,如果我们用LVS来传输大文件,很容易出现丢包,传输速度慢;

解决方法,关闭LRO/GRO功能,命令:

ethtool -k eth0 查看LRO/GRO当前是否打开

ethtool -K eth0 lro off 关闭GRO

ethtool -K eth0 gro off 关闭GRO

2.2 禁用ARP,增大backlog并发数

net.ipv4.conf.all.arp_ignore = 1

net.ipv4.conf.all.arp_announce = 2

net.core.netdev_max_backlog = 500000

5.nginx和apache的区别和优缺点

http://www.cnblogs.com/huangye-dream/p/3550328.html

1、nginx相对于apache的优点:

轻量级,同样起web 服务,比apache 占用更少的内存及资源

抗并发,nginx 处理请求是异步非阻塞的,而apache 则是阻塞型的,在高并发下nginx 能保持低资源低消耗高性能

高度模块化的设计,编写模块相对简单

社区活跃,各种高性能模块出品迅速啊

2.apache 相对于nginx 的优点:

rewrite ,比nginx 的rewrite 强大

模块超多,基本想到的都可以找到

超稳定

总结:需要性能的web 服务,用nginx 。如果不需要性能只求稳定,那就apache 吧。最核心的区别在于apache是同步多进程模型,一个连接对应一个进程;nginx是异步的,多个连接(万级别)可以对应一个进程

Apache 对 PHP 支持比较简单,Nginx 需要配合其他后端用Nginx优于apache的主要两点:1.Nginx本身就是一个反向代理服务器 2.Nginx支持7层负载均衡;其他的当然,Nginx可能会比apache支持更高的并发

6.mysql的两个分支

MySQL的两个分支,一个叫MariaDB,MySQL原作者出售后建立的一个分支.另一个叫做Percona Server,是一个专注于Linux版MySQL开发和运维,紧跟MySQL官方版本的MySQL分支,特点在于免费开源,其XtraDB引擎基于InnoDB进一步优化并保持兼容,还提供了一系列MySQL运维工具,比如热备份工具XtraBackup等等.

Percona专注于Linux上高性能高可用MySQL开发,为MySQL提供了一系列改进和工具,可以看做Linux上的MySQL企业版:

7.lvs通常和什么结合到一起使用

LVS只是做一个负载均衡,通过访问VIP来访问后端的网站程序,一旦LVS宕机,整个网站就访问不了,这就出现了单点。所以要结合keepalive这种高可用软件来保证整个网站的高可用

8.lvs的三种工作模式

http://www.csdn123.com/html/topnews201408/70/2670.htm

LVS( Linux Virtual Server),Linux下的负载均衡器,支持LVS-NAT、 LVS-DR、LVS-TUNL三种不同的方式

nat用的不是很多,主要用的是DR、TUNL方式。

DR方式适合所有的RealServer同一网段下,即接在同一个交换机上.

TUNL方式就对于RealServer的位置可以任意了,完全可以跨地域、空间,只要系统支持Tunnel就可以,方便以后扩充的话直接Tunl方式即可

9.lvs的八种调度算法

* 轮叫调度(Round-Robin Scheduling)

* 加权轮叫调度(Weighted Round-Robin Scheduling)

* 最小连接调度(Least-Connection Scheduling)

* 加权最小连接调度(Weighted Least-Connection Scheduling)

* 基于局部性的最少链接(Locality-Based Least Connections Scheduling)

* 带复制的基于局部性最少链接(Locality-Based Least Connections with Replication Scheduling)

* 目标地址散列调度(Destination Hashing Scheduling)

* 源地址散列调度(Source Hashing Scheduling)

* 最短预期延时调度(Shortest Expected Delay Scheduling)

* 不排队调度(Never Queue Scheduling)

对应: rr|wrr|lc|wlc|lblc|lblcr|dh|sh|sed|nq,

在一般的网络服务(如HTTP和Mail Service等)调度中,我会使用加权最小连接调度wlc或者加权轮叫调度wrr算法。

10.mysql和mariadb的区别

http://bijian1013.iteye.com/blog/2315665

  1. MariaDB 是一个采用Aria存储引擎的MySQL分支版本,是由原来 MySQL 的作者Michael Widenius创办的公司所开发的免费开源的数据库服务器
  2. MariaDB是一个社区驱动的、采用XtraDb存储引擎的MySQL分支版本

11.网站打开慢,分析原因及解决方案

用户自身网络问题,或者浏览器问题。 dns 解析问题。 服务器负载大。 数据库慢查询多
解决:
减少http请求数(优化缓存,将css放在网页head部分)

使用CDN(ContentDeliveryNetwork,内容分发网络)

优化数据库

12.lnmp 遇到502错误

http://zhangxylinux.blog.51cto.com/5041623/1563427

启用两个php-fpm实例,把php-fpm分为两部分,每部分各听一个端口或socket,这样就减少了lock,依然保持400个php-fpm进程,每个实例启用200个,采用nginx的upstream负载均衡,轮询每个socket来处理请求。

13.nginx和lvs的区别

http://732233048.blog.51cto.com/9323668/1623375

LVS特点:

1.抗负载能力强,使用IP负载均衡技术,只做分发,所以LVS本身并没有多少流量产生;

2.稳定性、可靠性好,自身有完美的热备方案;(如:LVS+Keepalived)

3.应用范围比较广,可以对所有应用做负载均衡;

4.不支持正则处理,不能做动静分离。

常用四种算法:

1.rr:轮叫,轮流分配到后端服务器;

2.wrr:权重轮叫,根据后端服务器负载情况来分配;

3.lc:最小连接,分配已建立连接最少的服务器上;

4.wlc:权重最小连接,根据后端服务器处理能力来分配。

Nginx特点:

1.工作在7层,可以对做正则规则处理;(如:针对域名、目录进行分流)

2.配置简单,能ping通就能进行负载功能,可以通过端口检测后端服务器状态,不支持url检测;

3.抗高并发,采用epoll网络模型处理客户请求;

4.只支持HTTP和EMail,应用范围比较少;

5.nginx主要是HTTP和反向代理服务器,低系统资源消耗。

常用四种算法:

1.RR:(默认)轮询,轮流分配到后端服务器;

2.weight:根据后端服务器性能分配;

3.ip_hash:每个请求按访问ip的hash结果进行分配,并发小时合适,解决session问题;

4.fair:(扩展策略),默认不被编译nginx内核,根据后端服务器响应时间判断负载情况,选择最轻的进行处理。

lvs优点:

是三个集群软件中性能和稳定性最高的(但是配置管理却是最复杂的)

工作在4层传输层,只用来做分发工作,并无流量的产生

几乎支持所有的应用,如:http,mysql,email等等

对网络要求很高,若是采用DR方式,最好用同一网段进行通信(LB与后端web)

nginx:

工作在7层应用层,可以对http应用层实现分流策略(如:根据域名,根据目录结构)

只支持http和email

对网络要求不是很高,理论上只要ping的通,就可以正常工作(nginx与后端web)

我建议:

如果公司的网站比较小,访问人数不是很多,可以采用nginx来做负载均衡

但是若公司网站规模较大,达到门户级别,建议采用lvs

14.php-fpm你做过哪些优化

http://blog.csdn.net/dc_726/article/details/12340349

http://www.ha97.com/4339.html

1进程数

php-fpm初始/空闲/最大worker进程数

pm.max_children = 300

pm.start_servers = 20

pm.min_spare_servers = 5

pm.max_spare_servers = 35

2最大处理请求数

最大处理请求数是指一个php-fpm的worker进程在处理多少个请求后就终止掉,master进程会重新respawn一个新的。

这个配置的主要目的是避免php解释器或程序引用的第三方库造成的内存泄露。

pm.max_requests = 10240

3最长执行时间

最大执行时间在php.ini和php-fpm.conf里都可以配置,配置项分别为max_execution_time和request_terminate_timeout。

其作用及其影响参见:Nginx中502和504错误详解

php-fpm对于进程的管理存在两种风格——static和dynamic。

如果设置成static,php-fpm进程数自始至终都是pm.max_children指定的数量,不再增加或减少。

如果设置成dynamic,则php-fpm进程数是动态的,最开始是pm.start_servers指定的数量,如果请求较多,则会自动增加,保证空闲的进程数不小于pm.min_spare_servers,如果进程数较多,也会进行相应清理,保证多余的进程数不多于pm.max_spare_servers。

这两种不同的进程管理方式,可以根据服务器的实际需求来进行调整。

这里先说一下涉及到这个的几个参数,他们分别是pm、pm.max_children、pm.start_servers、pm.min_spare_servers和pm.max_spare_servers。

pm表示使用那种方式,有两个值可以选择,就是static(静态)或者dynamic(动态)。在更老一些的版本中,dynamic被称作apache-like。这个要注意看配置文件的说明。

下面4个参数的意思分别为:

pm.max_children:静态方式下开启的php-fpm进程数量。
pm.start_servers:动态方式下的起始php-fpm进程数量。
pm.min_spare_servers:动态方式下的最小php-fpm进程数量。
pm.max_spare_servers:动态方式下的最大php-fpm进程数量。

如果dm设置为static,那么其实只有pm.max_children这个参数生效。系统会开启设置数量的php-fpm进程。

如果dm设置为dynamic,那么pm.max_children参数失效,后面3个参数生效。系统会在php-fpm运行开始的时候启动pm.start_servers个php-fpm进程,然后根据系统的需求动态在pm.min_spare_servers和pm.max_spare_servers之间调整php-fpm进程数。

那么,对于我们的服务器,选择哪种执行方式比较好呢?事实上,跟Apache一样,运行的PHP程序在执行完成后,或多或少会有内存泄露的问题。这也是为什么开始的时候一个php-fpm进程只占用3M左右内存,运行一段时间后就会上升到20-30M的原因了。

对于内存大的服务器(比如8G以上)来说,指定静态的max_children实际上更为妥当,因为这样不需要进行额外的进程数目控制,会提高效率。因为频繁开关php-fpm进程也会有时滞,所以内存够大的情况下开静态效果会更好。数量也可以根据 内存/30M 得到,比如8GB内存可以设置为100,那么php-fpm耗费的内存就能控制在 2G-3G的样子。如果内存稍微小点,比如1G,那么指定静态的进程数量更加有利于服务器的稳定。这样可以保证php-fpm只获取够用的内存,将不多的内存分配给其他应用去使用,会使系统的运行更加畅通。

对于小内存的服务器来说,比如256M内存的VPS,即使按照一个20M的内存量来算,10个php-cgi进程就将耗掉200M内存,那系统的崩溃就应该很正常了。因此应该尽量地控制php-fpm进程的数量,大体明确其他应用占用的内存后,给它指定一个静态的小数量,会让系统更加平稳一些。或者使用动态方式,因为动态方式会结束掉多余的进程,可以回收释放一些内存,所以推荐在内存较少的服务器或VPS上使用。具体最大数量根据 内存/20M 得到。比如说512M的VPS,建议pm.max_spare_servers设置为20。至于pm.min_spare_servers,则建议根据服务器的负载情况来设置,比较合适的值在5~10之间。

15.redis3.0的新特性

  • Redis Cluster —— 一个分布式的 Redis 实现
  • 全新的 “embedded string” 对象编码结果,更少的缓存丢失,在特定的工作负载下速度的大幅提升
  • AOF child -> parent 最终数据传输最小化延迟,通过在 AOF 重写过程中的 “last write”
  • 大幅提升 LRU 近似算法用于键的擦除
  • WAIT 命令堵塞等待写操作传输到指定数量的从节点
  • MIGRATE 连接缓存,大幅提升键移植的速度
  • MIGARTE 新的参数 COPY 和 REPLACE
  • CLIENT PAUSE 命令:在指定时间内停止处理客户端请求
  • BITCOUNT 性能提升
  • CONFIG SET 接受不同单位的内存值,例如 “CONFIG SET maxmemory 1gb”.
  • Redis 日志格式小调整用于反应实例的角色 (master/slave)
  • INCR 性能提升

16.ftp互动模式和被动模式的区别

主动模式(PORT)和被动模式(PASV)。主动模式是从服务器端向客户端发起连接;被动模式是客户端向服务器端发起连接。两者的共同点是都使用 21端口进行用户验证及管理,差别在于传送数据的方式不同,PORT模式的FTP服务器数据端口固定在20,而PASV模式则在1025-65535之间 随机。

17.如何通俗地解释 CGI,FastCGI,php-fpm 之间的关系

CGI是为了保证web server传递过来的数据是标准格式的,它是一个协议

Fastcgi是CGI的更高级的一种方式,是用来提高CGI程序性能的。

web server(如nginx)只是内容的分发者。比如,如果请求/index.html,那么web server会去文件系统中找到这个文件,发送给浏览器,这里分发的是静态资源。

如果现在请求的是/index.php,根据配置文件,nginx知道这个不是静态文件,需要去找PHP解析器来处理,那么他会把这个请求简单处理后交给PHP解析器。此时CGI便是规定了要传什么数据以什么格式传输给php解析器的协议。

CGI相较于Fastcgi而言其性能瓶颈在哪呢?CGI针对每个http请求都是fork一个新进程来进行处理,处理过程包括解析php.ini文件,初始化执行环境等,然后这个进程会把处理完的数据返回给web服务器,最后web服务器把内容发送给用户,刚才fork的进程也随之退出

astcgi则会先fork一个master,解析配置文件,初始化执行环境,然后再fork多个worker。当请求过来时,master会传递给一个worker,然后立即可以接受下一个请求。这样就避免了重复的劳动,效率自然是高

18.Nginx+php-fpm实现原理

http://blog.chinaunix.net/uid-26729093-id-4701792.html

Nginx本身不会对PHP进行解析,终端对PHP页面的请求将会被Nginx交给FastCGI进程监听的IP地址及端口,由php-fpm作为动态解析服务器处理,最后将处理结果再返回给nginx。其实,Nginx就是一个反向代理服务器。Nginx通过反向代理功能将动态请求转向后端php-fpm,从而实现对PHP的解析支持,这就是Nginx实现PHP动态解析的原理。

Nginx不支持对外部程序的直接调用或者解析,所有的外部程序(包括PHP)必须通过FastCGI接口来调用。FastCGI接口在Linux下是socket(这个socket可以是文件socket,也可以是ip socket)。为了调用CGI程序,还需要一个FastCGI的wrapper(wrapper可以理解为用于启动另一个程序的程序),这个wrapper绑定在某个固定socket上,如端口或者文件socket。当Nginx将CGI请求发送给这个socket的时候,通过FastCGI接口,wrapper接收到请求,然后派生出一个新的线程,这个线程调用解释器或者外部程序处理脚本并读取返回数据;接着,wrapper再将返回的数据通过FastCGI接口,沿着固定的socket传递给Nginx;最后,Nginx将返回的数据发送给客户端。

Nginx 简单配置

  1. location ~ \.php$ {
  2. root /home/admin/web/nginx/html/;
  3. fastcgi_pass 127.0.0.1:9000;
  4. fastcgi_index index.php;
  5. fastcgi_param SCRIPT_FILENAME /home/admin/web/nginx/html/$fastcgi_script_name;
  6. include fastcgi_params;
  7. }

19.nginx常用模块和配置参数

  1. user www www;
  2. worker_processes 2;
  3. error_log logs/error.log;
  4. #error_log logs/error.log notice;
  5. #error_log logs/error.log info;
  6. pid logs/nginx.pid;
  7. events {
  8. use epoll;
  9. worker_connections 2048;
  10. }
  11. http {
  12. include mime.types;
  13. default_type application/octet-stream;
  14. #log_format main '$remote_addr - $remote_user [$time_local] "$request" '
  15. # '$status $body_bytes_sent "$http_referer" '
  16. # '"$http_user_agent" "$http_x_forwarded_for"';
  17. #access_log logs/access.log main;
  18. sendfile on;
  19. # tcp_nopush on;
  20. keepalive_timeout 65;
  21. # gzip压缩功能设置
  22. gzip on;
  23. gzip_min_length 1k;
  24. gzip_buffers 4 16k;
  25. gzip_http_version 1.0;
  26. gzip_comp_level 6;
  27. gzip_types text/html text/plain text/css text/javascript application/json application/javascript application/x-javascript application/xml;
  28. gzip_vary on;
  29. # http_proxy 设置
  30. client_max_body_size 10m;
  31. client_body_buffer_size 128k;
  32. proxy_connect_timeout 75;
  33. proxy_send_timeout 75;
  34. proxy_read_timeout 75;
  35. proxy_buffer_size 4k;
  36. proxy_buffers 4 32k;
  37. proxy_busy_buffers_size 64k;
  38. proxy_temp_file_write_size 64k;
  39. proxy_temp_path /usr/local/nginx/proxy_temp 1 2;
  40. # 设定负载均衡后台服务器列表
  41. upstream backend {
  42. #ip_hash;
  43. server 192.168.10.100:8080 max_fails=2 fail_timeout=30s ;
  44. server 192.168.10.101:8080 max_fails=2 fail_timeout=30s ;
  45. }
  46. # 很重要的虚拟主机配置
  47. server {
  48. listen 80;
  49. server_name itoatest.example.com;
  50. root /apps/oaapp;
  51. charset utf-8;
  52. access_log logs/host.access.log main;
  53. #对 / 所有做负载均衡+反向代理
  54. location / {
  55. root /apps/oaapp;
  56. index index.jsp index.html index.htm;
  57. proxy_pass http://backend;
  58. proxy_redirect off;
  59. # 后端的Web服务器可以通过X-Forwarded-For获取用户真实IP
  60. proxy_set_header Host $host;
  61. proxy_set_header X-Real-IP $remote_addr;
  62. proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  63. proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504;
  64. }
  65. #静态文件,nginx自己处理,不去backend请求tomcat
  66. location ~* /download/ {
  67. root /apps/oa/fs;
  68. }
  69. location ~ .*\.(gif|jpg|jpeg|bmp|png|ico|txt|js|css)$
  70. {
  71. root /apps/oaapp;
  72. expires 7d;
  73. }
  74. location /nginx_status {
  75. stub_status on;
  76. access_log off;
  77. allow 192.168.10.0/24;
  78. deny all;
  79. }
  80. location ~ ^/(WEB-INF)/ {
  81. deny all;
  82. }
  83. #error_page 404 /404.html;
  84. # redirect server error pages to the static page /50x.html
  85. #
  86. error_page 500 502 503 504 /50x.html;
  87. location = /50x.html {
  88. root html;
  89. }
  90. }

2.2.1 main全局配置

nginx在运行时与具体业务功能(比如http服务或者email服务代理)无关的一些参数,比如工作进程数,运行的身份等。

woker_processes 2
在配置文件的顶级main部分,worker角色的工作进程的个数,master进程是接收并分配请求给worker处理。这个数值简单一点可以设置为cpu的核数grep ^processor /proc/cpuinfo | wc -l,也是 auto 值,如果开启了ssl和gzip更应该设置成与逻辑CPU数量一样甚至为2倍,可以减少I/O操作。如果nginx服务器还有其它服务,可以考虑适当减少。

worker_cpu_affinity
也是写在main部分。在高并发情况下,通过设置cpu粘性来降低由于多CPU核切换造成的寄存器等现场重建带来的性能损耗。如worker_cpu_affinity 0001 0010 0100 1000; (四核)。

worker_connections 2048
写在events部分。每一个worker进程能并发处理(发起)的最大连接数(包含与客户端或后端被代理服务器间等所有连接数)。nginx作为反向代理服务器,计算公式 最大连接数 = worker_processes * worker_connections/4,所以这里客户端最大连接数是1024,这个可以增到到8192都没关系,看情况而定,但不能超过后面的worker_rlimit_nofile。当nginx作为http服务器时,计算公式里面是除以2。

worker_rlimit_nofile 10240
写在main部分。默认是没有设置,可以限制为操作系统最大的限制65535。

use epoll
写在events部分。在Linux操作系统下,nginx默认使用epoll事件模型,得益于此,nginx在Linux操作系统下效率相当高。同时Nginx在OpenBSD或FreeBSD操作系统上采用类似于epoll的高效事件模型kqueue。在操作系统不支持这些高效模型时才使用select。

2.2.2 http服务器

与提供http服务相关的一些配置参数。例如:是否使用keepalive啊,是否使用gzip进行压缩等。

sendfile on
开启高效文件传输模式,sendfile指令指定nginx是否调用sendfile函数来输出文件,减少用户空间到内核空间的上下文切换。对于普通应用设为 on,如果用来进行下载等应用磁盘IO重负载应用,可设置为off,以平衡磁盘与网络I/O处理速度,降低系统的负载。

keepalive_timeout 65 : 长连接超时时间,单位是秒,这个参数很敏感,涉及浏览器的种类、后端服务器的超时设置、操作系统的设置,可以另外起一片文章了。长连接请求大量小文件的时候,可以减少重建连接的开销,但假如有大文件上传,65s内没上传完成会导致失败。如果设置时间过长,用户又多,长时间保持连接会占用大量资源。

send_timeout : 用于指定响应客户端的超时时间。这个超时仅限于两个连接活动之间的时间,如果超过这个时间,客户端没有任何活动,Nginx将会关闭连接。

client_max_body_size 10m
允许客户端请求的最大单文件字节数。如果有上传较大文件,请设置它的限制值

client_body_buffer_size 128k
缓冲区代理缓冲用户端请求的最大字节数
模块http_proxy:
这个模块实现的是nginx作为反向代理服务器的功能,包括缓存功能(另见文章)

proxy_connect_timeout 60
nginx跟后端服务器连接超时时间(代理连接超时)
proxy_read_timeout 60
连接成功后,与后端服务器两个成功的响应操作之间超时时间(代理接收超时)

proxy_buffer_size 4k
设置代理服务器(nginx)从后端realserver读取并保存用户头信息的缓冲区大小,默认与proxy_buffers大小相同,其实可以将这个指令值设的小一点

proxy_buffers 4 32k
proxy_buffers缓冲区,nginx针对单个连接缓存来自后端realserver的响应,网页平均在32k以下的话,这样设置

proxy_busy_buffers_size 64k
高负荷下缓冲大小(proxy_buffers*2)

proxy_max_temp_file_size
当 proxy_buffers 放不下后端服务器的响应内容时,会将一部分保存到硬盘的临时文件中,这个值用来设置最大临时文件大小,默认1024M,它与 proxy_cache 没有关系。大于这个值,将从upstream服务器传回。设置为0禁用。

proxy_temp_file_write_size 64k
当缓存被代理的服务器响应到临时文件时,这个选项限制每次写临时文件的大小。proxy_temp_path(可以在编译的时候)指定写到哪那个目录。

proxy_pass,proxy_redirect见 location 部分。

模块http_gzip:

gzip on : 开启gzip压缩输出,减少网络传输。
gzip_min_length 1k : 设置允许压缩的页面最小字节数,页面字节数从header头得content-length中进行获取。默认值是20。建议设置成大于1k的字节数,小于1k可能会越压越大。
gzip_buffers 4 16k : 设置系统获取几个单位的缓存用于存储gzip的压缩结果数据流。4 16k代表以16k为单位,安装原始数据大小以16k为单位的4倍申请内存。
gzip_http_version 1.0 : 用于识别 http 协议的版本,早期的浏览器不支持 Gzip 压缩,用户就会看到乱码,所以为了支持前期版本加上了这个选项,如果你用了 Nginx 的反向代理并期望也启用 Gzip 压缩的话,由于末端通信是 http/1.0,故请设置为 1.0。
gzip_comp_level 6 : gzip压缩比,1压缩比最小处理速度最快,9压缩比最大但处理速度最慢(传输快但比较消耗cpu)
gzip_types :匹配mime类型进行压缩,无论是否指定,”text/html”类型总是会被压缩的。
gzip_proxied any : Nginx作为反向代理的时候启用,决定开启或者关闭后端服务器返回的结果是否压缩,匹配的前提是后端服务器必须要返回包含”Via”的 header头。
gzip_vary on : 和http头有关系,会在响应头加个 Vary: Accept-Encoding ,可以让前端的缓存服务器缓存经过gzip压缩的页面,例如,用Squid缓存经过Nginx压缩的数据。

20.Apache select和Nginx epoll模型区别

http://oldboy.blog.51cto.com/2561410/1855201/

select的调用复杂度是线性的,即O(n)。举个例子,一个保姆照看一群孩子,如果把孩子是否需要尿尿比作网络IO事件,select的作用就好比这个保姆挨个询问每个孩子:你要尿尿吗?如果孩子回答是,保姆则把孩子拎出来放到另外一个地方。当所有孩子询问完之后,保姆领着这些要尿尿的孩子去上厕所(处理网络IO事件)。

还是以保姆照看一群孩子为例,在epoll机制下,保姆不再需要挨个的询问每个孩子是否需要尿尿。取而代之的是,每个孩子如果自己需要尿尿的时候,自己主动的站到事先约定好的地方,而保姆的职责就是查看事先约定好的地方是否有孩子。如果有小孩,则领着孩子去上厕所(网络事件处理)。因此,epoll的这种机制,能够高效的处理成千上万的并发连接,而且性能不会随着连接数增加而下降。

select epoll
性能 随着连接数增加,急剧下降。处理成千上万并发连接数时,性能很差。 随着连接数增加,性能基本上没有下降。处理成千上万并发连接时,性能很好。
连接数 连接数有限制,处理的最大连接数不超过1024。如果要处理超过1024个连接数,则需要修改FD_SETSIZE宏,并重新编译 。 连接数无限制。
内在处理机制 线性轮询 回调callback
开发复杂性
  http://thedream.blog.51cto.com/
关于

发表评论

暂无评论

切换注册

登录

忘记密码 ?

您也可以使用第三方帐号快捷登录

切换登录

注册

扫一扫二维码分享