性能优化

昨天分别在外网和无外网环境下安装PostgreSQL，有外网环境下安装的相当顺利。但是在无外网环境下就是两个不同的概念了，可谓十有八折。感兴趣的同学可以搭建一下。 PostgreSQL安装完成后第一件事便是做相关测试，然后调整参数。 /*CPU 查看CPU型号*/ cat /proc/cpuinfo | grep name | cut -f2 -d: | uniq -c /*查看物理CPU个数*/ cat /proc/cpuinfo | grep "physical id" | sort -u | wc -l /*查看逻辑CPU个数*/ cat /proc/cpuinfo | grep "processor" | wc -l /*查看CPU内核数*/ cat /proc/cpuinfo | grep "cpu cores" | uniq /*查看单个物理CPU封装的逻辑CPU数量*/ cat /proc/cpuinfo | grep "siblings" | uniq /*计算是否开启超线程 ##逻辑CPU > 物理CPU x CPU核数 #开启超线程 ##逻辑CPU = 物理CPU x CPU核数 #没有开启超线程或不支持超线程*/ /*查看是否超线程,如果cpu cores数量和siblings数量一致，则没有启用超线程，否则超线程被启用。*/ cat /proc

图片压缩 npm install --save-dev image-webpack-loader vue.config.js 配置 对打包的css js文件进行压缩（服务器需要配置） npm install --save-dev compression-webpack-pluginvue.config.js配置： const CompressionWebpackPlugin = require('compression-webpack-plugin'); Nginx配置如下： gzip on;gzip_types text/plain application/javascript application/x-javascript text/css application/xml text/javascript application/x-httpd-php image/jpeg image/gif image/png; 配置成功如下： 来源： https://www.cnblogs.com/sww-blog/p/11846831.html

优化目标 减少 IO 次数 IO永远是数据库最容易瓶颈的地方，这是由数据库的职责所决定的，大部分数据库操作中超过90%的时间都是 IO 操作所占用的，减少 IO 次数是 SQL 优化中需要第一优先考虑，当然，也是收效最明显的优化手段。 降低 CPU 计算 除了 IO 瓶颈之外，SQL优化中需要考虑的就是 CPU 运算量的优化了。order by, group by,distinct … 都是消耗 CPU 的大户（这些操作基本上都是 CPU 处理内存中的数据比较运算）。当我们的 IO 优化做到一定阶段之后，降低 CPU 计算也就成为了我们 SQL 优化的重要目标 优化方法 改变 SQL 执行计划 明确了优化目标之后，我们需要确定达到我们目标的方法。对于 SQL 语句来说，达到上述2个目标的方法其实只有一个，那就是改变 SQL 的执行计划，让他尽量“少走弯路”，尽量通过各种“捷径”来找到我们需要的数据，以达到 “减少 IO 次数” 和 “降低 CPU 计算” 的目标 常见误区 count(1)和count(primary_key) 优于 count(*) 很多人为了统计记录条数，就使用 count(1) 和 count(primary_key) 而不是 count(*) ，他们认为这样性能更好，其实这是一个误区。对于有些场景，这样做可能性能会更差，应为数据库对 count(*)

概述 Lint是Google提供的Android静态代码检查工具，可以扫描并发现代码中潜在的问题，提醒开发人员及早修正，提高代码质量。除了Android原生提供的几百个Lint规则，还可以开发自定义Lint规则以满足实际需要。 为什么要使用Lint 在美团外卖Android App的迭代过程中，线上问题频繁发生。开发时很容易写出一些问题代码，例如Serializable的使用：实现了Serializable接口的类，如果其成员变量引用的对象没有实现Serializable接口，序列化时就会Crash。我们对一些常见问题的原因和解决方法做分析总结，并在开发人员组内或跟测试人员一起分享交流，帮助相关人员主动避免这些问题。 为了进一步减少问题发生，我们逐步完善了一些规范，包括制定代码规范，加强代码Review，完善测试流程等。但这些措施仍然存在各种不足，包括代码规范难以实施，沟通成本高，特别是开发人员变动频繁导致反复沟通等，因此其效果有限，相似问题仍然不时发生。另一方面，越来越多的总结、规范文档，对于组内新人也产生了不小的学习压力。 有没有办法从技术角度减少或减轻上述问题呢？ 我们调研发现，静态代码检查是一个很好的思路。静态代码检查框架有很多种，例如FindBugs、PMD、Coverity，主要用于检查Java源文件或class文件；再例如Checkstyle，主要关注代码风格

