优化

由于项目中自主研发的一个Android平台工具库需要提供给外部人员使用，我们决定使用android sdk自带的proguard tool混淆源码。在动用了google之后得到的大量资源文中，拨云见雾、去糟存精，融会贯通理论于实践，自我成长之余制作以下proguard源码混淆独家宝典。 无耻的分割线---------------------------------------------------------------------------------------------------------------------- 本文是以项目中进行混淆的步骤以及其间遇到的问题为主线，行文略乱，洁癖er轻拍。 1. proguard工具身藏Android sdk何处: android-sdks/tools/proguard/ 推荐使用lib文件夹下的proguard.jar，从命令行启动该工具“java -jar .../lib/proguard.jar @混淆配置文件” 对代码进行混淆；图形界面proguardgui.jar在win下启动正常，ubuntu11.10启动失败( 没空追踪失败原因，放弃之， 读者若有兴趣可自行研究） 2. 上一条中的“混淆配置文件”是个神奇的好东东，在混淆的道路上起着举足轻重综合协调承前启后的作用，不好意思，我墨迹了，我只是想强调它的重要性

操作符优化 IN 操作符 　　用IN写出来的SQL的优点是比较容易写及清晰易懂，这比较适合现代软件开发的风格。 　　但是用IN的SQL性能总是比较低的，从ORACLE执行的步骤来分析用IN的SQL与不用IN的SQL有以下区别： 　　ORACLE试图将其转换成多个表的连接，如果转换不成功则先执行IN里面的子查询，再查询外层的表记录，如果转换成功则直接采用多个表的连接方式查询。由此可见用IN的SQL至少多了一个转换的过程。一般的SQL都可以转换成功，但对于含有分组统计等方面的SQL就不能转换了。 　　推荐方案：在业务密集的SQL当中尽量不采用IN操作符。 　　 NOT IN操作符 　　此操作是强列推荐不使用的，因为它不能应用表的索引。 　　推荐方案：用NOT EXISTS 或（外连接+判断为空）方案代替 　　<> 操作符（不等于） 　　不等于操作符是永远不会用到索引的，因此对它的处理只会产生全表扫描。 　　推荐方案：用其它相同功能的操作运算代替，如 　　a<>0 改为 a>0 or a<0 　　a<>’’ 改为 a>’’ 　　IS NULL 或IS NOT NULL操作（判断字段是否为空） 　　判断字段是否为空一般是不会应用索引的，因为B树索引是不索引空值的。 　　推荐方案： 　　用其它相同功能的操作运算代替，如 　　a is not null 改为 a>0 或a>’’等。 　

生产环境最佳实践 1.linux 系统： 1】关闭文件系统/分区的atime 选项 Vi /etc/fstab 在对应的分区项后面添加noatime ,nodiratime LABEL=/1 / ext3 defaults 1 1 LABEL=/data1 /data ext4 defaults,noatime,nodiratime 1 2 2】设置文件句柄4k+，目前该配置已经集成到启动脚本中。 Vi /etc/security/limit.conf * soft nproc 65536 * hard nproc 65536 * soft nofile 65536 * hard nofile 65536 3】不要使用large vm page （不要使用大内存页选项） Linux 大内存页参考：http://linuxgazette.net/155/krishnakumar.html 4】用dmesg 查看主机的信息。 2.linux 文件系统的选择： Mongodb 采用预分配的大文件来存储数据,我们推荐 1】ext4 2】xfs 3.内核版本： 网络上对2.6.33-31 以及2.6.32 的表现持怀疑度， 而强力推荐2.6.36 4.线程堆栈的尺寸 默认的线程堆栈尺寸为10m ，调整为1m ，已经集成在启动脚本中。 项目过程中的总结与建议 1.大小写问题 mongodb

转自 https://blog.csdn.net/weibo1230123/article/details/81984805 volatile是用于编译器的优化，对硬件上的memory order无用！ 1、 编译器优化 介绍： 由于内存访问速度远不及CPU处理速度 ，为提高机器整体性能，在硬件上引入硬件高速缓存Cache，加速对内存的访问。另外在现代CPU中指令的执行并不一定严格按照顺序执行，没有相关性的指令可以乱序执行，以充分利用CPU的指令流水线，提高执行速度。以上是硬件级别的优化。再看软件一级的优化：一种是在编写代码时由程序员优化，另一种是由编译器进行优化。 编译器优化常用的方法有：将内存变量缓存到寄存器；调整指令顺序充分利用CPU指令流水线，常见的是重新排序读写指令。 对常规内存进行优化的时候，这些优化是透明的，而且效率很好。由编译器优化或者硬件重新排序引起的问题的解决办法是在从硬件（或者其他处理器）的角度看必须以特定顺序执行的操作之间设置内存屏障（memory barrier），Linux 提供了一个宏解决编译器的执行顺序问题。 void Barrier(void) 这个函数通知编译器插入一个内存屏障， 但对硬件无效 ，编译后的代码会把当前CPU寄存器中的所有修改过的数值存入内存，需要这些数据的时候再重新从内存中读出。 2、volatile总是与优化有关，

关键词优化作为网站优化最重要的一项，如何做好网站关键词优化是每一个专业SEO需要了解熟悉的问题，并且是每天必须做的功课之一。接下来VictronSEO小编就来讲讲 CMS企业建站系统 ​网站高指数的关键词该如何优化? 1、首页优化目标关键词 对于实践SEO的人来说，做这个相对容易一些，知识点也很明确，需要考虑的问题也少。无非是优化标题，关键词标签，描述标签等，以及首页的各个版块的标题，图片alt，关键词密度等等，还就是内链和外链，这些都做足了，只需等待时间收获就OK了。 2、栏目页、内容页优化指数在1000以下的关键词 这个就相对难一点了，因为首页只有一个，而栏目页却有很多个，涉及的词多了，网页多了，需要考虑的问题也就多了。关键词的分配：包括关键词在各个栏目间的分配，在内容页上的分配。有时候还要斟酌这个词是用栏目页来做好，还是用内容页来做好，等等。还有文件名的命名：一旦命名了以后就不能轻易修改，否则权重就没了。而首页的优化就不牵扯这个问题。 url的目录深度：比如是在一级目录下做还是在二级目录下做......等等。还有就是一些各个栏目页共有的版块，比如“网站公告，会员登录，最新文章”等，当出现在所有的栏目时，其实对SEO是一种干扰，但有时又不能去除。 3、用栏目页和内容页优化高指数的关键词 由于CMS程序的限制，一般全站的内容页就一个模板。而假如你的网站涉及很多不同层面的关键词

转自：http://obmem.info/?p=717 本来我一直不知道怎么来更好地优化网页的性能，然后最近做python和php同类网页渲染速度比较时，意外地发现一个很简单很白痴但是我一直没发现的好方法（不得不BS我自己）：直接像某些php应用比如Discuz论坛那样，在生成的网页中打印出“本页面生成时间多少多少秒”，然后在不停地访问网页测试时，很直观地就能发现什么操作会导致瓶颈，怎样来解决瓶颈了。 于是我发现 SimpleCD 在生成首页时，意外地竟然需要0.2秒左右，真真不能忍：对比Discuz论坛首页平均生成才0.02秒，而Discuz论坛的首页页面无疑比SimpleCD的主页要复杂不少；这让我情何以堪啊，因为这必然不是Python语言导致的差距，只能说是我完全没做优化而Discuz程序优化得很好的后果。 优化分析 其实不用分析也能知道肯定是数据库在拖累，SimpleCD在生成首页时需要在sqlite的三个数据库中进行42多次查询，是历史原因导致的极其低效的一个设计；但是这40多次查询中，其实大部分是非常快的查询，仔细分析一下就有两个是性能大户，其他都不慢。 第一个大户就是：获取数据个数 SELECT count(*) FROM verycd 这个操作每次都要花不少时间，这是因为每次数据库都要锁住然后遍历一遍主键统计个数的缘故，数据量越大耗时就越大，耗时为O(N)

常用优化要点 nginx使用的是固定数量的workers, 每个worker都处理进入的请求。最佳实践是每个CPU内核配置一个worker. 如何知道您的系统有几个CPU？ $ grep ^processor /proc/cpuinfo | wc -l 对于一个四核处理器，配置文件类似： # One worker per CPU-core. worker_processes 4; events { worker_connections 8096; multi_accept on; use epoll; } worker_rlimit_nofile 40000; http { sendfile on; tcp_nopush on; tcp_nodelay on; keepalive_timeout 15; # Your content here .. } 这里我们提高了 worker_connections 设置，定义了每个worker进程能处理多少连接。 服务器的最大连接数量是： worker_processes * worker_connections (= 32384 本例中) 这里启用了 multi_accept，该配置项使 nginx能尽快接收尽可能多的请求，减少客户端的连接初始化时间。 最后，本例中使用了 epoll 的事件模型，这也是最佳实践建议。 压缩 很多用户会启用

一、SEO简介 SEO(Search Engine Optimization) 搜索引擎优化 在了解搜索引擎自然排名机制的基础上，对网站进行内部及外部的调整优化，改进网站在搜索引擎中的关键词自然排名，获得更多流量，从而达成网站销售及品牌建设的预期目标，总而言之SEO就是为了获取流量，提高网站排名。 有搜索引擎就有搜索引擎的排名，也就产生了SEO 什么是TDK？ TDK就是网站的 标题（Title） 、 描述（Description） 和 关键词（Keyword） 二、SEO的重要性 （一）、资讯网站做SEO 做SEO为了提升网站的整体排名，网站通过不断地更新内容以及优质的合作外链来提升排名，从而提升网站自身的知名度，提升权重后发布的咨讯内容获得高排名，从而获得高流量，赚取广告费。 （二）、社区网站做SEO 社区做网站SEO是为了提升用户数量让更多的人用户可以一起互动，实现用户自我互动，用户真正活跃起来，网站排名自然而然就会上升。 （三）、企业网站做SEO 企业做SEO（搜索引擎优化）是为了提升知名度；企业做SEM（搜索引擎营销）是为了增加业务量。目的是为了长期稳定在某个位置自然排名。支出少，支出选择作为业务关键词来稳固市场地位，从而获得更多业务。 三、SEO的特点 （一）、SEO优点 1、 价格较低 ：搜索引擎优化只需要对网站进行维护，相比价格竞争而言搜索引擎优化的成本就低得多

一、 数据库访问优化的五个法则 在实际开发，我们主要是需要对SQL语句进行优化， 我们需要快速定位能性的瓶颈点，也就是说快速找到我们 SQL 主要的开销在哪里？根据木桶原理可以知道，最慢的设备往往是性能瓶颈。例如：互联网运用中的带宽，本地数据复制时的硬盘的访问速度。 根据当前计算机硬件的基本性能指标及其在数据库中主要操作内容，可以整理出如下五条性能基本优化法则： （1） 减少数据访问（减少磁盘访问） （2） 返回更少数据（减少网络传输或磁盘访问） （3）减少交互次数（减少网络传输） （4） 减少服务器 CPU 开销（减少 CPU 及内存开销） （5） 利用更多资源（增加资源） 由于每一层优化法则都是解决其对应硬件的性能问题，所以带来的性能提升比例也不一样。传统数据库系统设计是也是尽可能对低速设备提供优化方法，因此针对低速设备问题的可优化手段也更多，优化成本也更低。我们任何一个 SQL 的性能优化都应该按这个规则由上到下来诊断问题并提出解决方案，而不应该首先想到的是增加资源解决问题。 以下是每个优化法则层级对应优化效果及成本经验参考： 优化法则 性能提升效果 优化成本 减少数据访问 1~1000 低 返回更少数据 1~100 低 减少交互次数 1~20 低 减少服务器 CPU 开销 1~5 低 利用更多资源 @~10 高 二、 数据库访问优化法则详解 2.1、减少数据访问 （1

作者：MingCong Han 在《 十分钟成为 Contributor 系列 | 为 Cascades Planner 添加优化规则 》中，我们简单介绍了 Cascades 的相关背景知识，本文将为大家深入介绍 TiDB 新的优化器——Cascades Planner 的框架及原理。 TiDB 当前优化器简介 关系型数据库中查询优化器的作用是为一个 SQL 在合理的开销内产生一个合适的查询计划， TiDB 源码阅读系列文章（六）Select 语句概览 中介绍过 TiDB 当前优化器的基本组成，TiDB 当前的优化器将优化过程主要分为逻辑优化（Logical Optimize）和物理优化（Physical Optimize）两个阶段。逻辑优化是将一棵逻辑算子树（LogicalPlan Tree）进行逻辑等价的变化，最后的结果是一棵更优的逻辑算子树；而物理优化则是将一棵逻辑算子树转换成一棵物理算子树（PhysicalPlan Tree）。这棵物理算子树就是我们说的物理执行计划，将交由 TiDB 执行引擎去完成后续的 SQL 执行过程。 逻辑优化 TiDB 中，一个 SQL 在进入到逻辑优化阶段之前，它的 AST（抽象语法树）已经转换成了对应的逻辑算子树，因此逻辑优化就是将一个逻辑算子树进行逻辑上等价变换的过程。逻辑优化是基于规则的优化（Rule-Based Optimization