服务器配置优化、系统参数调整、Linux系统内核参数优化
vim /etc/sysctl.conf
net.ipv4.ip_local_port_range = 1024 65535 # 用户端口范围
net.ipv4.tcp_max_syn_backlog = 4096
net.ipv4.tcp_fin_timeout = 30
fs.file-max=65535 # 系统最大文件句柄，控制的是能打开文件最大数量
数据库参数整体优化实例
thread_concurrency #并发线程数量个数
sort_buffer_size #排序缓存
read_buffer_size #顺序读取缓存
read_rnd_buffer_size #随机读取缓存
key_buffer_size #索引缓存
thread_cache_size #线程缓存(1G—>8, 2G—>16, 3G—>32, >3G—>64)
连接层（基本优化）
设置合理的对接客户及对接形式
max_connections #最大连接数，看交易笔数设置
max_connect_errors #最大错误连接数，能大则大
connect_timeout #连接超时
max_user_connections #最大用户连接数
skip-name-resolve #跳过域名解析
wait_timeout #等待超时
back_log #可以在堆栈中的连接数量
SQL层（基础优化）
query_cache_size：查询缓存
OLAP类型的数据库需要重点加强这个显存缓存。
通常不超过 GB。
对于频繁更改的数据，缓存会立即失效。
我们可以使用显存数据库（redis、memecache）来代替它的功能。
存储引擎层
innodb基本优化参数
default-storage-engine
innodb_buffer_pool_size # 没有固定大小，50%测试值，看看情况再微调。但是尽量设置不要超过物理内存70% innodb_file_per_table=(1,0)
innodb_flush_log_at_trx_commit=(0,1,2) #1是最安全的，0是性能最高，2折中
binlog_sync
Innodb_flush_method=(O_DIRECT, fdatasync)
innodb_log_buffer_size #100M以下
innodb_log_file_size #100M 以下
innodb_log_files_in_group #5个成员以下,一般2-3个够用（iblogfile0-N）
innodb_max_dirty_pages_pct #达到百分之75的时候刷写 内存脏页到磁盘。log_bin
max_binlog_cache_size #可以不设置
max_binlog_size #可以不设置
innodb_additional_mem_pool_size #小于2G内存的机器，推荐值是20M。32G内存以上100M
大数据的一些操作。 对于大数据的分页，直接使用limitstart和count分页语句。
当起始页较小时，查询不存在性能问题。 随着起始记录减少，时间也减少。
寻找
1）限制语句的查询时间与起始记录的位置成反比
2）mysql的limit语句很方便，不适合在记录较多的表中直接使用。
极限分页问题的性能优化方法
借助表的覆盖索引加快分页查询速度
我们都知道，如果使用索引查询的一个句子只包含该索引列（覆盖索引），那么查询会非常快。
由于有了借助索引进行搜索的优化算法，而且数据就在查询索引中，所以不需要寻找相关的数据地址，这样就节省了很多时间。 另外，Mysql中还有相关的索引缓存。 当并发量较高时，使用缓存会更有效。
id 数组是一个字段，自然包含默认的字段索引。
覆盖指数
如果一个索引包含（或覆盖）了数组中所有需要查询的值，则称为“覆盖索引”。 即只需要扫描索引而不需要返回表。
覆盖索引的优点
1.索引条目一般比数据行大小大得多。 如果只需要读取索引，MySQL将大大减少数据访问量。
2、由于索引是按照列值的顺序存储的，IO密集型的范围搜索会比从c盘随机读取每一行数据需要的IO少很多。
3、有些存储引擎如myisam只将索引缓存在显存中，数据依赖操作系统来缓存，因此需要系统调用来访问数据
4.Innodb的聚集索引和覆盖索引对于innodb表来说非常有用。
覆盖索引必须存储索引列的值，但是哈希索引、空间索引和全文索引不存储索引列的值，所以mysql只能使用B树索引作为覆盖索引。
案件
select id from product limit 866613, 20
SELECT * FROM product WHERE ID > =(select id from product limit 866613, 1) limit 20
SELECT * FROM product a JOIN (select id from product limit 866613, 20) b ON a.ID = b.id
百万数据导入
一。 对于数据超过65535行的问题，很自然地想到将整个数据分成块。 借助excel的多表分页功能，将超过65535行的数据写入到下一个工作表页面，即通过多表分页的方法突破了最大65535行数据的限制。 具体方法是单独做一个链接，使用JSP导入php删除空数组，通过JSP上的程序判断报表行数，超过65535行后写入SHEET中。这样问题就解决了
二。 在这些大量数据的报表生成和导入中，会占用大量的显存，尤其是在使用TOMCAT的情况下，JVM最多只能支持2G显存，会出现显存溢出的情况。 此时显存消耗主要分为两部分，一是生成报表时的消耗，二是生成报表后写入EXCEL时的消耗。 因为JVM的GC机制无法强制回收，针对这种情况，我们不得不改变形式：
设置报告的起始行和结束行参数，并在API的报告生成过程中逐步估算报告。 例如，一个20万行数据的报表，在生成过程中可以按照起始行和结束行分为4份。 -5 次。这样，报告生成期间的视频内存使用量就会增加。 在前面的报表生成过程中，如果发现显存不够，可以手动启动JVM的GC机制来回收上述报表的缓存。
每个报表生成后立即进行导入EXCEL的过程，将多个SHEET页面改为多个EXCEL，即一步一步生成EXCEL的同时一步步生成报表，内存消耗POI包生成的EXCEL也增加了。 。经过
当上一个EXCEL生成所需的显存不足时，多次生成还可以有效回收生成EXCEL时占用的显存。
然后利用文件操作根据每个客户端的导入请求的SESSIONID和登录时间在服务器端生成一个唯一的临时目录，并用它来存放生成的多个EXCEL，然后调用系统控制台对多个EXCEL进行打包进入RAR
或者JAR方式，最后反馈一个RAR包或者JAR包给用户。 响应客户请求后，再次调用控制台删除临时目录。
通过分段运算和生成，有效降低了从报表生成结果到EXCEL生成的显存消耗。其次，通过使用压缩包，大大减小了响应用户的生成文件的大小，从而提高了并发数用户。
发送和访问时服务器下载文件的负担，有效减少多用户导入下载时服务器端的流量，从而达到进一步减轻服务器负载的效果
PHP相关cgi、fastcgi、php-fpm区别cgi
CGI的英文是（COMMONGATE WAY INTERFACE）公共网段套接字。 它的作用是帮助服务器与语言进行通信。 下面是nginx和php之间的通信。 因为nginx和php的语言不同，所以需要一个通信转换的过程，CGI就是这样的。 通讯合同。
nginx服务器接收到浏览器发来的数据后，如果请求的是静态页面或者不需要动态处理的图片，会直接根据请求的url找到其位置并返回给浏览器。 不需要PHP参与，而如果是动态页面请求，此时nginx必须与php进行通信。 这个时候就需要cgi合约将请求数据转换成php可以理解的信息，然后php根据这个信息返回的信息也需要通过cgi合约转换成nginx可以理解的信息。 最后，nginx接收到这些信息并将其返回给浏览器。
快速cgi
传统的cgi合约会开启一个进程来处理每个连接请求，处理完后关闭该进程，所以最后一个连接会再次开启一个进程来处理，所以有多少个连接就有多少个cgi进程，这就是为什么传统cgi的原因变得平坦，因此太多进程消耗资源和视频内存。
每个请求被fast-cgi处理完后，并不会杀死该进程，而是保留该进程，以便该进程可以一次处理多个请求。 这样就不用每次都重新fork一个进程了，大大提高了效率。
php-cgi
php-cgi是php向webserve，即http后端服务器提供的cgi合约socket程序。 每次收到http后端服务器的请求，都会打开一个php-cgi进程进行处理，而在打开php-cgi进程的过程中php删除空数组，都要重新加载配置、数据结构和初始化运行环境第一的。 如果更新了php配置，那么需要重启php-cgi才能生效，比如phpstudy。
php-fpm
php-fpm是php向webserve，即http后端服务器提供的fastcgi合约socket程序。 它不会像php-cgi那样每次连接时都会重新启动一个进程，并在处理完请求后关闭该进程，而是允许一个进程处理多个连接，并且该进程不会立即关闭，而是会继续处理下一个连接。 可以说是php-cgi的一个管理程序，也是对php-cgi的改进。
php-fpm会打开多个php-cgi程序，但是php-fpm是常驻显存的，每次webserve服务器发送连接时，php-fpm都会将连接信息分配给php-cgi下面的子程序之一进行处理后处理完后，php-cgi不会关闭，而是继续等待下一次连接，这也是fast-cgi加速的原理，而且由于php-fpm是多进程的，一个php-cgi基本消耗7- 25M显存，所以如果连接数过多，就会消耗过多的显存，导致一些问题，比如nginx出现502错误。
同时，php-fpm还附带了一些其他功能：
比如平滑过渡配置修改，普通的php-cgi每次修改配置后都需要重启来初始化新的配置，但是php-fpm则不需要，php-fpm会将新的连接发送给新的子程序php- cgi，此时加载了新的配置，运行的php-cgi仍然使用原来的配置。 这次连接之后，下一次连接就会用新的配置进行初始化，这是一个平滑的过渡。
参考链接：...
PHP5和PHP7的区别
PHP7.0在性能提升方面堪称革命性的版本。 面对Facebook的HHVM引擎带来的压力，开发团队重新绘制了底层的ZendEngine，命名为ZendEngine2。
底层内核分析
PHP7中最重要的变化是zval不再单独从堆中分配显存，并且不存储自己的引用计数。 需要使用 zval 指针的复杂类型（例如字符串、数组和对象）存储自己的引用计数。 这会导致更少的视频内存分配操作、更少的间接指针使用以及更少的视频内存分配。 在PHP7中，zval已经变成了值指针，它要么保存原始值，要么指向保存原始值的指针。 也就是说现在的zval相当于PHP5中的zval。 与zval相比，直接存储zval，我们可以省去一次指针解引用，从而提高缓存友好性。
参考链接：
为什么PHP7比PHP5性能更好
1、变量存储字节减少，减少了内存占用，提高了变量运行速度。
2.改进链表结构。 链表元素和哈希映射表分配在同一个显存中，增加显存占用，提高CPU缓存命中率。
3.改进了函数调用机制。 通过优化参数传递过程，减少了部分指令，提高了执行效率。
安全
功能改变
preg_replace() 不再支持 /e 修饰符，官方给了我们一个新函数 preg_replace_callback
create_function() 已被弃用，它实际上执行 eval。
mysql* 系列的所有成员均已被删除。 如果想在PHP7中使用老版本的mysql*系列函数，需要自己安装。 正式版本不再包含在内。 现在官方推荐的是mysqli或者pdo_mysql。
unserialize()减少了一个可选的白名单参数，当然是白名单。 如果反序列化数据上的类名不在这个白名单中，就会报错。
默认情况下，assert() 不能再执行代码
句子变化
foreach 不再更改内部字段表指针
提高8补码字符的容错率。 在php5版本中，如果8补码字符包含无效数字，则无效数字将被静默删除。 php7 上会触发解析错误。
十六进制补码字符串不再被视为数字
不仅移动 ASP 和 scriptPHP 标签
将浮点数转换为整数时，如果浮点值太大而无法用整数表示，在 PHP5 版本中，转换会直接截断整数，不会导致错误。 在PHP7中，会报错。
全面的
性能提升：PHP7的性能是PHP5.0的两倍。
完整且一致的 64 位支持。
以前很多致命错误现在都改成了【抛出异常】。
与PHP5.0相比，PHP7.0不仅仅是一些旧的不支持的SAPI（[服务器端]应用程序编程端口）和扩展。
.PHP7.0比PHP5.0有一个新的空连接运算符。
PHP7.0比PHP5.0更新，减少了比较运算符的组合。
PHP7.0比PHP5.0更新，减少了函数的返回类型声明。
与 PHP5.0 相比，PHP7.0 新减少了标量类型声明。
PHP7.0 比 PHP5.0 具有更低的匿名类。
多个进程同时读写一个文件
PHP支持进程，不支持多线程（这个先澄清一下）。 如果是针对文件操作，虽然只需要加锁文件就可以解决，不需要其他操作，PHP的flock已经帮你做好了。
使用flock在写入前对文件加锁，写入后解锁，这样多个线程可以同时读写一个文件，防止冲突。
过程
flock参数说明：file为必填项，指定要锁定或释放的打开文件，需要lock。 指定要使用的锁类型。 块是可选的。 如果设置为 1 或 true，则锁定时阻止其他进程。
LOCK_SH 获取共享锁（读程序）
LOCK_EX 获取排它锁（写程序）
LOCK_UN 释放锁（无论共享还是独占）
LOCK_NB 如果你不希望flock()在锁定时阻塞
但在 PHP 中，flock 工作得不太好！ 在多并发的情况下，虽然资源经常被独占，但资源并没有立即释放，或者根本没有释放，导致死锁，进而使得服务器的CPU占用率非常高，有时甚至会导致服务器跑掉完全地。 嗯，在使用flock之前一定要仔细考虑一下。
解决方案
锁定文件时，设置一个超时时间，超时设置为1ms，如果在这个时间内没有获取到锁，就会重复获取，直到直接获取到文件的操作权，事实上。 如果达到超时限制，必须立即退出并放弃锁，以便其他进程可以操作。
不使用flock功能，使用临时文件来解决读写冲突问题。
考虑将需要更新的文件复制一份到我们的临时文件目录中，将文件的最后修改时间保存到一个变量中，并为这个临时文件取一个不容易重复的随机文件名。
更新此临时文件后，检查原文件的最后更新时间是否与之前保存的时间一致。
如果上次更改时间相同，则将更改后的临时文件重命名为原始文件。 为了保证文件状态同步更新，需要对文件状态进行清理。
但如果最后一次修改时间与之前保存的时间相同，则说明原文件在这段时间内已经被更改过。 这时需要删除临时文件，然后返回false，说明此时文件中有其他进程。 操作。
随机读写正在操作的文件，以减少并发的可能性。
本来需要定义一个随机空间。 空间越大，并发的可能性就越小。 这里假设随机读写空间为[1-500]，所以我们的日志文件的分布范围为log1到log500。 用户每次访问时，数据会随机传输到log1~log500之间的任意文件中。 同时有两个进程记录日志。 进程A可能是更新后的log32文件，但是进程B呢？ 那么此时更新的可能性就是log399。 要知道，如果想让进程B也操作log32，概率基本就是1/500，几乎等于0。 当我们需要分析访问日志时，只需要将这些日志先合并，然后再进行分析即可。 使用这些方案进行日志记录的好处之一是进程操作不太可能排队，从而允许进程非常快速地完成每个操作。
将所有要操作的进程放入队列中。
队列中每个被排除的进程相当于第一个具体操作，因此我们的服务第一次只需要从队列中获取对应的具体操作项即可。 如果这里还有大量的文件操作进程，没关系，站在我们队列旁边就可以了。 只要你乐意排队，排队多长都没关系。