背景     之前做的海量数据数据展示，在预处理速度和在线渲染上还有有所欠缺，本文中进行一些优化工作,使得九分钟处理完一千多万面数据的3-12级矢量切片，在线浏览数据请求时间控制在10s左右。 准备     软件环境:PostGIS(3.0.0rc2 r17909)和 PostgreSQL( 12.0, compiled by Visual C++ build 1914, 64-bit)，数据是微软开源的部分房屋数据public.california20191107(10988317条)。 预处理     预处理就是将3级到12级的矢量切片事先切好。首先获取数据12级的最大最小xyz，通过这个范围生成网格，然后和数据相交得到一一对应的网格表public.ca_xyz 。 --经度转切片x CREATE OR REPLACE FUNCTION lon2tile(lon DOUBLE PRECISION, zoom INTEGER) RETURNS INTEGER AS $BODY$ SELECT FLOOR( (lon + 180) / 360 * (1 << zoom) )::INTEGER; $BODY$ LANGUAGE SQL IMMUTABLE; --纬度转切片y CREATE OR REPLACE FUNCTION lat2tile(lat double

1. 取数原理 设计器拼出最终的SQL，将SQL语句传给数据库，数据库执行，将数据返回给设计器。 由于计算过程首先要通过SQL语句从数据库中取数据，我们可以通过控制数据量的大小和对数据的提前预处理来提高报表的性能。下面是一些优化的方法。 2. 优化SQL FineReport报表的数据集采用的是表模型，也就是说通过SQL这种DSL语言，从数据库通过简单查询或各种组合关联查询得到一个关系表，而这部分SQL查询根据各种数据库产商长时间的优化(比如建立索引)，已经非常成熟。数据集一般要通过FineReport报表模型的复杂处理才能生成最终的表样。因此，从数据库SQL查询取出数据量越少，FineReport报表模型需要做的复杂处理和计算就越少，所花的时间和内存就少，从而可以提高性能。 2.1 SQL语句取具体的字段 我们一般会用select * from 这样的形式将一个数据库表中所有的字段都取出来，而其中一些字段是报表中不需要用到的，例如报表中只需要用到三个字段，但是数据库中实际的表有十个字段，一些初学者习惯性的用select * from table1，这样相当于把十个字段的数据都取到报表服务器端，增加了报表服务器端的内存占用以及减慢了运算速度，所以SQL语句中尽量不要用“*”号，而是写上具体的字段，能够减少报表服务器端的内存占用，加快报表的运算速度。 2.2

　　在应用系统开发初期，由于开发数据库数据比较少，对于查询sql语句，复杂试图的编写等体会不出sql语句各种写法的性能优劣，但是如果将应用系统提交实际应用后，随着数据库中数据的增加，系统的响应速度就成为目前系统需要解决的最主要问题之一。系统优化中一个很重要的方面就是sql语句的优化。对于海量数据，劣质sql语句和优质sql语句之间的速度差别可以达到上百倍，可见对于一个系统不是简单地能实现其功能就行，而是要写出高质量的sql语句，提高系统的可用性。 　　Oracle的sql调优第一个复杂的主题，甚至需要长篇概论来介绍OracleSQL调优的细微差别。不过有一些基本的规则是每个OracleDBA都需要遵从的，这些规则可以改善他们系统的性能。 　　sql调优的目标是简单的：消除不必要的大表全表搜索。不必要的全表搜索导致大量不必要的磁盘I/O，从而拖慢整个数据库的性能，对于不必要的全表搜索来说，最常见的调优方法是增加索引，可以在表中加入标准的B树索引，也可以加入位图索引和基于函数的索引。要决定是否消除一个全表搜索，你可以仔细检查索引搜索的I/O开销和全表搜索的开销，它们的开销和数据块的读取和可能的并行执行有关，并将两者作对比。 　　另外，在全表搜索是一个最快的访问方法时，将小表的全表搜索放到缓存（内存）中，也是一个非常明智的选择。我们会发现现在诞生了很多基于内存的数据库管理系统

引子 互联网有一项著名的8秒原则。用户在访问Web网页时，如果时间超过8秒就会感到不耐烦，如果加载需要太长时间，他们就会放弃访问 。大部分用户希望网页能在2秒之内就完成加载。事实上，加载时间每多1秒，你就会流失7%的用户。8秒并不是准确的8秒钟，只是向网站开发者表明了加载时间的重要性。那我们如何优化页面性能，提高页面加载速度呢？这是本文主要要探讨的问题，然而性能优化是个综合性问题，没有标准答案，想要面面俱到罗列出来，并非易事。本文只关注一些核心要点，以下是我总结性能优化常见的办法： 一、资源压缩与合并 主要包括这些方面： html压缩、css 压缩、js的压缩和混乱和文件合并 。 资源压缩可以从文件中去掉多余的字符，比如回车、空格。你在编辑器中写代码的时候，会使用缩进和注释，这些方法无疑会让你的代码简洁而且易读，但它们也会在文档中添加多余的字节。 1.html压缩 html代码压缩就是压缩这些在文本文件中有意义，但是在HTML中不显示的字符，包括空格，制表符，换行符等，还有一些其他意义的字符，如HTML注释也可以被压缩。 如何进行html压缩： 使用在线网站进行压缩(开发过程中一般不用) nodejs 提供了html-minifier工具 后端模板引擎渲染压缩 2.css代码压缩： css代码压缩简单来说就是无效代码删除和css语义合并 如何进行css压缩： 使用在线网站进行压缩

关键字: hibernate 本文依照HIBERNATE帮助文档，一些网络书籍及项目经验整理而成，只提供要点和思路，具体做法可以留言探讨，或是找一些更详细更有针对性的资料。 初用HIBERNATE的人也许都遇到过性能问题，实现同一功能，用HIBERNATE与用JDBC性能相差十几倍很正常，如果不及早调整，很可能影响整个项目的进度。 大体上，对于HIBERNATE性能调优的主要考虑点如下: ? 数据库设计调整 ? HQL优化 ? API的正确使用(如根据不同的业务类型选用不同的集合及查询API) ? 主配置参数(日志，查询缓存，fetch_size, batch_size等) ? 映射文件优化(ID生成策略，二级缓存，延迟加载，关联优化) ? 一级缓存的管理 ? 针对二级缓存，还有许多特有的策略 ? 事务控制策略。 1、 数据库设计 a) 降低关联的复杂性 b) 尽量不使用联合主键 c) ID的生成机制，不同的数据库所提供的机制并不完全一样 d) 适当的冗余数据，不过分追求高范式 2、 HQL优化 HQL如果抛开它同HIBERNATE本身一些缓存机制的关联，HQL的优化技巧同普通的SQL优化技巧一样，可以很容易在网上找到一些经验之谈。 3、 主配置 a) 查询缓存，同下面讲的缓存不太一样，它是针对HQL语句的缓存，即完全一样的语句再次执行时可以利用缓存数据。但是

