性能

使用HTTP/2服务端推送(Server Push),大幅提升网页脚本图片加载速度

使用HTTP/2服务端推送(Server Push),大幅提升网页脚本图片加载速度

内容概览

NGINX从1.13.9版本开始支持HTTP/2服务端推送, 使用此特性,能大幅提升前端页面加载速度,如,js.css,image等的加载速度大幅提升。经测试js.css的加载时间,从平均几百毫秒到几秒提升到几毫秒到十几毫秒(1M带宽测试)。

升级工作主要包括:

  1. 升级NGINX
  2. 修改NGINX配置
  3. 修改PHP程序
                        

网页的图片,js ,css ,视频 都加 http accept-ranges头,以提高性能

网页的图片,js ,css ,视频 都加 http accept-ranges头,以支持多线程加载,断点续传,提高性能!目前各大网站都在使用此方式!

nginx 设置为:

server {
  listen 80;
  server_name p2hp.com;
  location ~ ^/(img/|js/|css/|upload/|font/|fonts/|res/|video) {
    add_header Access-Control-Allow-Origin *;
    add_header Accept-Ranges bytes;
    root /var/www/...;
    access_log off;
    expires 30d;
  }
  ...
}

                    

Nginx开启一个参数就能让你的WEB性能提升3倍

一、遇到的一些问题

记得 2008 年做性能测试的时候,新进7台 lenovo 4核4G 服务器用于性能测试。

当时资源紧张,这7台服务器都装了双系统(Win2003/CentOS5)空闲时用于做测试机(压测的Agent)。

当时给Nginx做了一系列测试,印象很深的是:在这批机器上,Nginx状态页面的压测。

短连接的话最佳QPS约4万,长连接的话最高QPS约13万。…

        

我必须得告诉大家的MySQL优化原理

说起MySQL的查询优化,相信大家收藏了一堆奇技淫巧:不能使用SELECT *、不使用NULL字段、合理创建索引、为字段选择合适的数据类型..... 你是否真的理解这些优化技巧?是否理解其背后的工作原理?在实际场景下性能真有提升吗?我想未必。因而理解这些优化建议背后的原理就尤为重要,希望本文能让你重新审视这些优化建议,并在实际业务场景下合理的运用。

MySQL逻辑架构

如果能在头脑中构建一幅MySQL各组件之间如何协同工作的架构图,有助于深入理解MySQL服务器。下图展示了MySQL的逻辑架构图。

MySQL逻辑架构,来自:高性能MySQL

MySQL逻辑架构整体分为三层,最上层为客户端层,并非MySQL所独有,诸如:连接处理、授权认证、安全等功能均在这一层处理。

MySQL大多数核心服务均在中间这一层,包括查询解析、分析、优化、缓存、内置函数(比如:时间、数学、加密等函数)。所有的跨存储引擎的功能也在这一层实现:存储过程、触发器、视图等。

最下层为存储引擎,其负责MySQL中的数据存储和提取。和Linux下的文件系统类似,每种存储引擎都有其优势和劣势。中间的服务层通过API与存储引擎通信,这些API接口屏蔽了不同存储引擎间的差异。

MySQL查询过程

我们总是希望MySQL能够获得更高的查询性能,最好的办法是弄清楚MySQL是如何优化和执行查询的。一旦理解了这一点,就会发现:很多的查询优化工作实际上就是遵循一些原则让MySQL的优化器能够按照预想的合理方式运行而已。

当向MySQL发送一个请求的时候,MySQL到底做了些什么呢?

MySQL查询过程

客户端/服务端通信协议

MySQL客户端/服务端通信协议是“半双工”的:在任一时刻,要么是服务器向客户端发送数据,要么是客户端向服务器发送数据,这两个动作不能同时发生。一旦一端开始发送消息,另一端要接收完整个消息才能响应它,所以我们无法也无须将一个消息切成小块独立发送,也没有办法进行流量控制。

客户端用一个单独的数据包将查询请求发送给服务器,所以当查询语句很长的时候,需要设置max_allowed_packet参数。但是需要注意的是,如果查询实在是太大,服务端会拒绝接收更多数据并抛出异常。

与之相反的是,服务器响应给用户的数据通常会很多,由多个数据包组成。但是当服务器响应客户端请求时,客户端必须完整的接收整个返回结果,而不能简单的只取前面几条结果,然后让服务器停止发送。因而在实际开发中,尽量保持查询简单且只返回必需的数据,减小通信间数据包的大小和数量是一个非常好的习惯,这也是查询中尽量避免使用SELECT *以及加上LIMIT限制的原因之一。

查询缓存

在解析一个查询语句前,如果查询缓存是打开的,那么MySQL会检查这个查询语句是否命中查询缓存中的数据。如果当前查询恰好命中查询缓存,在检查一次用户权限后直接返回缓存中的结果。这种情况下,查询不会被解析,也不会生成执行计划,更不会执行。

MySQL将缓存存放在一个引用表(不要理解成table,可以认为是类似于HashMap的数据结构),通过一个哈希值索引,这个哈希值通过查询本身、当前要查询的数据库、客户端协议版本号等一些可能影响结果的信息计算得来。所以两个查询在任何字符上的不同(例如:空格、注释),都会导致缓存不会命中。

如果查询中包含任何用户自定义函数、存储函数、用户变量、临时表、mysql库中的系统表,其查询结果
都不会被缓存。比如函数NOW()或者CURRENT_DATE()会因为不同的查询时间,返回不同的查询结果,再比如包含

        

PHP session.save_path目录大量session临时文件带来的服务器效率问题

如果访问量大,可能产生的 SESSION 文件会比较多,这时可以设置分级目录进行 SESSION 文件的保存,效率会提高很多,设置方法为:session.save_path="N;/save_path",N 为分级的级数,save_path 为开始目录。当写入 SESSION 数据的时候,PHP 会获取到客户端的 SESSION_ID,然后根据这个 SESSION ID 到指定的 SESSION 文件保存目录中找到相应的 SESSION 文件,不存在则创建之,最后将数据序列化之后写入文件。     检查了下各web节点,所有web服务器的httpd线程均达到满负荷,很奇怪。因为所有web节点都通过nfs来共享session目录来达到 session的一致性,检查了下nfs文件服务器,IO读写比较大,检查了session_tmp目录,发现session目录临时文件达到 70000多个,初步判断也许是因为一级目录下文件过多带来的IO性能下降。 …

            

PHP-FPM 调优: 用 ‘pm static’ 达到最大性能

 

让我们来迅速了解一下怎样设置 PHP-FPM,以便达到高吞吐,低延迟以及稳定的使用 CPU 和内存的完美状态。在默认的情况下,大多数设置都将 PHP-FPM PM(进程管理器)设置为 dynamic,或者当你有可用内存的问题时常建议你使用ondemand。接下来,让我们根据 php.net 的官方文档来比较一下这两个管理选项和我最常用的设置 —— static之间的区别:

  • pm = dynamic:子进程的数量是根据以下指令来动态生成的:pm.max_childrenpm.start_serverspm.min_spare_serverspm.max_spare_servers.
  • pm = ondemand:在服务启动的时候根据 pm.start_servers 指令生成进程,而非动态生成。
  • pm = static:子进程的数量是由 pm.max_children 指令来确定的。

查看