Benchmark

redis-benchmark benchmark]# redis-benchmark -h 127.0.0.1 -p 6382 -c 500 -n 200000 -n Total number of requests (default 100000) -c 500个并发连接， 其他参数请通过 redis-benchmark --help 以下是测试执行的结果 ====== PING_INLINE ====== 200000 requests completed in 2.43 seconds 500 parallel clients 3 bytes payload keep alive: 1 0.00% <= 1 milliseconds 0.01% <= 2 milliseconds 59.27% <= 3 milliseconds 96.02% <= 4 milliseconds 98.71% <= 5 milliseconds 99.21% <= 6 milliseconds 99.62% <= 7 milliseconds 99.83% <= 8 milliseconds 99.91% <= 9 milliseconds 99.98% <= 10 milliseconds 100.00% <= 10 milliseconds 82406.26 requests per

最近花很大的经历来做性能测试，把结果整理到了ppt中，可能有个别地方不准，但是可以看看一个趋势。 主要分为两部分，一部分是写入elasticsearch性能，一部分是查询测试，elasticsearch的查询性能。 当然在elasticsearch1.3.0之后elasticsearch会提供benchmark来评估服务器性能实用情况。 硬件配置 主机 cpu mem disk system 192.168.32.243 POWER7 4228MHz*12 24G swap:1G IBMsas 600G Red Hat Enterprise Linux Server 6.4 192.168.32.244 POWER7 4228MHz*8 16G swap:1G IBMsas 600G Red Hat Enterprise Linux Server 6.4 192.168.32.245 POWER7 4228MHz*8 16G swap:1G IBMsas 600G Red Hat Enterprise Linux Server 6.4 测试样本说明 入库测试（bulk）、查询测试 1个服务~3个服务 3、6、9分片 1备份 2.4亿条记录 8g内存 jmeter压力测试工具（2.11） 入库测试 POST http://192.168.32.245:9200/performance

Note: The blog post Apache Kafka Supports 200K Partitions Per Cluster contains important updates that have happened in Kafka as of version 2.0. This is a common question asked by many Kafka users. The goal of this post is to explain a few important determining factors and provide a few simple formulas. More Partitions Lead to Higher Throughput The first thing to understand is that a topic partition is the unit of parallelism in Kafka. On both the producer and the broker side, writes to different partitions can be done fully in parallel. So expensive operations such as compression can utilize

一、 引言 Mycat作为现在最流行的分布式数据库中间件，已经在很多的生产项目中实施，随着时间的推移会有更多的生产项目中会用到Mycat。 本文主要是介绍MyCat主要配置文件，以及笔者对这些配置的一些理解。 二、 前言 本文主要分析的有server.xml，schema.xml，rule.xml三个最常用的文件。 三、 Server.xml Server.xml保存了mycat需要的所有的系统配置信息，代码映射为SystemConfig类。 标签主要有四个： system,user,firewarll,cluster. 接下来对四个标签进行说明 1. user标签 内容： <user name="test"> 说明用户名是test。 子标签： property，privileges. 1) property标签 内容： <property name="password">test</property> 用户密码是test <property name="schemas">db1, db2</property> 可访问的schema有db1,db2 <property name="readOnly">true</property> 是否只读 <property name="benchmark">1000</property> 连接上限，降级权值。 <property name=

转这篇文章是因为其论述的测试用例重要性、以及设计用例的总体思想很好！ 一、前言    作为移动互联网产品『最后一公里的守护者』，我们必须要清楚的知道自己该做什么、怎么做。但从版本迭代速度、需求量级、测试人员不断变动等方面综合来看，我们很多人都没有做好充分的准备。测试方法落后、测试用例覆盖不全、测试效率低下，使得测试将要成为阻碍产品质量进一步提升的另一瓶颈。    因此，沉淀一下自己的工作心得，希望能帮助更多的人完善测试设计，提升自我测试能力。 二、提高测试用例质量    测试用例的存在，能对复杂需求的功能质量提升，以及自身测试效率的提升，起到非常基本的促进作用。因为测试用例本身就是通过对需求点的梳理，找出潜在的测试点，避免测试点的遗漏。    那么问题来了：为什么要强调提升测试用例质量呢？    测试用例设计能力的好坏，直接关系到各角色peer，尤其是开发人员对测试人员的印象的好坏。就如同测试人员去评价一位优秀的开发人员：代码规范、Bug少；思维严谨、效率高；沟通顺畅、责任心强…    同样的，开发人员去评价一名优秀的测试人员，也无非这几个方面：case覆盖全、漏测少；思维严谨、效率高；沟通顺畅、责任心强。    从这就可以看出，就像开发人员写不出好代码一样，测试人员测试用例设计的不好，其实是一件挺丢面儿的事。    此外，好的测试用例，对测试质量和测试效率，有着很大的影响

