原使用HTTP/2服务端推送（Server Push）,大幅提升网页脚本图片加载速度
使用HTTP/2服务端推送（Server Push）,大幅提升网页脚本图片加载速度
内容概览
NGINX从1.13.9版本开始支持HTTP/2服务端推送， 使用此特性，能大幅提升前端页面加载速度，如，js.css,image等的加载速度大幅提升。经测试js.css的加载时间，从平均几百毫秒到几秒提升到几毫秒到十几毫秒（1M带宽测试）。
升级工作主要包括：
- 升级NGINX
- 修改NGINX配置
- 修改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优化原理
说起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_children,pm.start_servers,pm.min_spare_servers,pm.max_spare_servers. - pm = ondemand：在服务启动的时候根据
pm.start_servers指令生成进程，而非动态生成。 - pm = static：子进程的数量是由
pm.max_children指令来确定的。
查看…
原亿级mysql数据,启用表分区后,性能大大增加
亿级mysql数据,启用表分区后,性能大大增加
…
Laravel 5 性能优化技巧
说明
性能一直是 Laravel 框架为人诟病的一个点，所以调优 Laravel 程序算是一个必学的技能。
接下来分享一些开发的最佳实践，还有调优技巧，大家有别的建议也欢迎留言讨论。
这里是简单的列表：…
基于composer的php项目的性能优化
优化全部程序使用的文件 ¶
默认时，PHP的OPcache在byte code缓存中存了2000个文件。这个数字对于一般的程序来说还是太小，因此你必须设置 opcache.max_accelerated_files 配置选项为更高的值:…
近期评论