性能优化

Mysql性能优化 Sql 1、profiling 可以使用profiling命令查看sql语句执行的时间。 使用select @@profiling;查看开启状态。 mysql> select @@profiling; +-------------+ | @@profiling | +-------------+ | 0 | +-------------+ 1 row in set (0.36 sec) 默认为0，表示不开启。 使用set命令开启。 mysql> set profiling=1; Query OK, 0 rows affected (0.08 sec) mysql> select @@profiling; +-------------+ | @@profiling | +-------------+ | 1 | +-------------+ 1 row in set (0.16 sec) 使用几条select语句查询后，查看profiles的状态。 mysql> show profiles; +----------+------------+----------------------------------+ | Query_ID | Duration | Query | +----------+------------+-------------------

如果是自己写的代码，加上又熟悉业务场景，很容易就知道性能瓶颈点。但如果上来就去优化别人的代码，甚至是其他产品线的代码，还是有一些挑战的。最近就在做这事，接手了优化公司一个业务引擎接口的任务。优化方法做一些总结。 优化接口总共分两步，一是找到性能热点，二是解决热点。在不熟悉代码的情况下，找热点是最难的，找到后对症下药就容易多了。这里主要说一下如何找性能热点。 第一步，查调用链。 微服务下，调用链追踪能很容易的定位到是链路上的哪个环节出现问题。从而确定是别人接口把你的拖慢了，还是自己接口内代码有问题。且调用链反映的是线上真实数据，比跑线下测试数据更有说服力。 这里以A->B->C举例，简单说一下调用链常用的几个参数： TraceID：一个完整链路的唯一ID。本例中，TraceID是在A、B、C中传递的，ABC中记录的链路日志都用这个唯一的TraceID，不会变。 BindingID：一个线程内的ID。本例中，A记录的链路日志中，有唯一的BindingIDA，同样B、C中各有BindingIDB、BindingIDC ConversationID：一个会话的ID。本例中，A调用B，A生成一个ConversationID，传给B，B在返回结果前，记下日志，A在收到结果后记下日志。这两条日志有唯一的ConversationID。 VirtualPath：用于标识微服务路径 Component

TCP 属于OSI七层模型中的传输层协议，位于网络边缘，提供端到端的可靠数据传输，其有着承上启下的作用，协议数据单元为报文段（Message Segment)。 TCP需要提供以下功能： 分组和复用 应用报文的差错检测（包括出错、丢失、重复、失序、超时等） 提供端到端的流量控制 提供拥塞控制 运输连接建立与释放 连接控制 报文段序号 传输层为应用进程之间提供端到端的逻辑通信，之所以称为逻辑通信，是因为其看似为两端之间的水平传输，实际为垂直方向的封包和拆包过程。此概念上一节已提到。 文章来自（更详细的内容参照此链接）： https://github.com/laoqiren/web-performance/blob/master/%E5%B8%A6%E5%AE%BD%E4%B8%8E%E5%BB%B6%E8%BF%9F/TCP%E5%8D%8F%E8%AE%AE%E7%BB%86%E8%8A%82.md 来源： https://www.cnblogs.com/syw20170419/p/11953378.html

2019年开始，新东方APP团队启动了长达半年以上的稳定性建设工作，为什么稳定性如此重要？因为随着每年30%以上的高速增长，现有的后端服务完全扛不住日益增多的用户带来的高并发，高可用场景。所以优化工作势在必行。 如果你是一名java程序员的话，相信你也会很清楚，有时候，在研发功能的时候，仅仅是贴着产品的需求在做开发，功能是都实现了，但是没有考虑到功能在高并发下面是否可用，响应是否及时。这就给以后的线上运行留下很多隐患。 我们做稳定性建设的原因就是要解决这些隐患，提高系统稳定性，提高单台机器的QPS性能。加快接口响应速度，优化数据库的sql查询。 下面看一下优化后的效果图： 以上是单独一台服务器的吞吐率和响应时间曲线图，从图中可以看到，暑期吞吐率增长5倍，服务响应时间从最长的50多秒大幅度减少到0.4秒。优化效果明显。 以下从3方面阐述优化方法： 1、如何定位后端问题 2、如何解决数据库问题 3、如何分析和解决程序问题 一、定位后端问题的方法： kibana 。可以还原线上有问题的接口的参数列表（实时性比较好，统计多台服务器的日志，统一处理）。 听云 用听云监测慢事务，慢接口比较详细，能准确定位接口是sql慢，还是代码哪里慢。 二、数据库知识点和优化 1、2种存储引擎 在MySQL中，索引属于存储引擎级别的概念，不同存储引擎对索引的实现方式是不同的

转自： https://blog.csdn.net/qq_35624156/article/details/77455670 一、什么是lua&luaJit lua（www.lua.org）其实就是为了嵌入其它应用程序而开发的一个脚本语言， luajit（www.luajit.org）是lua的一个Just-In-Time也就是运行时编译器，也可以说是lua的一个高效版。 二、优势 1）lua是一个免费、小巧、简单、强大、高效、轻量级的嵌入式的脚本语言,lua当前的发行版本5.3.1只有276k。 2）它是用C语言开发的项目，所以可以在大部分的操作系统上运行 3）lua是目前速度最快的脚本语言，既可以提升语言的灵活性还可以最大限度的保留速度 4）其语法非常简单，没有特例 5）lua还可以作为C的API来使用 三、不足和不同 1）lua没有强大的库，所以很多功能实现起来没有python、perl、ruby等脚本语言简洁 2）lua的异常处理功能饱受争议，虽然其提供了pcall和xpcall的异常处理函数 3）lua原生语言中没有提供对unicode编码的支持，虽然可以通过一些折中的办法实现 http://www.cppblog.com/darkdestiny/archive/2009/04/25/81055.html 4）没有提供在C++中应用很广泛的a?b:c的三元运算符操作 5