0x01 前言 今天听学长们交流漏洞挖掘的经验，提到了Limit注入，借此来学习一下limit注入 0x02 知识介绍 limit LIMIT[位置偏移量,]行数 其中，中括号里面的参数是可选参数，位置偏移量是指MySQL查询分析器要从哪一行开始显示，索引值从0开始，即第一条记录位置偏移量是0，第二条记录的位置偏移量是1,依此类推...，第二个参数为“行数”即指示返回的记录条数。 效果如图 自行理解 benchmark benchmark函数有两个参数，第一个是执行次数，第二个是要测试的函数或者表达式 比如 benchmark(10000000,sha1(1)) 意思是执行sha1函数10000000次 使mysql运算量增大 导致延时 有点类似与多表联合查询（笛卡尔积） 如图 大概执行10000000次会造成3秒以上的延时 0x03 limit注入 Example：select*from limittest limit 1,[可控点] or select ... limit [可控点] limit后面能够拼接的函数只有into和procedure，into可以用来写文件，本文我们不考虑。 在Limit后面 可以用 procedure analyse()这个子查询 而且只能用extractvalue 和 benchmark 函数进行延时 procedure analyse

测试机器 CPU: I3-7100 内存: 8G 操作系统:Win7_64 测试结果图 源码地址 https://github.com/Chris2018998/BeeCP/blob/master/doc/other/HikariCP-benchmark_SafeClose.zip Tag:BeeCP 来源： oschina 链接： https://my.oschina.net/u/3918073/blog/4365521

作者：李泽明，GrowingIO 解决方案顾问。 来源：GrowingIO 增长沙龙分享内容 大家好，我是李泽明，来自 GrowingIO，主要为客户提供增长咨询服务。 GrowingIO 将「数据驱动增长」方法论分为三步走： 第一步，采+看，即数据监控。也就是将用户行为数据以及业务数据采集过来，用可视化的图表呈现。 第二步，想，即数据分析。结合各类数据分析方法，对上面的数据进行分析、产出洞察。 第三步，做，即业务增长。基于商业目标进行业务决策、采取行动，驱动业务增长。 在我服务过的一百多家客户当中，我发现：很多企业在「数据监控」这一步做了很多探索和实践；但是他们更关注结果性数据，而中间的过程性数据往往被忽略了。所以，他们在实践和落地增长的过程中会遇到很多的问题，包括方法、执行甚至战略。 当我们的业务出现数据异常时，因为数据很多，往往会一遍遍的从这些数据中去寻找可以定位原因的相关指标，这不仅会浪费很多时间，还会使人心疲力竭。 大部分成长型公司缺少体系化的监控，每天看数据的有多少？在你的日常工作中需要监控多少个运营指标？ 解决上述问题的思路是给公司搭建一套基于业务的数据监控体系，数据监控环节离不开一个核心概念——指标。 「指标」是一种度量，它用于追踪和评估商业进程的状态，确保商务在正确的轨道上运营，同时验证方法论，不断地学习。 指标监控体系最大的价值就是帮助大家高效利用时间

从学界到工业界， “ 开源 ” 已经成为AI领域的一个关键词。一方面，它以 “ 授人以渔 ” 的方式为AI构建了一个开放共进的生态环境，帮助行业加速AI应用落地；另一方面，在解决行业实际问题时持续更新和迭代，源源不断地给AI领域输送重要的技术养料和创造力，可以说开源是AI落地和繁荣不可或缺的源动力。 6月1 0 日，腾讯优图实验室宣布正式开源新一代移动端深度学习推理框架 TNN ，通过底层技术优化实现在多个不同平台的轻量部署落地，性能优异、简单易用。基于TNN，开发者能够轻松将深度学习算法移植到手机端高效的执行，开发出人工智能 APP，真正将 AI 带到指尖。 轻量级部署，TNN助力深度学习提速增效 深度学习对算力的巨大需求一直制约着其更广泛的落地，尤其是在移动端，由于手机处理器性能弱、算力无法多机拓展、运算耗时长等因素常常导致发热和高功耗，直接影响到app等应用的用户体验。腾讯优图基于自身在深度学习方面的技术积累，并借鉴业内主流框架优点，推出了针对手机端的高性能、轻量级移动端推理框架TNN。 TNN在设计之初便将移动端高性能融入核心理念，对2017年开源的ncnn框架进行了重构升级。通过GPU深度调优、ARM SIMD深入汇编指令调优、低精度计算等技术手段，在性能上取得了进一步提升。以下是M NN, ncnn, TNN 框架在多款主流平台的实测性能： TNN 在麒麟9 70

比如有人想新增一个虚拟摄像头，当用户app打开摄像头设备时，打开的不是系统默认的camera hal代码，而是自己指定的代码，用自己事先准备好的视频数据，来喂给app；也有人想在系统默认的一套app框架上，新增一个外接的usbcamera，并且要能溶入到camera框架中。app只需要指定usbcamera的id，就能像打开普通摄像头那样，去打开我们的usbcamera；也有人，想在现有的框架上，同时兼容老的hal1+api1流程的android8.0之前的camera，又想新增一个符合android8.0的hidl接口规范的camera模块。 上面所有的需求，归纳起来，核心的就是一点，即如何去新增一个camera hal模块。我这篇博客，是以在mtk android8.0上新增一个usbcamera hal模块来讲的。当然，新增虚拟摄像头，流程跟这个也是一模一样的。 好了，既然是想在android8.0上新增一套符合hidl接口规范的camera流程，那么我们先要了解一下，android原生的hidl接口下的camera流程，下面我们先讲一讲这块。 在android8.0之前，frameworks层的cameraservice和hal层的camera代码是在同一个进程的，这样不利于hal层部份独立升级。针对这个问题，8.0后，就推出了hidl机制