企业官网建设流程全解析

玖壹购网站是做啥子的,wordpress源码解读,848给我做一下88网站,云南百度推广开户公司某个系统的微信端计划将开放给几百上千的人员登录查询#xff0c;并且登录账号为同一账号多人使用。 后台服务能够支撑起多用户的并发操作以及成百上千人登录微信端对生产数据库或者登录查询的性能效率高成为交付可靠生产环境的必要条件。 因此#xff0c;项目组决定提…公司某个系统的微信端计划将开放给几百上千的人员登录查询并且登录账号为同一账号多人使用。后台服务能够支撑起多用户的并发操作以及成百上千人登录微信端对生产数据库或者登录查询的性能效率高成为交付可靠生产环境的必要条件。因此项目组决定提交测试由测试人员通过自动化方式模拟并发场景以验证程序的可靠性。问题点描述测试初期随着时间的推移Loadrunner客户端不断出现事务通过率下降的情况或因为连接不上服务端或因为连接超时现象1大用户并发一段时间后服务器吞吐率降到0而后所有请求出现无法连接到服务器。现象2根据目标1000个并发请求进行结果验证吞吐量在运行一段时间后有下降趋势最后服务端支撑不起若干请求 failed to connected to server 若干请求connect timed out。这些现象都直接说明了系统服务端暂无法支撑起大并发用户的访问。思路和方法我们需要进一步移位到服务端Linux-tomcat服务器通过性能分析手段来分析问题并根据定位出的具体问题来展开调优手段解决问题主要的分析工具有1. Linux-top命令一个用户程序的执行离不开管理它的操作系统top命令是Linux操作系统下实时查看服务器资源情况的其中一种命令它可以输出操作系统资源概况信息和进程信息。2. Jstack工具Jstack这是一个在JDK5开始提供的内置工具可以打印指定进程中线程运行的状态包括线程数量、是否存在死锁、资源竞争情况和线程的状态等等。以及如netstat -anp|grep 端口号|wc -l 查询http连接数、查询数据库连接数Ps -LF pid 查询线程情况ps -eLo pid,stat|grep 20017|grep Sl|wc -l查询线程S1状态个数等等其他Linux命令了解当前当前服务器运行情况。调优方案01 现象1的性能分析过程及对应的调优手段一分析过程使用top命令查询服务器资源结果CPU占用资源过大内存、磁盘资源正常根据top 1 占用cpu资源的排行定位到占用资源率高的进程idpid进行进一步分析Tomcat对应的java进程程占用CPU资源率最高记录下java进程号top -hp 进程号 打印线程信息记录下占用CPU资源异常的线程号tid查看线程情况其中某线程cpu占用率高使用 printf %x \ntid 命令将异常线程id转成十六进制的值thread-hex-id通过jstack工具输出当前的线程信息jstack -l pid | grep thread-hex-id -A 10thread dump文件显示出程序在执行org.apache.commons.collections.ReferenceMap..getEntry()方法时处于获取到锁资源的可运行状态heap dump 中JVM堆中对象使用的情况正常。过5分钟后再次通过通过jstack工具输出当前的线程信息jstack -l pid | grep thread-hex-id -A 10thread dump文件显示出程序在执行org.apache.commons.collections.ReferenceMap..getEntry()方法时处于获取锁资源的可运行状态heap dump 中JVM堆中对象使用的情况正常。对比前后两次的线程信息进行分析两个线程在长达5分钟时间里一直在执行org.apache.commons.collections.ReferenceMap.getEntry()方法未能释放锁进入了死循环。而其他多线程处于等待锁资源的状态造成了blocked阻塞。二对应的调优手段百度查询wait to lockorg.hibernate.util.SoftLimitMRUCache出此类似的问题为hibernate3.1,x的bug造成了线程不安全hashMap等线程不安全的容器用在多线程读/写的场合导致hashmap的方法调用造成死循环解决方法是更换hibernate版本。02 现象2的性能分析过程及对应的调优手段一分析过程当前配置下逐渐增加服务器负载根据tps 查找最佳线程数。500用户并发时tps出现拐点使用500个用户并发运行一段时间服务器吞吐率逐渐下载而后开始产生一些连接超时的问题最后出现connect timeout分析tomcat配置连接数、线程数以及队列长度Connector port8080 protocolHTTP/1.1 connectionTimeout2000000 redirectPort8443 minSpareThreads100 maxSpareThreads500 acceptCount1000 /从以上信息了解到服务端采用的是tomcat BIO模式配置中未指定最大线程数则默认为200未指定连接数则Bio下 connect max connectionsmax thread200tomcat一开始可处理acceptCountmaxConnections的请求已进入acceptcount但无法处理的先出现connect timeout最后无法进入acceptcount的出现connect refuse。二对应的调优手段根据目标支撑数调整tomcat配置线程数和队列长度。Connector port8080 protocolHTTP/1.1 connectionTimeout2000000 redirectPort8443 maxThreads1000 acceptCount1000 /修改后500个用户并发运行30min服务器吞吐率保持稳定继续进行100-200-300 到1000个用户并发场景结合Loadrunner和服务端资源验证结果原先运行10min就开始报错现在并发运行48min期间吞吐量稳定48min后出错是现象1的问题服务端内存占用率稳定tomcat配置修改有效。总结Loadrunner工具是以客户的角度分析应用业务是否可用服务体验是否满意它不需要知道系统的业务流向和系统的架构设计但系统瓶颈分析和调优时却需要这些知识。面对日益复杂的系统负载系统的性能也受许多因素的影响如处理器速度、内存容量、网络、I/O、磁盘容量、中间件连接池配置等等。因此要求我们对计算机硬件、操作系统和应用有相当深入的了解我们才能合理动用脑袋中的知识库以分析和解决问题。在分析系统瓶颈和调优问题上本人也没有搭建起完整的知识体系框架来在此只能分享我浅薄的几点经验1.了解被测项目的架构如是否用了缓存用了集群、负载均衡用了哪些应用以及对应配置、特性如redis是内存数据库特性是占用内存会大对磁盘资源依赖少。如常见的关系型数据库对CPU、内存、磁盘都有比较高的要求web应用如果对文件进行操作那可先分析磁盘I/O、内存。2. 运用抓包、日志等工具分段定位瓶颈位置前端页面、后台服务端还是数据库。3. 对于测试对象是web应用类型的经常出问题的是它中间件的配置、程序代码和其依赖的服务器资源一般出错时有后台服务端日志可以参考。4. 对于web应用要了解tcp工作原理java应用了解进程、线程状态及工作情况。5. 优先排查应用程序问题一般应用程序和资源表现有关系应用服务端关注连接模式及配置、jvm内存泄露、溢出、应用程序逻辑。6. 操作系统关注包含了操作系统的系统参数、内核参数、进程参数、文件系统、磁盘IO等7. 数据库关注连接池、sql语句、索引、死锁系统分析的主要目标是识别出哪些工作负荷是影响当前吞吐量的瓶颈总体来说有很多有用的信息分析工具可以用且分析方法并不是唯一本次实践在物流查询系统中出现的问题也只是性能问题里的冰山一角。通过性能分析和对应的调优手段我们提升了系统的响应能力为用户带来更好的使用体验。在其他场景我们通过架构、应用逻辑上的优化还可以不需要对硬件系统进行扩容用更少的硬件资源支撑更大量的业务发展从而达到节省硬件投资的目的性能调优带来收益是巨大的。在性能分析手段上本人也还在努力学习分享以上测试经验希望大家少走弯路希望能够帮助初学者解决一些问题共同进步。感谢每一个认真阅读我文章的人礼尚往来总是要有的虽然不是什么很值钱的东西如果你用得到的话可以直接拿走这些资料对于【软件测试】的朋友来说应该是最全面最完整的备战仓库这个仓库也陪伴上万个测试工程师们走过最艰难的路程希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取