Defonds 的专栏

可以使用函数 __javaScript 来执行 JavaScript 代码片：${__javaScript((Math.random() * (100)).toFixed(2) * 1,)}以上将生成 0 ~ 100 的带两位小数的浮点数。说明如下：Math.random() 生成 0 ~ 1 的小数Math.random() * (100) 生成 0 ~ 100 的浮点数toFixed(2) 将生成的浮点数保留 2 位小数如果想生成 100 ~ 200 内的带两位小数的浮点数，可以：$

在对某项目进行压测时，阿里云 PTS 压测工具监测到在某个时间点后 tps 呈下降趋势：作为对应指标的响应时间(rt)在这个时间点呈上升趋势：查看实时监控-监控集指标，发现 publisher1 节点的 CPU 利用率已降为 1.9，在高并发的时候这个值肯定是有问题，很可能这个节点已经宕掉:查看网络流量发现该节点果然已经没有了网络流量：ssh 登录 publisher1 ps 证实 Tomcat

表述性状态传输(REST)作为对基于 SOAP 和 Web 服务描述语言(WSDL)的 Web 服务的简单替代，在 Web 开发上得到了广泛的接受。能够充分证明这点的是主流 Web 2.0 服务提供商在接口设计中对 REST 的普遍采用 - 包括雅虎、谷歌以及脸谱 - 出于简单易用、以面向资源的模型发布自己的服务的偏好他们都已经抛弃了 SOAP 和基于 WSDL 的接口。在你必须要对你的 REST

熟悉 LoadRunner 的朋友一定不会对其 TPS(每秒事务数)、TRT(事务响应时间) 等视图感到陌生，因为这是压力测试最为关键的两个指标。JMeter 以其开源、灵活、扩展性高等特性赢得了广大测试从业人员的青睐，但是它没有像 LoadRunner 那样提供一个 TPS、TRT 之类的视图，虽然聚合报告也能说明一些整体以及实时的问题，但是就整体趋势、稳定性报告方面就无能无力了，见下图：所幸的

做压力测试，我喜欢先写 JMeter 脚本，功能测通以后再翻译成 LoadRunner 脚本，最后用 LoadRunner 完成压测。也许我是 Java 出身吧，对 JMeter 总是有一种亲切感用着得心应手，而 LoadRunner 稳定性、强大而友好的结果分析功能又是我无法抗拒的...

用 Badboy 录制的脚步，有个界面是 Ajax 提交表单，先有 HTTP Status 415 错误(解决方案参考《一次 JMeter 脚本请求错误 HTTP Status 415 的解决笔记》)，然后又有 Could not read JSON: Unexpected character ('%' (code 37)): expected a valid value 错误。监听器 "察看结果

根据 web 应用的复杂度你可以选择创建两种类型的 JMeter 测试计划：面向点击数的或面向场景的。创建一个面向点击数的测试计划你需要有中值统计。这些统计要包含你的应用每秒应该处理多少个独立请求的相关信息。这种统计很简单而且适用于大多数网站。但是不一定适用于其它一些比较复杂的应用。比如，你不能使用一个直连从网上银行获取一份概要报告；你首先得登录该应用然后再导航到特定的页面。出于这个目的，浏览器将

1.背景1.1.Linux 服务器情况# cat /etc/issueRed Hat Enterprise Linux Server release 6.1 (Santiago)Kernel \r on an \m1.2.Win7 客户端情况Win7 旗舰版 sp1，4G内存，双核 CPU 主频 3.0G。1.3.Oracle 服务器情况10.2.0，部署在上述 RedHat 上。2.AWR 报告

