up:: 定制化tomcat内嵌开发
说明： 虽然前面我们优化了并发线程上限以及keepalive的优化问题，但是当并发数越来越多，http的响应时间也越来越长，直到TPS达到一定上限，效率就会非常低下了。。。
那对于单台应用来说，简单的一个主键查询都需要那么久的耗时，那其实对于我们的一个大型的企业级的电商网站上来说是不能容忍的。我们来看一下我们对应的一个优化的方向。 那首先我们总结出了一个规律，也就是一个单台的web应用容器的一个上限
性能测试：TPS和QPS的区别 - 全栈测试笔记 - 博客园
性能测试指标TPS（Transaction per Second）总结_we_opkn的博客-CSDN博客_tps指标
单web容器的上限
那对于一个四核的CPU。8g的内存的单进程调度线程数控制在800到1千。
只要在1000以上CPU，就会花费大量的时间在一个线程的调度上。
也就是说，我们的服务器，我们的应用的线程数绝对不是越多越好，那所谓的高并发多线程也是有一个拐点的概念。
什么叫拐点呢？也就是说我们对应的服务器的吞吐量TPS会随着支持的并发线程数的逐渐增多，但是直到某一个拐点上，线程再往上面扩大量的CPU的消耗会花费在线程的调度以及CPU的内存切换的时间上。我们的CPU处理那么多的线程，就会显得力不从心，因此会有一个拐点。那我们对于一个四核的CPU 8g的内存来说，我们经过压力测试，对应的一个拐点是在800个线程左右。 这个大家要记住。。。
每台超过我们就要考虑增加服务器进行扩容处理了。。。
如果说对应的并发请求超过800了，那就会进入对应的队列做缓冲时。但是也不能无限长，因为对应的缓冲区是消耗内存的，而且出队入队也耗CPU。一般我们就设在1千到2千左右就可以了，再超过了，那不好意思就拒绝连接，说明我们整个应用的集群就有问题，那我们需要将单台web的容器。扩展为多台，甚至于上万台，上亿台。
Mysql数据库QPS的容量问题
比如说我们的根据订单状态查询我们对应的一个订单表。那对应的这个订单状态字段就必须得是非唯一索引的查询，因为不走索引的话就是全表扫描。全表扫描在我们的大型的企业级应用当中，根本就是不可以接受的，甚至于我们的数据库到达千万级别的数据之后。非为索引的查询也会产生对应的一个压力，之后就是需要我们要考虑到一个分库分表。
我们需要尽量使用主键查询和唯一索引，如果实际情况不允许的化，我们就要考虑分库分表进行分布式扩容处理了。。。
mysql数据库TPS容量问题
最后可以看看学习思考