1:配置executor属性
打开/conf/server.xml文件,在Connector之前配置一个线程池:
重要参数说明:name :共享线程池的名字。这是Connector为了共享线程池要引用的名字,该名字必须唯一。默认值:None; namePrefix :在JVM上,每个运行线程都可以有一个name 字符串。这一属性为线程池中每个线程的name字符串设置了一个前缀,Tomcat将把线程号追加到这一前缀的后面。默认值:tomcat-exec-; maxThreads :该线程池可以容纳的最大线程数。默认值:200; maxIdleTime :在Tomcat关闭一个空闲线程之前,允许空闲线程持续的时间(以毫秒为单位)。只有当前活跃的线程数大于minSpareThread的值,才会关闭空闲线程。默认值:60000(一分钟)。 minSpareThreads :Tomcat应该始终打开的最小不活跃线程数。默认值:25。
2:配置Connector
重要参数说明:executor :表示使用该参数值对应的线程池; minProcessors :服务器启动时创建的处理请求的线程数; maxProcessors :最大可以创建的处理请求的线程数; acceptCount :指定当所有可以使用的处理请求的线程数都被使用时,可以放到处理队列中的请求数,超过这个数的请求将不予处理。
一.Tomcat内存优化
Tomcat内存优化主要是对 tomcat 启动参数优化,我们可以在 tomcat 的启动脚本 catalina.sh 中设置JAVA_OPTS 参数。
1.JAVA_OPTS参数说明
现公司服务器内存一般都可以加到最大2G ,所以可以采取以下配置:
在cygwin=false前添加
配置完成后可重启Tomcat ,通过以下命令进行查看配置是否生效:
首先查看Tomcat 进程号:
result
我们可以看到Tomcat 进程号是27698 。
查看是否配置生效:
能在输出的信息中找到Heap Configuration中看到MaxHeapSize 等参数已经生效。
二.Tomcat并发优化
1.Tomcat连接相关参数
在Tomcat 配置文件 server.xml 中的 配置中
1.参数说明
minProcessors :最小空闲连接线程数,用于提高系统处理性能,默认值为 10 maxProcessors :最大连接线程数,即:并发处理的最大请求数,默认值为 75 acceptCount :允许的最大连接数,应大于等于 maxProcessors ,默认值为 100 enableLookups :是否反查域名,取值为: true 或 false 。为了提高处理能力,应设置为 false connectionTimeout :网络连接超时,单位:毫秒。设置为 0 表示永不超时,这样设置有隐患的。通常可设置为 30000 毫秒。其中和最大连接数相关的参数为maxProcessors 和 acceptCount 。如果要加大并发连接数,应同时加大这两个参数。web server允许的最大连接数还受制于操作系统的内核参数设置,通常 Windows 是 2000 个左右, Linux是 1000 个左右。
2.Tomcat中的配置示例
2.调整连接器connector的并发处理能力
1.参数说明
maxThreads :客户请求最大线程数 minSpareThreads :Tomcat初始化时创建的 socket 线程数 maxSpareThreads :Tomcat连接器的最大空闲 socket 线程数 enableLookups :若设为true, 则支持域名解析,可把 ip 地址解析为主机名 redirectPort :在需要基于安全通道的场合,把客户请求转发到基于SSL 的 redirectPort 端口 acceptAccount :监听端口队列最大数,满了之后客户请求会被拒绝(不能小于maxSpareThreads ) connectionTimeout :连接超时 minProcessors :服务器创建时的最小处理线程数 maxProcessors :服务器同时最大处理线程数 URIEncoding :URL统一编码
2.Tomcat中的配置示例
3.Tomcat缓存优化
1.参数说明
compression :打开压缩功能 compressionMinSize :启用压缩的输出内容大小,这里面默认为2KB compressableMimeType :压缩类型 connectionTimeout :定义建立客户连接超时的时间. 如果为 -1, 表示不限制建立客户连接的时间
2.Tomcat中的配置示例
4.参考配置
1.旧有的配置
参考网络对服务器做过如下配置,拿出来分享下:
后来发现在访问量达到3 百万多的时候出现性能瓶颈。
2.更改后的配置
使用高性能的服务器、高性能的数据库、高效率的编程语言、还有高性能的Web容器,(对架构分层+负载均衡+集群)这几个解决思路在一定程度上意味着更大的投入。
1、高并发:在同一个时间点,有大量的客户来访问我们的网站,如果访问量过大,就可能造成网站瘫痪。
2、高流量:当网站大后,有大量的图片,视频,这样就会对流量要求高,需要更多更大的带宽。
3、大存储:可能对数据保存和查询出现问题。
解决方案:
1、提高硬件能力、增加系统服务器。(当服务器增加到某个程度的时候系统所能提供的并发访问量几乎不变,所以不能根本解决问题)
2、本地缓存:本地可以使用JDK自带的Map、Guava Cache.分布式缓存:Redis、Memcache.本地缓存不适用于提高系统并发量,一般是用处用在程序中。
Spiring把已经初始过的变量放在一个Map中,下次再要使用这个变量的时候,先判断Map中有没有,这也就是系统中常见的单例模式的实现。
场景很重要,比如一万并发的qps还是tps,这完全不同的概念。 服务器做做优化,现在通过epoll支撑百万连接十万并发没什么瓶颈。但是,这只是网络层,如果落到具体业务,那就另当别论了。比如redis可以十万并发,因为只需要网络io和访问内存。但是如果有业务处理,挂上了数据库,走了kafka,并且再走redis,那就要具体问题具体分析了。 数据库单存qps,我们原来基准测试结果是可以支撑六万到八万左右,但是有事务的增删改绝对不是这个量级。 其实你需要的是一个基准测试的结果,例如tcp,http基准测试;tomcat基准测试;应用框架基准测试;redis基准测试;mysql基准测试等。 我们做过应用框架基准测试,基于springboot,测试接口没什么逻辑,就是直接查询sql并返回结果。基准测试结果是八核16G内存,跑两个实例,可以撑到8万并发左右,应该还有优化空间吧。 你这问题就和一天跑一百公里要个什么车一样,也不说什么路,也不说拉什么货 撇开场景扯性能,扯吞吐量,扯并发都是耍流氓 几台服务器加F5,一台不牢靠 看你什么样的场景,业务复杂度,就个静态页面,给你两台ng就搞定了 允许配置全站加速吗?另外需求不明确 32核128G内存 不可以,如果是短期高并发,建议考虑挂载负载均衡服务器。 C10kp……这是很经典的问题啊,一般nio就做到了。 要看性能要求了,如果只讨论并发数量,用异步网络模型,并发一万个链接没啥问题吧,只是数据处理不过来,大多数链接都是在等待结果而已。服务器配置1核8g差不多够了吧欢迎分享,转载请注明来源:夏雨云
评论列表(0条)