Hibernate性能优化4( 转) 在处理大数据量时，会有大量的数据缓冲保存在 Session 的一级缓存中，这缓存大太时会严重显示性能，所以在使用 Hibernate 处理大数据量的，可以使用 session.clear() 或者 session. Evict(Object) 在处理过程中，清除全部的缓存或者清除某个对象。 2) 对大数据量查询时，慎用 list() 或者 iterator() 返回查询结果， 1. 使用 List() 返回结果时， Hibernate 会所有查询结果初始化为持久化对象，结果集较大时，会占用很多的处理时间。 2. 而使用 iterator() 返回结果时，在每次调用 iterator.next() 返回对象并使用对象时， Hibernate 才调用查询将对应的对象初始化，对于大数据量时，每调用一次查询都会花费较多的时间。当结果集较大，但是含有较大量相同的数据，或者结果集不是全部都会使 用时，使用 iterator() 才有优势。 3. 对于大数据量，使用 qry.scroll() 可以得到较好的处理速度以及性能。而且直接对结果集向前向后滚动。 3) 对于关联操作， Hibernate 虽然可以表达复杂的数据关系，但请慎用，使数据关系较为简单时会得到较好的效率，特别是较深层次的关联时，性能会很差。 4) 对含有关联的 PO （持久化对象）时，若