再重复一次,并没有一个明确的答案或解决方法可以通用适配这类问题;
正常,如果有条件,可以在一个相似的测试环境进行压力测试,如果没有条件,可以在生产环境直接收集相关性能参数,定位瓶颈究竟在那里?在客户端,广域网,防火墙,web服务器,应用服务器,数据库服务器,还是? 知道了瓶颈在那里,才能有针对性的进行解决,否则就可能是碰运气,或者纯粹的升级硬件资源(确实有时候也能解决);
(更专业一点的,会在这里取一个基线,便于后续优化后进行参考对比)
(比如瓶颈在应用服务器或数据库)
第二步再定位对应的服务器中,是CPU、内存,存储等那一个存在短缺;还是网络响应速度比较慢(这里又有很多不同情形造成);
(比如是内存不足)
第三步,再看是什么消耗了内存,如果是用户代码部分,定位那一片代码造成的较大内存消耗或者内存泄漏,进行代码或SQL的优化;
第四步,(有时和第三步同步进行),确认是否可以调整操作系统,中间件应用系统,数据库的某些参数,来优化系统资源的使用;或者使用固态硬盘,升级网络设备等来优化系统性能;(有些部署的工程师缺乏经验,系统是默认安装,没有对系统参数进行调整,并不能完全发挥硬件全部性能,或者匹配具体应用系统的特点)
第五步,上面三、四步都做了,还达不到要求;那可能要从架构设计上进行调整,这里又很多门道...
以上每一步都有相应的工具和方法进行分析处理;
面对高并发高请求的大型JAVA应用场景,需要考虑到以下几个方面并并进行优化:
1、代码方面从最基础的做起,优化所写代码,减少不必要的资源浪费,比如:避免频繁的new对象,优先考虑使用单例模式、减繁去重,重用代码要归纳成公用方法,相关工具类使用静态方法访问、使用java中效率高的类等等;
2、数据库方面当面对复杂的应用,用户大量访问的时候,一台数据很快无法满足需求,这时就需要使用数据库集群或者库表散列。
常用的优化措施是M-S(主-从)方式进行同步复制,将查询和操作和分别在不同的服务器上进行操作,这样会大大减少数据库操作耗时;
3、静态资源方面我们可以把一些访问频次高但是变更不大的动态请求提前渲染生成html静态页面,然后每次用户再访问该请求时,就不要再调用服务器请求了,这样会大大减少高峰期时服务器的压力;
在静态资源例如图片、js、css等方面,我们可以将这些资源与核心应用和html资源分离开,建立合适的静态文件服务器,针对不同类型的静态资源对服务器进行优化配置,这样就不会再高并发时因为这些静态资源的问题而使整个页面崩溃了;
4、其他方面缓存:尽量使用缓存,包括用户缓存,信息缓存等,多花点内存来做缓存,可以大量减少与数据库的交互,提高性能。
可以考虑memcached缓存集群和静态HTML、Redis缓存
负载均衡:nginx(异步)、squid(同步)、lighttpd(异步)
存储:分布式的,如hadop等
欢迎分享,转载请注明来源:夏雨云
评论列表(0条)