1.事故描述本月 8 日上午十点多，我们的基础应用发生生产事故。具体表象为系统出现假死无响应。查看事发时间段的基础应用 error 日志，没发现明显异常。查看基础应用业务日志，银行结果处理的部分普遍很慢，大都在十分钟以上。2.AWR 报告向 DBA 要了一下那个时间段的 AWR 报告，发现以下三个地方有些异常：2.1.CPU 利用率过高如上图所示，CPU利用率：1883.25分钟DB时间/(4核心

本文是《Linux 服务器运行健康状况监控利器 Spotlight on Unix 的安装与使用》的姊妹篇，Linux 的 Spotlight 监控请参考该篇博客。1.本文背景Oracle 版本：10g Enterprise Edition Release 10.2.0.5.0 - 64bit，部署于 Red Hat 服务器Windows：Win7 旗舰版 sp12.Spotlight on Or

本文是《JVM 性能调优实战之：一次系统性能瓶颈的寻找过程》 的后续篇，该篇介绍了如何使用 JDK 自身提供的工具进行 JVM 调优将 TPS 由 2.5 提升到 20 (提升了 7 倍)，并准确定位系统瓶颈：我们应用里静态对象不是太多、有大量的业务线程在频繁创建一些生命周期很长的临时对象，代码里有问题。那么问题来了，如何在海量业务代码里边准确定位这些性能代码？本文将介绍如何使用阿里开源工具 TP...

玩过性能优化的朋友都清楚，性能优化的关键并不在于怎么进行优化，而在于怎么找到当前系统的性能瓶颈。性能优化分为好几个层次，比如系统层次、算法层次、代码层次...JVM 的性能优化被认为是底层优化，门槛较高，精通这种技能的人比较少。笔者呆过几家技术力量不算弱的公司，每个公司内部真正能够进行 JVM 性能调优的人寥寥无几、甚至没有。如是乎，能够有效通过 JVM 调优提升系统性能的人往往被人们冠以"大牛"

1.背景1.1.Linux 服务器情况# cat /etc/issueRed Hat Enterprise Linux Server release 6.1 (Santiago)Kernel \r on an \mCPU 16 核、主频 2.6G，内存 32GB。1.2.Win7 客户端情况Win7 旗舰版 sp1，4G内存，双核 CPU 主频 3.0G。2.Spotlight 下载本文使用 Sp

在 http Load Testing 中，json 数据的提交是个让人头疼的问题。本文详细介绍如何进行 JMeter 的 json 测试提交，以及如何将其参数化。        Step 1 http json 请求采样器的录制        这个工具很多，可以使用 JMeter 代理录制，也可以使用 Badboy。该采样器录制好以后如下图所示：        Step 2 为该采样器添加 HT

问题描述        文件上传时，用户定义 Content-Disposition 是失效的。        笔者在写压力测试脚本的时候，有个上传页面，服务器是根据用户传过来的 Content-Disposition 里的 filename 值来定义保存文件的文件名的。但是测试人员不可能为每一次请求都准备一个不同的文件(这个工作量海了去了)，所以 JMeter 传给服务器的 Content-Di

有这样一个压力测试环境，有一个上传页面，上传成功之后服务器会返回一些上传信息(比如文件的 id 或者保存路径之类的信息)，然后压力机会继续下一个请求，比如调整 id 为 xx 的文件的一些信息等等。问题来了：JMeter 是不知道上传后文件的 id 的，第二个请求势必从第一个请求的返回结果中提取出文件 id，然后依此为参数发起第二次请求。那么 JMeter 如何把上一个请求的结果作为下一个请求的参数呢？本文将介绍如何使用正则提取器解决这个问题。

使用非 GUI 模式，即命令行模式运行 JMeter 测试脚本能够大大缩减所需要的系统资源。使用命令jmeter -n -t -l (比如 jmeter -n -t testplan.jmx -l listener.jtl)        我的第一次使用命令行执行测试脚本时，看到的输出如下：D:\Jmeter\bin>jmeter -n -t testplan.jmx -l listener.j

Badboy 录制好脚本以后，使用 JMeter 打开，直接运行测试，发现有个 Ajax 提交表单的时候出错了。服务器返回信息如下：HTTP Status 415 -type Status reportmessagedescription The server refused this request because the request entity is in a format not su

简介压力测试过程中，随时对负载服务器的健康状况的把控是相当重要的，有了这些数据，我们才能准确分析出压测瓶颈。如果你面对的是一个集群，如果能了解到负载是否被正确分发，是不是一件很漂亮的事情？为了达到这些目的，JMeter 插件包现在能够支持服务器监控啦！使用这个插件，你几乎可以在所有平台上监对 CPU、内存、Swap、磁盘 I/O、网络 I/O 进行监控！以下监控插件图演示了压力测试中的 4 台服务