0
为了方便监控 ES 的慢查询日志, 采用方案:flume+elasticsearch+kibana方式, 但是我们ES版本是6.*, 而Flume官方版本只兼容ES1.7… 所以需要自定义flume 对接ES的 Sink代码 Flume 原理&架构 flume是一个分布式、可靠、和高可用的海量日志采集、聚合和传输的系统。支持在日志系统中定制各类数据发送方，用于收集…
MQ 是很常见的分布式中间件，被测系统和测试工具中也经常用到它们，使用它们的时候要遇到很多概念： JMS，AMQP , Producer，consumer等等，它们之间是神马关系？ MQ的实现原理又是什么？ 性能指标有哪些？可以通过哪些配置参数提升传输性能？ MQ基础–协议 常见的MQ有 activemq, rabbitmq, rocketmq, kafka等，常用消息队列协议的基本原…
网络IO传输模式和编解码方案对系统的性能影响至关重要, 作为HTTP Server, 为什么Nginx 的网络IO性能很高, 而Tomcat 之类的Web Server 网络IO 性能相对较低 ? 系统选择的网络IO模型不同, Nginx使用的poll/epoll属于 多路复用型网络模型; Tomcat 6 之前的版本都是用的阻塞式IO模型 (6版本之后支持 NIO模式了,网络IO有所提升) , …
1.DB服务常见问题 1、慢SQL，查询语句不好，没有优化，如：没有索引或者没有用到索引等 2、I/O吞吐量小，形成了瓶颈效应。 3、内存不足 4、 网络速度慢 5、锁或者死锁(这也是查询慢最常见的问题，是程序设计的缺陷)sp_lock,sp_who,活动的用户查看,原因是读写竞争资源。 2. DB监控指标&工具： 资源层：和其他软件一样 业务层： …
1. 性能问题发现 1.1 用户体验 a. RT : 超时 b. TPS 率：达不到预期值 c. 错误率：比预期值高 以上数据来源为压测工具端的统计监控 1.2 被测端监控告警 资源层：系统 load 值、内存使用率、磁盘使用率、网络带宽等超过阈值 业务层：连接数满，full GC频率过高等 2.性能问题定位流程 3. Java 类问题定位常用工具&…
一般一个项目质量活动中，性能测试经常发现一些RT时间过长问题和DB服务有关，通常慢查询类问题比较多， 一般影响查询时间长短的主要是对DB索引的理解和使用问题，比如没有索引或者没有用到索引(这是查询慢最常见的问题，是程序设计的缺陷)，当然也有一些其他类型的原因，比如查询出的数据量过大（可以采用多次查询或其他的方法降低数据量），锁或者死锁(这也是查询慢最常见的问题，是程序设计的缺陷)sp_lock,s…
Flink也支持ML库，但不太成熟： flink 比spark 支持的ML算法少很多 flink中只有dataset 类型的数据才能使用ML，datastream类型数据没有专门的ML库； flink 中dateset 不能转换成dataframe结构…特征数据处理感觉不是很方便 flink dateset ML库中的算法类似乎没有提供模型评估方法 一个简单的线性回归算…
1.业务分析: 根据乘客的各维度特征预Titanic乘客生还概率 框架选择: 数据分析–pandas 机器学习–sklearn 2.数据分析: 导入数据分析维度和类型: df = pd.read_csv(‘D:/code/sparkProject/sparkInput/titanic-data.csv’) print(train_df.head()) 结果显示…