前端性能优化可以分为两大类，分别是 页面级别优化：包含了http请求数以及内联脚本位置优化； 代码级别优化：包含DOM操作优化，CSS选择符优化以及图片优化等。 优化的目的 优化的目的在于让页面加载的更快，对用户操作响应更及时，为用户带来更好的用户体验，对于开发者来说优化能够减少页面请求数，能够节省资源。 页面级别优化 http请求数 减少http请求数是最重要也是最有效的方法，可以通过以下方法来减少http请求： 合理的设置http缓存，恰当的缓存设置可以大大减少http请求。要尽可能地让资源能够在缓存中待的更久； 从设计实现层面简化页面，保持页面简洁、减少资源的使用是最直接的 资源合并与压缩，尽可能的将外部的脚本、样式进行合并，多个合为一个 CSS Sprites，通过合并CSS图片，这是减少请求数的一个好办法 图片地图： 假设导航栏上有五幅图片，点击每张图片都会进入一个链接，这样五张导航的图片在加载时会产生5个HTTP请求。然而，使用一个图片地图可以提高效率，这样就只需要一个HTTP请求。 服务器端图片地图：将所有点击提交到同一个url，同时提交用户点击的 x，y坐标，服务器端根据坐标映射响应 客户端图片地图：直接将点击映射到操作 使用图片地图的缺点：指定坐标区域时，矩形或圆形比较容易指定，而其他形状手工指定比较难 CSS Sprites： 直译过来就是CSS精灵

对于一些数据量较大的系统，数据库面临的问题除了查询效率低下，还有就是数据入库时间长。特别像报表系统，每天花费在数据导入上的时间可能会长达几个小时或十几个小时之久。因此，优化数据库插入性能是很有意义的。 经过对MySQL innodb的一些性能测试，发现一些可以提高insert效率的方法，供大家参考参考。 1. 一条SQL语句插入多条数据。 常用的插入语句如： INSERT INTO `insert_table` (`datetime`, `uid`, `content`, `type`) VALUES ('0', 'userid_0', 'content_0', 0); INSERT INTO `insert_table` (`datetime`, `uid`, `content`, `type`) VALUES ('1', 'userid_1', 'content_1', 1); 修改成： INSERT INTO `insert_table` (`datetime`, `uid`, `content`, `type`) VALUES ('0', 'userid_0', 'content_0', 0), ('1', 'userid_1', 'content_1', 1); 修改后的插入操作能够提高程序的插入效率。这里第二种SQL执行效率高的主要原因是合并后日志量

对于一些数据量较大的系统，数据库面临的问题除了查询效率低下，还有就是数据入库时间长。特别像报表系统，可能每天花费在数据导入上的时间就会长达几个小时之久。因此，优化数据库插入性能是很有意义的。 网络上的牛人很多，总会有一些手段可以提高insert效率，大家跟我一起分享一下吧： 1. 一条SQL语句插入多条数据。 我们常用的插入语句大都是一条一个insert，如： INSERT INTO `insert_table` (`datetime`, `uid`, `content`, `type`) VALUES ('0', 'userid_0', 'content_0', 0); INSERT INTO `insert_table` (`datetime`, `uid`, `content`, `type`) VALUES ('1', 'userid_1', 'content_1', 1); 现在我们将它修改成： INSERT INTO `insert_table` (`datetime`, `uid`, `content`, `type`) VALUES ('0', 'userid_0', 'content_0', 0), ('1', 'userid_1', 'content_1', 1); 【数据对比】 下面是网上牛人提供一些测试对比数据

Go 使用 channel 实现 CSP 模型。处理双方仅关注通道和数据本身，无需理会对方身份和数量，以此实现结构性解耦。在各文宣中都有 “Don't communicate by sharing memory, share memory by communicating.” 这类说法。但这并非鼓励我们不分场合，教条地使用 channel。 在我看来，channel 多数时候适用于结构层面，而非单个区域的数据处理。原话中 “communicate” 本就表明一种 “message-passing”，而非 “lock-free”。所以，它并非用来取代 mutex，各自有不同的使用场景。 有关 channel 实现方式，可参考《Go 学习笔记》第五版，下卷《源码剖析》。 从实现角度看，channel 算是一种很 “重” 的实现。在小粒度层面，其性能真算不得好。我们可用一个常见示例测试一下：用 channel 实现并发安全的计数器，或序号生成器。 性能测试结果表明，差异远比想的要大得多。单就此例而言，还可以用原子操作（atomic）进一步优化。 如果说 channel 适用于结构层面解耦，那么 mutex 则适合保护语句级别的数据安全。至于 atomic，虽然也可实现 lock-free 结构，但处理起来要复杂得多（比如 ABA 等问题），也未必就比 mutex 快很多。还有，sync

原文: SqlServer性能优化，查看CPU、内存占用大的会话及SQL语句 1，查看CPU占用量最高的会话及SQL语句 select spid,cmd,cpu,physical_io,memusage, (select top 1 [text] from ::fn_get_sql(sql_handle)) sql_text from master..sysprocesses order by cpu desc,physical_io desc 2，查看缓存重用次数少，内存占用大的SQL语句 SELECT TOP 100 usecounts, objtype, p.size_in_bytes,[sql].[text] FROM sys.dm_exec_cached_plans p OUTER APPLY sys.dm_exec_sql_text (p.plan_handle) sql ORDER BY usecounts,p.size_in_bytes desc 来源： https://www.cnblogs.com/lonelyxmas/p/11939569.html