大家好，又见面了，我是你们的朋友全栈君。
下面的都是整理别人的加上自己的一些思考，有什么不对请多多指教。
1.公式：
响应时间(RT)是指系统对请求作出响应的时间。
吞吐量(Throughput) 是指系统在单位时间内处理请求的数量。
并发用户数（Maximum concurrent user ）是指系统可以同时承载的正常使用系统功能的用户的数量。
吞吐量一般指相当一段时间内测量出来的系统单位时间处理的任务数或事务数（我的理解，请求无非是读或者写。写可以参考TPS、读可以参考QPS）
TPS：是Transactions Per Second的缩写，也就是事务数/秒。它是软件测试结果的测量单位。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数。
QPS：是Queries Per Second的缩写，意思是每秒查询率，是一台服务器每秒能够相应的查询次数，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。
QPS（TPS）= 并发数/平均响应时间
ps：并发一定，响应时间小，吞吐量大，所以读写吞吐量是要区分的。并发超过一定数字后，如果压力继续增大，系统的吞吐量反而会下降，原因是系统超负荷工作，上下文切换、内存等等其它消耗导致系统性能下 降。
2.优化（两者都可以通过缓存，优化sql等减少响应时间来优化，除了这个还有下面的方案）
吞吐量
1、增加硬件设备
2、提高程序处理能力
Master-Worker模式是常用的多任务并行处理模式，它的核心思想是，系统由两类进程协作工作：Master进程和 Worker进程。Master-Worker模式是一种将串行任务并行化的方法，被分解的子任务在系统中可以被并行处理。同时，如果有需要，Master进程不需要等待所有子任务都完成计算，就可以根据已有的部分结果集计算最终结果。
https://baijiahao.baidu.com/s?id=1615663057253029648&wfr=spider&for=pc
并发
当一个进程有 500 个线程在跑的话，那性能已经是很低很低了。Tomcat 默认配置的最大请求数是 150，也就是说同时支持 150 个并发，当然了，也可以将其改大。操作系统对于进程中的线程数有一定的限制： Windows 每个进程中的线程数不允许超过 2000 Linux 每个进程中的线程数不允许超过 1000 另外，在 Java 中每开启一个线程需要耗用 1MB 的 JVM 内存空间用于作为线程栈之用。 Tomcat的最大并发数是可以配置的，实际运用中，最大并发数与硬件性能和CPU数量都有很大关系的。更好的硬件，更多的处理器都会使Tomcat支持更多的并发。 Tomcat 默认的 HTTP 实现是采用阻塞式的 Socket 通信，每个请求都需要创建一个线程处理。这种模式下的并发量受到线程数的限制，但对于 Tomcat 来说几乎没有 BUG 存在了。 Tomcat 还可以配置 NIO 方式的 Socket 通信，在性能上高于阻塞式的，每个请求也不需要创建一个线程进行处理，并发能力比前者高。但没有阻塞式的成熟。 这个并发能力还与应用的逻辑密切相关，如果逻辑很复杂需要大量的计算，那并发能力势必会下降。如果每个请求都含有很多的数据库操作，那么对于数据库的性能也是非常高的。 对于单台数据库服务器来说，允许客户端的连接数量是有限制的。 并发能力问题涉及整个系统架构和业务逻辑。 系统环境不同，Tomcat版本不同、JDK版本不同、以及修改的设定参数不同。并发量的差异还是满大的。 maxThreads=”1000″ 最大并发数 minSpareThreads=”100″///初始化时创建的线程数 maxSpareThreads=”500″///一旦创建的线程超过这个值，Tomcat就会关闭不再需要的socket线程。 acceptCount=”700″// 指定当所有可以使用的处理请求的线程数都被使用时，可以放到处理队列中的请求数，超过这个数的请求将不予处理
https://blog.csdn.net/Jacabe/article/details/53747289
3.参考值
吞吐量
这里就大致根据理论最大QPS，给网站做几个分类
50QPS以下——小网站
没什么好说的，简单的小网站而已，就如同本站这样，你可以用最简单的方法快速搭建，短期没有太多的技术瓶颈，只要服务器不要太烂就好。
50～100QPS——DB极限型
大部分的关系型数据库的每次请求大多都能控制在0.01秒左右，即便你的网站每页面只有一次DB请求，那么页面请求无法保证在1秒钟内完成100个请求，这个阶段要考虑做Cache或者多DB负载。无论那种方案，网站重构是不可避免的。
300～800QPS——带宽极限型
目前服务器大多用了IDC提供的“百兆带宽”，这意味着网站出口的实际带宽是8M Byte左右。假定每个页面只有10K Byte，在这个并发条件下，百兆带宽已经吃完。首要考虑是CDN加速／异地缓存，多机负载等技术。
500～1000QPS——内网带宽极限＋Memcache极限型
由于Key/value的特性，每个页面对memcache的请求远大于直接对DB的请求，Memcache的悲观并发数在2w左右，看似很高，但事实上大多数情况下，首先是有可能在次之前内网的带宽就已经吃光，接着是在8K QPS左右的情况下，Memcache已经表现出了不稳定，如果代码上没有足够的优化，可能直接将压力转嫁到了DB层上，这就最终导致整个系统在达到某个阀值之上，性能迅速下滑。
1000～2000QPS——FORK/SELECT，锁模式极限型
好吧，一句话：线程模型决定吞吐量。不管你系统中最常见的锁是什么锁，这个级别下，文件系统访问锁都成为了灾难。这就要求系统中不能存在中央节点，所有的数据都必须分布存储，数据需要分布处理。总之，关键词：分布
2000QPS以上——C10K极限
尽管现在很多应用已经实现了C25K，但短板理论告诉我们，决定网站整体并发的永远是最低效的那个环节。我承认我生涯中从未遇到过2000QPS以上，甚至1.5K以上的网站，希望有此经验的哥们可以一起交流下
http://www.litrin.net/2013/03/27/web网站的几个并发量级/
并发
当一个进程有 500 个线程在跑的话，那性能已经是很低很低了。Tomcat 默认配置的最大请求数是 150，也就是说同时支持 150 个并发，当然了，也可以将其改大。
当某个应用拥有 250 个以上并发的时候，应考虑应用服务器的集群。
https://blog.csdn.net/Jacabe/article/details/53747289
发布者：全栈程序员栈长，转载请注明出处：https://javaforall.cn/179131.html原文链接：https://javaforall.cn
