我原本想尝试从服务器的任意目录访问文件,但是经过数次的尝试,网上教的通过修改Tomcat路径映射和自定义XML来进行文件映射都不能成功访问到目标文件。
最后查到,把文件放在Tomcat的ROOT目录下,就可以用服务器域名+“/”+“文件名(带后缀)”直接访问到文件,亲测成功,。
提到服务器性能测试,不得不提到很多术语。为了让大家更容易理解,举个生活中的例子:你中午去“海底捞”吃饭。
我们可以把“海底捞”这个酒楼看成一个被测系统。
你去吃饭,就是对这个被测系统发起请求,对这个系统造成了一定的负载。你带去的人越多,那么这个餐馆就越繁忙,可以说餐馆承受的负载就越大。
你开始点菜。这个时候你隔壁桌的人也开始点菜。那么你们两个对这个系统产生了并发的请求。同时,其他桌有的在吃菜,有的在等菜,这些都是并发进行的事务。一个完整的吃饭事务可以定义成包括:点菜,下单,上菜,买单四个步骤。对于一个C/S的系统来说,可以对应于:建立连接,发送请求,接受应答,断开连接。
影响一个餐馆生意好坏的一个重要原因是上菜速度。上菜速度体现在两个方面:
很多因素会影响上菜速度,比如服务员的个数、厨师的个数。对于一个C/S的系统,服务员相当于是接入层,厨师相当于是后台服务。假如服务员太少,下单很慢,后面的厨师都闲着,那么上菜速度也快不了;假如服务员够多,下单足够快,但是厨师太少,下的单来不及做,同样上菜速度也很慢;如果服务员很多,厨师也很多,但是来的客人很少,那么大部分的服务员和厨师都闲着,资源全部浪费掉了。因此,接入层和后台服务进程个数、以及资源配比,都是需要根据实际情况进行调优的。
来多少顾客,这是酒楼自己无法控制的,但是酒楼的上菜速度、餐位多少都会制约客流量。一定有一个峰值客流量,当来的客人超过了这个峰值,那么这些客人就会等位,或者是上菜速度超慢让客人无法容忍。容量测试就是通过工具模拟足够多的顾客来吃饭的事务,希望找到这样一个客流量对酒楼产生一定的负载,这个时候酒楼既能接待最多的客户同时也能保证最短的等待时间。更多的,还可以对这个酒楼人员配置和餐位设置等进行调优,以期达到一个最理想的资源利用率和效率。
客流量跟进来的客人多少有关,也跟餐馆的接待能力有关。单方面增加来就餐的顾客,遭到投诉的可能性就越大,上错菜的可能性也越大。
1.一个顾客请求的处理耗时,从下单到上菜中间等待的时间,我们称之为响应时间。
2.这个餐馆同时为多名顾客上菜的频率,我们称之为吞吐量。
欢迎分享,转载请注明来源:夏雨云
评论列表(0条)