• Ningx的基本使用


    Ningx的基本使用
     
    user www;
    worker_processes 2;
    error_log logs/error.log info;
    pid logs/nginx.pid;
     
    events {
    worker_connections 1024; // 控制允许接受的并发连接数
    }
    http { // 定义与web服务相关的
    include mime.types;
    default_type application/octet-stream;
    ....
    }
     
    一、部署web服务
     
    每一个server { } 定义一个网站
     
    例子:
    http {
    include mime.types;
    default_type application/octet-stream;
    sendfile on;
    keepalive_timeout 65;
    server {
    listen 80;
    server_name localhost;
    location / {
    root html;       # 定义网站的根目录
    index index.html index.htm index.php;       # 定义目录的默认页面
    }
    error_page 500 502 503 504 /50x.html;
    location = /50x.html {
    root html;
    }
    location ~ .php$ {     # 匹配所有以 .php结尾的访问请求
    root html;
    fastcgi_pass 127.0.0.1:9000;     # 把请求交给本地监听9000端口的进程来处理
    fastcgi_index index.php;
    fastcgi_param SCRIPT_FILENAME $document_root/$fastcgi_script_name;
    include fastcgi_params;
    }
    }
    }
     
     
     
     
    URL的组成: http://www.upl.com/bbs/upload/11.jpg
     
    http 协议
    :// 格式符号 例如: ftp:// file://
     
    www.upl.com 目的地,这个请求要发给谁,可以写IP地址
     
    /bbs/upload/11.jpg 网络路径(请求路径)
    nginx: Location
    squid: url_path
    apache: Location
     
     
     
     
    在原有默认网站的基础上,再去定义一个网站
    http{
    ...
    ...
    server {
    默认网站
    }
     
    server {
    第二个网站
    }
    }
     
     
     
    定义好第二个网站的例子:
     
    server {
    listen 80;
    server_name bbs.upl.com;
    root /web/bbs.upl.com/wwwroot;
    access_log /web/bbs.upl.com/logs/access.log;
     
    location / {
    index index.html index.htm index.php;
    }
     
    location ~ .php$ {
    fastcgi_pass 127.0.0.1:9000;
    fastcgi_index index.php;
    fastcgi_param SCRIPT_FILENAME $document_root/$fastcgi_script_name;
    include fastcgi_params;
    }
     
     
     
     
    # mkdir -p /web/bbs.upl.com/{wwwroot,logs}
    # chown -R www:www /web/bbs.upl.com/{wwwroot,logs}
     
     
     
    重载
    # /usr/local/nginx/sbin/nginx -s reload
     
     
    测试的时候
    客户端需要修改hosts:
     
    10.1.1.21 www.upl.com upl.com bbs.upl.com
     
     
     
     
    ======================================================================
     
     
     
    例子: location学习
     
    匹配访问请求中的路径,不同的请求路径不同的处理方法
     
     
    location
     
    syntax: location [=|~|~*|^~|@] /uri/ { ... }
     
    = 精确匹配某个路径
    ~ 可以使用正则表达式匹配(对大小写敏感)
    ~* 忽略大小写的正则表达式匹配
    ^~ 以什么开头请求,可以使用正则表达式
     
     
     
    location = / {
    # 仅仅只能匹配以/开头并且没有多余的字符的路径 http://www.upl.com/
    [ configuration A ]
    }
    location / {
    # 如果后面或者前面有更精确匹配或者有正则表达的location能够匹配,首先匹配它们,然后再
    # 匹配本location,如果选项冲突按照前者生效,如果选项不冲突,那么按照本location
    # 可以匹配任何以 / 开头的请求
    [ configuration B ]
    }
    location ^~ /images/ {
    # 正则表达是匹配,匹配所有以 /images开头的访问请求
    # http://www.upl.com/images/xxx/xxx/.jpg
    [ configuration C ]
    }
    location ~* .(gif|jpg|jpeg)$ {
    # 忽略大小写,匹配所有以gif或者jpg或者jpeg结尾的访问请求。
    # 如果存在多个正则表达式匹配某个请求,那么谁在前面,谁优先生效,后面就不会再去匹配。
    # Configuration C.
    [ configuration D ]
    }
     
     
     
    Example requests:
     
    * / -> configuration A <--- http://www.upl.com/
     
    * /documents/document.html -> configuration B
    <-- http://www.upl.com/documents/document.html
     
    * /images/1.gif -> configuration C
    <--- http://www.upl.com/images/1.gif
     
    * /documents/1.jpg -> configuration D
     
     
     
     
     
     
    通过设定location,给所有的网站指定404错误页面
     
    1、把同一个报错页面的相关文件放在一个目录里
    # mkdir -p /web/common
    # chown www:www /web/common
    # ls /web/common/
    404.html no.png
     
    # cat 404.html
    <center><img src="/no.png" /></center>
     
     
    server {
    ..
    error_page 404 /404.html;
    location = /404.html {
    root /web/common;
    }
    location = /no.png {
    root /web/common;
    }
    ..
    }
     
    server {
    ..
    error_page 404 /404.html;
    location = /404.html {
    root /web/common;
    }
    location = /no.png {
    root /web/common;
    }
    ..
    }
     
     
     
     
     
     
     
    状态页面
     
    location /status {
    stub_status on;
    access_log off;
    allow 10.1.1.21;
    deny all;
    }
     
     
    正则匹配,地址重写
     
    if 条件判断,匹配用户的请求,然后作出相应的动作
     
    匹配的操作符号
    ~ performs a case-sensitive match
    ~* performs a case-insensitive match (firefox matches FireFox)
    !~ and !~* mean the opposite, "doesn't match"
     
     
    if ($http_user_agent ~ MSIE) {
    rewrite ^(.*)$ /msie/$1 break;
    }
     
     
    地址重写rewrite
     
    rewrite ^(.*)$ /zh/$1 break;
    rewrite 客户端发过来的请求地址 nginx转换出来的地址 flag;
     
    如果客户端浏览器语言是zh_CN,那么就把它请求转换成/zh开头的
    http://www.upl.com/test.html --转换后-> http://www.upl.com/zh/test.html
     
     
     
    例子1:中文语言客户端访问中文页面
    server {
    ...
    if ($http_user_agent ~ zh-CN) {
    rewrite ^(.*)$ /zh/$1 break;
    }
     
    location { .. }
    }
     
     
     
    # mkdir /wwwroot/zh
    # ls /wwwroot/test.html <---英文页面
    # ls /wwwroot/zh/test.html <---中文页面
     
     
    效果:使用中文的浏览器访问的时候,就会实际访问到 中文页面
     
    客户实际访问的URL
    但事实上被nginx偷偷加载 /wwwroot/zh/test.html 返回给客户端。
     
     
    例子: 防止盗链
     
    www.upl.com网站上的图片,只要出现在非www.upl.com的网站里都会被返回一张盗链提示的图片
     
    原理: 只要www.upl.com服务器接受访问图片的请求,而这些请求的来路(Referer)不是www.upl.com开头,那么绝对就是盗链。
     
     
    location ~* .(gif|jpg|jpeg|png)$ {
    if ( $http_referer !~ http://www.upl.com/(.*) ) {
    rewrite ^(.*)$ /no.png last;
    }
    }
     
     
     
    例子:伪静态
     
    http://www.upl.com/read-tid-1.html <---这个页面在服务器上根本不存在,但是可以被访问。
     
     
    /read-tid-1.html ---> nginx通过正则表达是匹配该请求----转换用户请求read.php?tid=1 ---> nginx背后按照转换后的请求去返回资源给客户端
     
    为了实现伪静态的前提:
     
    1、网站跑的应用程序要支持。
    2、web服务器上rewrite规则要正确
     
    默认的URL形式为 "http://www.phpwind.net/thread.php?fid=2"
    新的URL形式为 "http://www.phpwind.net/thread-fid-2.html" <--客户端在浏览器输入的地址
     
    $1 /thread
    $2 fid-2.html
    转换后:
    /thread.php?fid-2.html
     
     
    /read.php?tid-1.html
     
     
    1、登录论坛后台设定
     
    静态目录: -htm-
    静态目录扩展名设置: .html
     
    2、写规则
     
    server {
    rewrite ^(.*)-htm-(.*)$ $1.php?$2 last;
     
    location { ..}
     
    }
     
    ===============================================================================
     
    web服务器的调优
     
    如何评价一个web服务的性能:
    1、并发请求数目并不等价同时有多个不同的IP连接。具体是指连接请求。
    # lsof -i:80 -n | grep 199
    nginx 9194 www 13u IPv4 156781 0t0 TCP 10.1.1.21:http->10.1.1.199:40161 (ESTABLISHED)
    nginx 9194 www 15u IPv4 156788 0t0 TCP 10.1.1.21:http->10.1.1.199:40164 (ESTABLISHED)
    nginx 9194 www 16u IPv4 156789 0t0 TCP 10.1.1.21:http->10.1.1.199:40165 (ESTABLISHED)
    nginx 9194 www 27u IPv4 156899 0t0 TCP 10.1.1.21:http->10.1.1.199:40175
     
    以上代表四个并发请求
     
    2、请求时间(响应时间)
    站住客户端的角度去分析:
    响应时间 = 请求发送出去的时间 + 服务器处理请求的时间 + 请求返回的时间
     
    站在服务端的角度去分析:
    响应时间 = 服务器处理请求的时间(从接受到请求到返回那刻开始)
     
    3、吞吐量
    服务器在单位时间内,处理了多少的数据。
     
    理想目标:
    在系统资源允许的条件下,响应时间在可以接受的范围内,并发请求越多越好,吞吐量越大越好。
     
     
    调优手段:
    1、模拟并发请求,增加对服务器的压力
     
    # ab 命令 <---安装httpd-tools软件包
     
    2、调整参数,对比调整前后的指标
     
    调整的方向:
    可以减少cpu的开销,就尽可能减少。
    并发请求、连接建立和撤销、动态页面的编译消耗cpu资源
     
    可以减少内存的开销,尽可能减少。
    页面的编译、页面的代码、请求的类型、连接驻留(保持连接)
     
     
    如果服务器是属于cpu密集型,主要是以消耗cpu为主的,服务器主要体现在cpu运算能力不足:增加内存的使用,减少cpu的开销,前提:内存足够
     
    如果服务器是属于内存密集型,主要是以消耗内存为主的,服务器主要体现在内存不足: 减少内存开销,往往就会带来cpu开销增加。前提:cpu运算能力足够
     
     
    3、不断变化调整,最后找到一个最恰当的参数
     
     
    调整参数之前,在一定比例的并发数下,在响应时间允许的情况下,做测试。
     
    # ab -c 500 -n 5000 http://10.1.1.21/thread-htm-fid-2.html
    -A:指定连接服务器的基本的认证凭据; -c:指定一次向服务器发出请求数; -C:添加cookie; -g:将测试结果输出为“gnuolot”文件; -h:显示帮助信息; -H:为请求追加一个额外的头; -i:使用“head”请求方式; -k:激活HTTP中的“keepAlive”特性; -n:指定测试会话使用的请求数; -p:指定包含数据的文件; -q:不显示进度百分比; -T:使用POST数据时,设置内容类型头; -v:设置详细模式等级; -w:以HTML表格方式打印结果; -x:以表格方式输出时,设置表格的属性; -X:使用指定的代理服务器发送请求; -y:以表格方式输出时,设置表格属性。
     
    -c参数是指定并发量,就是我一次对这个网站发起多少个连接。
    -n 测试的次数,比如说我们用10的并发量向服务器去请求1000次的HTTP请求,相当于我们访问了1000次指定的网页。
     
     
    # vmstat 2
    procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
    r b swpd free buff cache si so bi bo in cs us sy id wa st
    0 0 0 1575384 130720 1495268 0 0 41 15 17 117 24 3 73 0 0
    1 0 0 1571896 130720 1498780 0 0 0 0 728 784 5 2 94 0 0
    28 0 0 1570148 130732 1489188 0 0 0 4 11455 3698 71 30 0 0 0
    35 0 0 1573712 130732 1489232 0 0 0 0 11372 3867 72 28 0 0 0
    33 0 0 1572968 130740 1489260 0 0 0 84 11106 3832 73 27 0 0 0
    32 0 0 1572300 130740 1489284 0 0 0 0 10958 3835 73 28 0 0 0
    35 0 0 1558512 130748 1498772 0 0 0 8 10803 4693 72 29 0 0 0
     
    以上的测试条件,让服务器的响应时间很慢,运行队列(系统负载)很高。
     
     
    修改参数:
    # ab -c 100 -n 1000 http://10.1.1.21/thread-htm-fid-2.html
     
     
     
    Benchmarking 10.1.1.21 (be patient)
    Completed 100 requests 分10次测试所有请求,每次完成100个请求
    Completed 200 requests
    Completed 300 requests
    Completed 400 requests
    Completed 500 requests
    Completed 600 requests
    Completed 700 requests
    Completed 800 requests
    Completed 900 requests
    Completed 1000 requests
    Finished 1000 requests
     
     
     
    Server Software: nginx/1.0.15
    Server Hostname: 10.1.1.21
    Server Port: 80
     
    Document Path: /thread-htm-fid-2.html
    Document Length: 56666 bytes
     
    Concurrency Level: 100 ######
    Time taken for tests: 23.535 seconds <---整个测试消耗的时间
    Complete requests: 1000 <---测试了1000个请求 #####
    Failed requests: 28 <--- 有28个失败。 #######
    (Connect: 0, Receive: 0, Length: 28, Exceptions: 0)
    Write errors: 0
    Non-2xx responses: 28
    Total transferred: 55747689 bytes 本次测试一共传输接受了多少字节的数据
    HTML transferred: 55119348 bytes 属于html文本代码有多少
     
    Requests per second: 42.49 [#/sec] (mean) 平均每秒钟完成多少个请求
    Time per request: 2353.484 [ms] (mean) 每个测试阶段。完成每个阶段的所有请求消耗多少时间 #########
    Time per request: 23.535 [ms] (mean, across all concurrent requests) 每个请求消耗多少时间 #####
    Transfer rate: 2313.21 [Kbytes/sec] received 每秒钟的传输的数据量(吞吐量)#####
     
    Connection Times (ms)
    min mean[+/-sd] median max
    Connect: 0 6 5.6 4 31
    Processing: 500 2249 3628.9 1226 21294
    Waiting: 485 2166 3642.5 1144 21294
    Total: 510 2254 3630.0 1231 21306
     
    Percentage of the requests served within a certain time (ms)
    50% 1231
    66% 1301
    75% 1367
    80% 1418
    90% 4365
    95% 7516
    98% 21032
    99% 21306
    100% 21306 (longest request)
     
     
    总结:
    模拟100个并发请求的条件,测试结果表明服务器完成100的并发请求,需要消耗2353.484 ms
    由于上面的测试是两台电脑同时测试的,所有最终的结果是:
    同时完成200个并发请求,需要消耗2353.484 ms。
     
    测试的过程中,其他客户端访问页面的时候非常慢,所以总结以上的测试压力对于服务器来说,是非常大的。
     
    nginx一个进程使用内存30M左右
    php-cgi进程 每个占用20-30M
     
    要么:降低测试压力。
    要么:调整参数,看一下能否把负载降低。
     
     
    设定工作进程数目: 等于cpu的核心数。
    worker_processes 2;
     
    更均衡给工作进程分配cpu核心
    worker_cpu_affinity 01 10;
     
    允许工作进程最多打开多少个资源(文件描述符、连接)
    worker_rlimit_nofile 65535; <---应该也罢ulimit -n 的值设定成一样
     
    events
    {
    use epoll; <--- Linux 2.6内核后才有的一种高效的网络IO调度算法。
    worker_connections 20480; <---允许处理多大并发请求。
    }
     
     
    http
    {
    include mime.types;
    default_type application/octet-stream;
    server_names_hash_bucket_size 128;
    client_header_buffer_size 4k;
    large_client_header_buffers 8 4k;
    client_max_body_size 8m; //限制允许上传的最大文件尺寸
    keepalive_timeout 8; // 保持连接8秒,保持连接需要浪费内存,建立与撤销连接需要消耗cpu,也会影响响应时间,如何设定?根据应用的类型,一般常规设定为8秒,相册类型: 可以设定比浏览照片时间稍微长2秒钟。
    gzip off; //cpu资源过剩,然后打开压缩可以省带宽。一般针对文本进行压缩,图片不需要。
     
     
    server {
     
    # rewrite ^(.*)-htm-(.*)$ $1.php?$2 last; 取消伪静态,因为需要cpu开销
    location ~ .*.(gif|jpg|jpeg|png|bmp|swf)?$ {
    expires 7d; //告诉客户端缓存7天
    }
     
    location ~ .*.(js|css)?$ {
    expires 1d; //告诉客户端缓存1天
    }
     
    }
     
     
     
    //以下参数对本次调整意义不大,不会降低cpu开销
    fastcgi_connect_timeout 60;
    fastcgi_send_timeout 60;
    fastcgi_read_timeout 60;
    fastcgi_buffer_size 4k;
    fastcgi_buffers 64 4k; //内存足够的情况下可以调整大一些
    fastcgi_busy_buffers_size 128k;
    fastcgi_temp_file_write_size 128k;
     
     
    gzip on;
    gzip_min_length 1k;
    gzip_buffers 16 4k;
    gzip_http_version 1.0;
    gzip_comp_level 2;
    gzip_types text/plain application/x-javascript text/css application/xml;
    gzip_vary on;
     
     
    //以下所有的fastcgi_cache 相关参数在本次实验中不是用
    // 这些参数都是为了缓存php动态页面的编译结果,减少重复对相同页面的编译带来的无用cpu开销
    fastcgi_cache_path /usr/local/nginx/fastcgi_cache levels=2:2 keys_zone=phpcache:30m inactive=5m;
    fastcgi_cache phpcache;
    fastcgi_cache_valid 200 302 1h;
    fastcgi_cache_valid 301 1d;
    fastcgi_cache_valid any 1m;
    fastcgi_cache_min_uses 1;
    fastcgi_cache_use_stale error timeout invalid_header http_500;
    fastcgi_cache_key http://$host$request_uri;
     
    // 不使用的原因:因为论坛不适合缓存,没人喜欢看一个不会变化的论坛。其次,论坛页面绝大多数都不会成功被缓存,因为页面有cookie字段。
     
     
     
    作业:
    搜索 nginx优化 、 nginx十万并发
     
    http协议详解
     
     
     
     
    反向代理
    实现简单的负载均衡。
     
    ================================================
     
    http协议的概要:
     
    响应头信息原始头信息
    Server nginx/1.0.15
    Date Thu, 03 Jan 2013 06:31:20 GMT
    Content-Type text/html
    Content-Length 85
    Last-Modified Thu, 03 Jan 2013 06:27:02 GMT
    Connection keep-alive
    Accept-Ranges bytes
     
     
    请求头信息原始头信息
    Host bbs.upl.com
    User-Agent Mozilla/5.0 (X11; U; Linux x86_64; zh-CN; rv:1.9.2.24) Gecko/20111104 Red Hat/3.6.24-3.el6_1 Firefox/3.6.24
     
     
    Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
    Accept-Language zh-cn,zh;q=0.5
    Accept-Encoding gzip,deflate
    Accept-Charset GB2312,utf-8;q=0.7,*;q=0.7
    Keep-Alive 115
    Connection keep-alive
     
     
     
     
     
     
     
    请求头信息原始头信息
    Host www.upl.com
    User-Agent Mozilla/5.0 (X11; U; Linux x86_64; zh-CN; rv:1.9.2.24) Gecko/20111104 Red Hat/3.6.24-3.el6_1 Firefox/3.6.24
    Accept image/png,image/*;q=0.8,*/*;q=0.5
    Accept-Language zh-cn,zh;q=0.5
    Accept-Encoding gzip,deflate
    Accept-Charset GB2312,utf-8;q=0.7,*;q=0.7
    Keep-Alive 115
    Connection keep-alive
     
    Referer http://bbs.upl.com/test.html <---来路
     
    If-Modified-Since Thu, 03 Jan 2013 06:25:06 GMT
    Cache-Control max-age=0
     
     
     
     
     
     
     
  • 相关阅读:
    Cefsharp支持MP4和MP3的CEF库cef.redist.x86.3.2623,对应Cefsharp49
    解读设计模式
    模拟支付宝、淘宝登录2
    模拟支付宝、淘宝登录1
    上一篇随笔是2011-11-21 17:23,唏嘘啊。。。
    像素格式
    YUV格式详解
    认识RGB和YUV
    WPF性能优化经验总结
    【日期正则表达式】
  • 原文地址:https://www.cnblogs.com/steven9898/p/11331140.html
Copyright © 2020-2023  润新知