TCPCopy是一种重放TCP流的工具，使用真实环境来测试互联网服务器上的应用程序。
tcpcopy是一种重放TCP流的工具，可使用真实环境的流量来测试互联网服务器上的应用程序。
tcpcopy实现新加的从库数据预热，这个功能还是比较实用的（booking的2018年DTCC大会上的分享中也提过他们做了这个功能）。尤其是高负载的从库，如果直接加入一台冷的从节点到集群，可能造成大量慢查询出现。
一、工具介绍 Tcpcopy是一个分布式在线压力测试工具，可以将线上流量拷贝到测试机器，实时的模拟线上环境，达到在程序不上线的情况下实时承担线上流量的效果，尽早发现bug，增加上线信心。 Tcpcopy是由网易技术部于2011年9月开源的一个项目，现在已经更新到0.4版本。 与传统的压力测试工具（如：abench）相比，tcpcopy的最大优势在于其实时及真实性，除了少量的丢包，完全拷贝线上流量到测试机器，真实的模拟线上流量的变化规律。 二、Tcpcopy的原理 1．流程 现在以nginx作为前端说明tcp
tcpcopy 是一个分布式在线压力测试工具，可以将线上流量拷贝到测试机器，实时的模拟线上环境，达到在程序不上线的情况下实时承担线上流量的效果，尽早发现 bug，增加上线信心。
作者博客：http://blog.csdn.net/wangbin579/article/details/8950282
TCPCOPY 是一个 tcp 流量的实时复制工具，其1.0版本由网易工程师 @tcpcopy 开发和维护。一般用来将生产环境的线上流量实时复制到测试环境进行测试。例如新系统上线前，如果我们希望进行一些基本的压力测试，那么我们可以直接利用 tcpcopy 来复制线上的流量过来对系统进行测试，这样的好处是测试数据接近真实水平，且实施起来相对简单。
TCPCopy是用来做TCP重放的，常用的场景是把线上流量复制到测试环境，用来排查线下不容易重现的问题，或者对测试环境做压力测试。（HTTPS不能进行压力测试，由于数据加密）
tcpcopy是一个tcp流量复制工具，当前还支持udp和mysql流量的复制。 目的： 将机器10.24.110.21的5000端口流量引流到机器10.23.25.11的5000端口。 示例：将10.24.110.21:4077引流到10.23.25.11:5000 1) 线上机器：10.24.110.21 tcpcopy -x 4077-10.23.25.11:5000 -s 10.23.25.12 -c 192.168.100.x -n 1 2) 测试机器：10.23.25.11 route add -net 192.168.100.0 netmask 255.255.255.0 gw 10.23.25.12 192.168.100/24为虚拟的IP，tcpcopy使用它来连接测试机。 3) 辅助机器：10.23.25.12 intercept -i eth1 -F tcp and src port 5000 测试机器和辅助机器需要在同一网段，否则添加不了路由。 如何需要将多台线上的机器引渡到同一台测试机上了？ 关键点：需要不同的辅助端口 假设引流两台线上机到一台测试机10.23.25.11:5000 在辅助机器上启动两个不同端口的intercept进程（-p参数默认值为36524）： intercept -p 36524 -i eth1 -F tcp and src port 5000 intercept -p 36525 -i eth1 -F tcp and src port 5000 同时，测试机上需要添加两条到辅助机的路由： route add -net 192.168.100.0 netmask 255.255.255.0 gw 10.23.25.12 route add -net 192.168.110.0 netmask 255.255.255.0 gw 10.23.25.12 两台线上机上分别启动tcpcopy引流（需要指定不同的协助机端口）： tcpcopy -x 4077-10.23.25.11:5000 -c 192.168.100.x -n 1 -s 10.23.25.12 -f 1 -p 36524 tcpcopy -x 4077-10.23.25.11:5000 -c 192.168.110.x -n 1 -s 10.23.25.12 -f 6 -p 36525
An online request replication tool, also a tcp stream replay tool, fit for real testing, performance testing, stability testing, stress testing, load testing, smoke testing, etc
近日，一个进行了大半年的大型项目重构接近尾声。这种重构无异于飞机在天上直接换引擎。慢慢进行灰度是必然的。但是灰度之前，有更好的方式提前发现问题，那就是流量复制，使用线上真实的流量对即将上线的应用进行测试。
本篇背景是另外一同事朋友，最近在利用流量回放技术应用在服务端接口自动化测试方面，还在各部门全力推进阶段，未来效果暂且不好说，但这部分内容确实各大公司，测试技术大会等等的热词，由于我没参与但我很感兴趣，所以邀请普及一篇，后边应该还会带来实战篇，本公众号坚持原创和干货分享，欢迎长期关注，一同成长，如果你有好的实战分享也欢迎投稿。
网易 NetEase https://github.com/netease 1.分布式TCP压力测试工具 tcpcopy tcpcopy是一种应用请求复制（基于tcp的packets）工具，其应用领域较广，目前已经应用于国内各大互联网公司。 总体说来，tcpcopy主要有如下功能： 1）分布式压力测试工具，利用在线数据，可以测试系统能够承受的压力大小（远比ab压力测试工具真实地多）,也可以提前发现一些bug 2）普通上线测试，可以发现新系统是否稳定，提前发现上线过程中会出现的诸多问题，让开发者有信心上线 3
机房T和机房Y共十台前端机，Y机房请求量是T的两倍，主要用于数据查询，开始问题是Y机房tomcat 相继僵死 1） tomcat僵死处理步骤 a 检查代码，发现read through后，没有把DB数据写到缓存，增加回写代码；但单台机器每秒请求也就几十条，HBase压力很小，最终发现无效。 b 检查代码，认为跟运行几个月的动态代码在HBase使用上完全一致，所以认为业务代码层没有问题；打印堆栈信息，认为是HBase client端发现资源等待死锁的问题 c 下载0.94.2 patch，分析认为其解决了死锁
很多年以前，网易推了一个tcp流量复制工具叫tcpcopy。2013年07月我入职新公司，大概10月份接触到tcpcopy，为tcpcopy修了两个bug，一个是由于公司内网的IP tunnel的问题tcpcopy无法正常工作；另一个是一个严重的性能bug。两个bug都用邮件方式向原作者反馈了，尤其第二个bug原作者在博客上发文感谢。在接下来的二次开发中，由于没办法看懂tcpcopy的tcp会话部分的代码，当时建议作者按照tcp的11个状态写成状态机，作者拒绝了。于是，我根据当时的业务情况重写了一个新的TCPCOPY叫TCPGO。技术原理和tcpcopy是一样的，但tcp会话部分写成了标准 的11个tcp状态的状态机（见源代码中的tcpsession类，漂亮的运行在应用空间而不是内核态的精简的tcp状态机）。另部署方式很不一样，要简单很多。为了开发效率，开发语言用了C++，用了boost库还加了lua帮助写业务代码。
之前组内一位大佬分享了一些关于系统性能优化方面的干货，这里我将它整理成文并且加入自己平时常用的一些工具和技巧。由于关于系统性能优化涉及的内容非常多，我会分几篇文章来分享。这次分享下定位系统层面问题的常用方法。
基于实际的生产业务场景、系统环境，模拟海量的用户请求和数据对整个业务链进行压力测试，并持续调优的过程
大家所熟悉的性能测试工具有Loadrunner、JMeter，以及其他小众一些的工具，如Locust、Ngrinder、Gatling等等，那么你们知道这些工具有什么不同吗？为什么有的工具能模拟数千上几万的并发，有的工具单机只能模拟一两千的并发，这其中的原因是什么呢？那么这节课我就来告诉大家，你所不了解性能测试工具的一面：并发模式。
能力管理(Capacity Management)应该是ITIL里面一个非常重要的概念，有些人叫容量管理，但我还是觉得能力管理更好一些，能力直接的理解就是我们能做什么？还有多少能力冗余？让我们来看看ITIL的概念解释，指在成本和业务需求的双重约束下，通过配置合理的服务能力使组织的IT资源发挥最大效能的服务管理流程，ITIL给到的流程图如下：
本文由曾鋆、海智、亚辉、孟莹四位作者共同创作完成。 背景介绍 随着海量请求、节假日峰值流量和与日俱增的系统复杂度出现的，很有可能是各种故障。在分析以往案例时我们发现，如果预案充分，即使出现故障，也能及时应对。它能最大程度降低故障的平均恢复时间（MTTR），进而让系统可用程度（SLA）维持在相对较高的水平，将故障损失保持在可控范围内。但是，经过对2016全年酒店后台研发组所有面向C端系统的线上事故分析后发现，在许多情况下，由于事故处理预案的缺失或者预案本身的不可靠，以及开发人员故障处理经验的缺失，造成大家在
操作系统：Centos,※,Ubuntu,Redhat※,,suse,Freebsd
伴随着网站业务发展，需求日趋复杂多样并随时变化。传统静态化方案会遇到业务瓶颈，不能满足瞬变的需求。因此，需要一种能高性能实时渲染的动态化模板技术来解决这些问题。本文和大家分享一下最近一年做的京东商品详情页的架构升级的心路历程。
-t 100 http://www.isTester.com/zhichang/177.html
当我们把DNS服务器配置好后，我们肯定会想测试一下DNS服务器的性能如何，上线后如果请求数够多服务器还能否响应？于是，我们可以使用软件模拟环境，对DNS服务器作评估性的测试。在bind中，有一款自带的压力测试软件，queryperf。使用这款软件可以对DNS服务器作请求测试，并且使用方法简单，我们可以使用queryperf测试多次，取一个平均值，这样就算结果不准确，也不会和实际情况相差太大。
最近的工作一直在与服务端性能优化打交道，QPS（每秒查询率）的苛刻要求让我这个以前也就用 node.js 写写博客的人深刻地感觉到以前做的东西就是个玩具。所以最近也在尝试了解一些压测方面的知识。对于压测工具，业界常用的有 jmeter、loadrunner、tcpcopy、apache bench、wrk(2) 等。作为压测小白，结合项目实际情况（无需硬件监控、测试请求较简单），在这里选择了上手使用 wrk2。本文记录了使用过程中的一些心得体会。
我们在测试接口的时候。为了便于测试，可能希望线上的请求能够同步到测试一部分，以便于验证某些功能，或者是在多套测试环境的情况下，希望能够将某些请求在几个环境同步，比如在1环境测试的时候生成了某个图片或者视频，这个生成依赖于一个请求的回调，而如果没有特别配置，则这个请求就只在当前环境中生效，这对测试工作有相当大的不便。于是，我们需要引入流量复制这一概念。
之前介绍了Nginx的两种开源waf，Naxsi和ModSecurity，有人担心直接上生产会不会有问题，拦截正常请求，我想说——那是必然会影响的
系统写好了，能不能顺利上线？一般来说我们需要做一些压力测试来判断。比如系统预计每天一百万的接口访问量，并且访问时段主要集中在早八点到晚八点，那么平均下来 RPS 大约是 22 次左右，不过用户的访问量通常不会很平均，假设峰值流量是平均流量的 3 到 5 倍的话，那么我们可以推断出项目要想顺利上线，RPS 至少应该达到 66+ 次，110+ 次更好。由此可见上线前用压力测试工具测试 RPS 是一个很重要的环节。
在深入测试工作的那段时间，笔者发现测试人员因为工作边界模糊，大部分时间和精力都花在了功能测试上，而对于质量测试、自动化测试等扩展性强的工作，所花时间和精力很少，这是一件可悲的事情，但这是很多公司内都存在的现象。导致这种现象的原因有很多，其中一个让人特别头疼的问题就是自动化测试的覆盖速度远远达不到产品变化的速度，所以很多人失去了信心，选择老老实实地做功能测试。
本周六很荣幸参加了快狗打车的闭门交流会，能和关注已久的沈剑老师面基感觉特别荣幸。我想在介绍交流会内容的同时，谈谈自己的思考。
木桶理论又称短板理论，其核心思想是一只木桶盛水多少，并不取决于最高的木板，而取决于最短的那块木板。
在传输过程中，RPC并不会把请求参数的所有二进制数据整体一下子发送到对端机器上，中间可能会拆分成多个数据包，也有可能合并成其他请求的数据包。RPC协议就是为了"正确进行装包和拆包"而生的，比如使用长度限制或者标识设定边界。
前几天在技术交流群，大家又讨论起了流量录制回放的话题。我观察了一下，讨论的人不少，大体有这两种观点：第一种观点认为，流量录制回放的应用前景很广阔，能大幅度提高测试效率和技术逼格，都想在自己团队落地，但需要一些最佳实践参考；第二种观点则认为只有大厂才能做这个实践，小公司就别想了。
前些天，一堆人在 TCPCopy 社区里闲扯蛋，有人提了一个问题：FIN_WAIT1 能持续多久？引发了一场讨论，期间我得到斌哥和多位朋友的点化，受益良多。
没有那家卖瓜的会说自己家的不甜，同样，没有哪个开源项目愿意告诉你在对它条件最苛刻的时候压力情况是多少，一般官网号称给你看的性能指标都是在最理想环境下的，毫无参考意义。
在发布或重启某线上某服务时（jetty8作为服务器），常常发现有些机器的load会飙到非常高（高达70），并持续较长一段时间（5分钟）后回落（图1），与此同时响应时间曲线（图2）也与load曲线一致。注：load飙高的初始时刻是应用服务端口打开，流量打入时（load具体指什么可参考http://www.cnblogs.com/amsun/p/3155246.html）。
公有云，私有云（OpenStack/cloudstack + KVM/XEN，oVirt), 混合云 服务监控 配置管理
在国内，APM很火，一部分是受资本市场的推动，另外一部分是它给人感觉找到了核心痛点，解决了IT中的大麻烦。可我觉得需要冷静的看，APM就是你的IT能力的一面镜子，特别是服务端代码级APM。
随着微服务架构的兴起，服务之间的依赖关系变的越来越复杂，软件测试也面临新的挑战：系统升级频繁、服务依赖众多等等。
你想通过执行ping google.com来判断网络连通性么？我想你这是在侮辱方教授。本篇是《荒岛余生》系列第五篇，网络篇，但不会教你fq。其余参见：
本文章来自我的微信个人技术公众号---网络技术修炼，公众号中总结普及网络基础知识，包括基础原理、网络方案、开发经验和问题定位案例等，欢迎关注。
日常大部分的测试工作都是在测试环境下，通过模拟用户的行为来对系统进行验证，包括功能以及性能。在这个过程中，你可能会遇到以下问题:
有些 BUG 是业务逻辑上的错误导致的，一般不会导致程序崩溃，例如：原本要将两个数相加，但不小心把这两个数相减，而导致结果出错。这时我们可以通过在程序中，使用 printf 这类输出函数来进行打点调试。
AutoMeter 是一款针对分布式服务，微服务 API 做功能和性能一体化的自动化测试平台，一站式提供发布单元，API，环境，用例，前置条件，场景，计划，报告等管理
导语：运维可以说是世界上最紧张且强度最大的工作之一，每个杂乱无章的问题背后都需要我们的深入的抽丝剥茧。尤其是当你面对的问题直接与收入业务、海量服务运营挂钩时，可谓是肾上腺素瞬间飙升。压力的存在可能诱发
排查出问题并找到根本原因加以解决，个人认为是一件很成就感的事情。曾经有人问过我：“你是怎么想到问题出现在xxx的？又是怎么确认根本原因是xxx的？”，我只能轻描淡写的回答：“靠经验”，然后感觉这个逼装得还可以。其实这里说的“靠经验”是很模糊的，一直以来大家可能都觉得排查问题要靠经验，但是又说不出具体通过什么样的经验排查出了问题，最后让排查问题逐渐变成了一门玄学。其实问题排查工作往往遵循一些通用且不成文的实践规则，并不是一门所谓的玄说，结合自身经历、总结，希望能为大家的实际工作带来助益。
由于nio的普及，ck10k的问题已经成为过去式。现在随便一台服务器，就可以支持数十万级别的连接了。那么我们来算一下，100万的连接需要多少资源。
生产环境下， 我们一般使用 esrally来做es的基准测试。 但是毕竟和真实生产的请求场景可能有差异的。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
即时通信 IM
实时音视频
