最近公司开始考核企业站下所有站点，首先从itpub开始进行。为此，开始学习关于如何 优化一个网站使之提高访问速度这方面的知识。得知page speed 是个不错的工具，就下载下来了。介绍下这个工具吧，Page Speed 是开源 Firefox/Firebug 插件。网站管理员和网络开发人员可以使用 Page Speed 来评估他们网页的性能，并获得有关如何改进性能的建议。对网站的网络服务器配置和前端代码执行若干测试。这些测试基于一组已知可增强网页性能的最佳实践。在网页上运行 Page Speed 的网站管理员会获得一组针对各网页的分数，以及有关如何改善网页性能的有用建议。它会使你的网站更快速，减少带宽成本。

下面以我们的itpub站点为列简要说下：

1 首先你得安装这个插件，具体怎么按，略过；

2 安装后，按F12出现下图

3 点击上图花圈的 出现下图：

这个82/100是你这个站按照page speed的考核获得分数

自己决定还是不错的。

黄色的表示 警告 可以进一步优化的

绿色的表示做的不错

红色的表示做的不行需要优化了

（itpub没有红色的 这点做的还是不错的）

4 看下“启用keep-alive” 关于keep-alive 我会在我的另外一篇博文中着重写下。待续

说明it168.com这台主机需要启用keep-alive，可是这是其他项目组的主机，我这边无权修改。所以，在这说下，以后非自己管辖的主机，就直接pass了不管。

5 说下下面的压缩JavaScript

pagespeed给你的建议是 进行压缩以下的2个js。你点击后面的op…它会给你生成个压缩后的js。然后你可以替换原先的js即可。这地方只说明怎么做。当然了JQuery也有min版的压缩后的js。

6 上CDN

其实做了这些 还有个更重要的方面，如果你的公司没钱的话，可以按照上面的来做。如果公司有钱，可以加动态CDN

明后天开始给ITPUB上动态CDN，同时对图片 附件 分离出来用单独的域名。目前首页首屏时间为3.156s

希望在上完CDN后网速会得到很大的提高！！！

===============================================================================================

这里说下关于性能优化技巧方面一些认识，也是网上传的沸沸扬扬的“军规”：

1 启用gzip。

gzip压缩是一种开发的压缩算法，目前的主流浏览器(Firefox, Safari, Chrome, IE4及以上)与主流服务器(Apache, Lighttpd, Nginx)均对其有很好的支持。gzip压缩是通过HTTP 1.1协议中的Content-Encoding : gzip来进行标记说明，其可以明显减少文本文件的大小，从而节省带宽和加载时间。我做过的一个实验，发现启用gzip后，JQuery 1.2.6 minify版本的大小从54.4k减少到16k，减少了70%。gzip适用的情况包括：

HTML\CSS\JavaScript文 件，gzip算法对于文本文件的效率比较高，而jpg/gif/png/pdf等二进制文件本身已经进行了一次压缩，再使用gzip的成效已经不明显了。 而且gzip压缩需要消耗服务器的资源，而解压缩需要消耗浏览器的资源，对于比较大的二进制文件具有非常高的性能消耗；
尽量使用一种大小写方式，要么全部大写，要么全部小写。学过数据结构和算法的同学一定知道压缩其本身就是对冗余信息熵进行压缩，如何数据原素的类型种类太多，其信息冗余度会降低，从而压缩率降低；
过小的文件(通常小于150个字节)不宜进行gzip压缩，因为gzip会在文件头加入相关信息，对于小文件反而会增加文件的长度；

（以上文字摘自http://www.yakecan.com/archives/3 我表示认同）

那么怎么看你的服务器是否开启了呢？

以我这边的一台服务器为例说明下，我的web服务器是nginx的，就以nginx说下：

打开nginx的配置文件，你会看到相关的gzip的设置，如果没有的话，请你们公司的运维同事设置启用即可。

types 是使用哪些类型的文件使用到gzip。

你可以用站长工具查看你的站点是否使用gzip了，如使用http://tool.chinaz.com/Gzips/可以查看

以我的一个站点为例，

大家可以看到这个结果就知道了。

 2 最小化JS和图片

你可以用一个压缩工具压缩即可。对 于JavaScript文件本身具有非常大的优化空间。所谓JavaScript压缩，就是通过一些工具将函数、变量名进行优化(其实就是尽可能缩短变量 名长度)，消除多余字符(比如空格、换行符、注释等)，最终得到的代码可以在分析和执行上得到性能提升。压缩后得到的代码对于机器而言是可读的，对于人来 说就不行了，因为文件内容已经面目全非。所以压缩一般用于生产期的代码，不能使用于开发期。

3 JavaScript最小化

比如JQuery.form.js，最小化后减少11.9kb，减少54.8%的空间。点击minified version，在新窗口中可以看到Page Speed为你优化好的版本，直接更新到服务器就可以了。

4 启用浏览器缓存

这是经常使用的方法。当请求的资源在浏览器本地得到缓存后，第二次请求这些内容就可以从直接缓存中取出，减少了连线的HTTP请求。

5 JavaScript延迟加载

   通常浏览器在解析HTML时遇到JS文件会先下载，解析执行后才会下载后面的内容，期间自然会造成一定的延时。为了提高性能，尽可能将JS文件的位置后 移，如果可能，还可以通过部分代码进行异步加载。另外，对于JS和CSS在必须放置在一起情况，需要报JS放置在CSS之后，这样CSS与JS文件可以同 步下载。

6 文件拼接，就是可以合并的文件，就合并成一个文件

7 减少HTTP请求。这个是同上面的几个一起使用的。

8 只加载head里的部分js。其他的可以放到底部加载。

9 压缩HTML代码。

有个不错的方法就是压缩HTML，压缩html 其实就是：清除换行符,清除制表符,去掉注释标记  。它所起到的作用不可小视。

现提供PHP 压缩HTML函数。请大家不妨试试看。

完

简介

对于写出实现功能的SQL语句和既能实现功能又能保证性能的SQL语句的差别是巨大的。很多时候开发人员仅仅是把精力放在实现所需的功能上，而忽略了其所 写代码的性能和对SQL Server实例所产生的影响(也就是IO,CPU,内存方面的消耗).这甚至有可能使整个SQL Server实例跪了。本文旨在提供一些简单的步骤来帮助你优化SQL语句。

市面上已经有很多关于如何优化SQL Server性能的书籍和白皮书。所以本文并不打算达到那种深度和广度，而仅仅是为开发人员提供一个快速检测的列表来找到SQL语句中导致瓶颈产生的部分。

在开始解决性能问题之前，合适的诊断工具是必须的。除去众所周知的SSMS和SQL Profiler,SQL Server 2008还带有众多DMV来提供关键信息。本篇文章中，我将使用SSMS和一些DMV来找到SQL的瓶颈

那么，我们从哪开始

我的第一步是查看执行计划。这一步既可以通过SMSS也可以通过SQL Profiler实现，为了简便起见，我将在SMSS中获取执行计划。

1) 检查你是否忽略掉了某些表的连接的条件,从而导致了笛卡尔积（Cross)连接(Join)。比如，在生产系统中有两个表，每个表中有1000行数据。这 其中绝大多数数据并不需要返回，如果你在这两个表上应用了Cross Join,返回的结果将会是100万行的结果集!返回如此数量的数据包括将所有数据从物理存储介质中读取出来，因而占用了IO。然后这些数据将会被导入内 存，也就是SQL Server的缓冲区。这会将缓冲区内的其它页Flush出去。

2)查看你是否忽略了某些Where子句，缺少Where子句会导致返回额外不需要的行。这产生的影响和步骤一所产生的影响是一样的。

3)查看统计信息是否是自动创建和自动更新的，你可以在数据库的属性里看到这些选项

在默认条件下创建一个新数据库，Auto Create Statistics和Auto Update Statistics选项是开启的，统计信息是用于帮助查询优化器生成最佳执行计划的。这份白皮书对于解释统计信息的重要性以及对于执行计划的作用解释的非常到位。上面那些设置可以通过右键数据库，选择属性，在“选项”中找到。

4)检查统计信息是否已经过期，虽然统计信息是自动创建的，但是更新统计信息从而反映出数据的变化也同样重要。在一个大表中，有时候虽然Auto Update Statistics 选项已经开始，但统计信息依然无法反映出数据的分布情况。默认情况下，统计信息的更新是基于抽取表中的随机信息作为样本产生的。如果数据是按顺序存储的， 那么很有可能数据样本并没有反映出表中的数据情况。因此，推荐在频繁更新的表中，统计信息使用Full Scan选项来定期更新。这种更新可以放到数据库闲时来做。

DBCC SHOW_STATISTICS命令可以用于查看上次统计信息的更新时间，行数以及样本行数.在这个例子中，我们可以看到Person.Address表上的AK_Address_rowguid索引的有关信息:

USE AdventureWorks;
GO
DBCC SHOW_STATISTICS ("Person.Address", AK_Address_rowguid);
GO

下面是输出结果，请注意Updated,Rows,Rows Sampled这三个列

如果你认为统计信息已经过期，则可以使用sp_updatestats这个存储过程来更新当前数据库中的所有统计信息:

Exec sp_updatestats

或者使用FULLSCAN选项，则关于表Person.Address上的所有统计信息将会被更新:

UPDATE STATISTICS Person.Address WITH FULLSCAN

5)查看执行计划是否出现任何表或者索引的扫描（译者注：不是查找),在大多数情况下（这里假设统计信息是最新的),这意味着索引的缺失。下面几个DMV对于查找缺失索引很有帮助:

i) sys.dm_db_missing_index_details

ii) sys.dm_db_missing_index_group_stats

iii) sys.dm_db_missing_index_groups

接下来的几个语句使用了上面的DMV，按照索引缺失对于性能的影响，展现出信息:

SELECT avg_total_user_cost,avg_user_impact,user_seeks, user_scans,
ID.equality_columns,ID.inequality_columns,ID.included_columns,ID.statement 
FROM sys.dm_db_missing_index_group_stats GS
LEFT OUTER JOIN sys.dm_db_missing_index_groups IG On (IG.index_group_handle = GS.group_handle)
LEFT OUTER JOIN sys.dm_db_missing_index_details ID On (ID.index_handle = IG.index_handle)
ORDER BY avg_total_user_cost * avg_user_impact * (user_seeks + user_scans)DESC

你也可以使用数据引擎优化顾问来找出缺失的索引以及需要创建哪些索引来提高性能。

6)查看是否有书签查找,同样，在执行计划中找到书签查找十分容易,书签查找并不能完全避免，但是使用覆盖索引可以大大减少书签查找。

7)查看排序操作，如果在执行计划中排序操作占去了很大一部分百分比，我会考虑以下几种方案:

•      按照所排序的列创建聚集索引，但这种方式一直存在争议。因为最佳实践是使用唯一列或者Int类型的列作为主键，然后让SQL Server在主键上创建聚集索引。但是在特定情况下使用排序列创建聚集索引也是可以的
•     创建一个索引视图，在索引视图上按照排序列创建聚集索引
•     创建一个排序列的非聚集索引，把其他需要返回的列INCLUDE进去

在我的另一篇文章中，我将会详细阐述选择最佳方案的方法。

8)查看加在表上的锁，如果所查的表由于一个DML语句导致上锁，则查询引擎需要花一些时间等待锁的释放。下面是一些解决锁问题的方法:

•     让事务尽可能的短
•     查看数据库隔离等级，降低隔离等级以增加并发
•     在Select语句中使用表提示，比如READUNCOMMITTED 或 READPAST.虽然这两个表提示都会增加并发，但是ReadUnCommited可能会带来脏读的问题,而READPAST会只返回部分结果集

9)查看是否有索引碎片，索引碎片可以使用sys.dm_db_index_physical_statsDMV轻松查看，如果索引碎片已经大于30%,则推荐索引重建.而索引碎片小于30%时，推荐使用索引整理。索引碎片因为使查询需要读取更多的列从而增加了IO,而更多的页意味着占用更多的缓冲区，因此还会形成内存压力。

如下语句根据索引碎片的百分比查看所有索引:

Declare @db	SysName;
Set @db = '<DB NAME>';

SELECT CAST(OBJECT_NAME(S.Object_ID, DB_ID(@db)) AS VARCHAR(20)) AS 'Table Name',
 CAST(index_type_desc AS VARCHAR(20)) AS 'Index Type',
 I.Name As 'Index Name',
 avg_fragmentation_in_percent As 'Avg % Fragmentation',
 record_count As 'RecordCount',
 page_count As 'Pages Allocated',
 avg_page_space_used_in_percent As 'Avg % Page Space Used'
FROM sys.dm_db_index_physical_stats (DB_ID(@db),NULL,NULL,NULL,'DETAILED' ) S
LEFT OUTER JOIN sys.indexes I On (I.Object_ID = S.Object_ID and I.Index_ID = S.Index_ID)
AND S.INDEX_ID > 0
ORDER BY avg_fragmentation_in_percent DESC

下面语句可以重建指定表的所有索引:

ALTER INDEX ALL ON <Table Name> REBUILD;

下面语句可以重建指定索引:

ALTER INDEX <Index Name> ON <Table Name> REBUILD;

当然，我们也可以整理索引，下面语句整理指定表上的所有索引:

ALTER INDEX ALL ON <Table Name> REORGANIZE;

下面语句指定特定的索引进行整理:

ALTER INDEX <Index Name> ON <Table Name> REORGANIZE;

在重建或整理完索引之后，重新运行上面的语句来查看索引碎片的情况。

总结

上面的9个步骤并不是优化一个SQL语句必须的，尽管如此，你还是需要尽快找到是哪个步骤导致查询性能的瓶颈从而解决性能问题。就像文中开篇所说，性能的 问题往往是由于更深层次的原因,比如CPU或内存压力，IO的瓶颈(这个列表会很长….),因此，更多的研究和阅读是解决性能问题所必须的。

—————————————-

原文链接:http://www.sqlservercentral.com/articles/Performance+Tuning/70647/

一、聚合函数：

SQLite中支持的聚合函数在很多其他的关系型数据库中也同样支持，因此我们这里将只是给出每个聚集函数的简要说明，而不在给出更多的示例了。这里还需要进一步说明的是，对于所有聚合函数而言，distinct关键字可以作为函数参数字段的前置属性，以便在进行计算时忽略到所有重复的字段值，如count(distinct x)。

二、核心函数：

以下函数均为SQLite缺省提供的内置函数，其声明和描述见如下列表：

三、日期和时间函数：

SQLite主要支持以下四种与日期和时间相关的函数，如：
    1). date(timestring, modifier, modifier, …)
    2). time(timestring, modifier, modifier, …)
    3). datetime(timestring, modifier, modifier, …)
    4). strftime(format, timestring, modifier, modifier, …)
以上所有四个函数都接受一个时间字符串作为参数，其后再跟有0个或多个修改符。其中strftime()函数还接受一个格式字符串作为其第一个参数。 strftime()和C运行时库中的同名函数完全相同。至于其他三个函数，date函数的缺省格式为：”YYYY-MM-DD”，time函数的缺省格 式为：”HH:MM:SS”，datetime函数的缺省格式为：”YYYY-MM-DD HH:MM:SS”。
1. strftime函数的格式信息：

需要额外指出的是，其余三个时间函数均可用strftime来表示，如：
date(…)         strftime(‘%Y-%m-%d’, …)
time(…)         strftime(‘%H:%M:%S’, …)
datetime(…)   strftime(‘%Y-%m-%d %H:%M:%S’, …)

2. 时间字符串的格式：
见如下列表：
    1). YYYY-MM-DD
    2). YYYY-MM-DD HH:MM
    3). YYYY-MM-DD HH:MM:SS
    4). YYYY-MM-DD HH:MM:SS.SSS
    5). HH:MM
    6). HH:MM:SS
    7). HH:MM:SS.SSS
    8). now
5)到7)中只是包含了时间部分，SQLite将假设日期为2000-01-01。8)表示当前时间。

   3. 修改符：
见如下列表：
    1). NNN days
    2). NNN hours
    3). NNN minutes
    4). NNN.NNNN seconds
    5). NNN months
    6). NNN years
    7). start of month
    8). start of year
    9). start of day
    10).weekday N   
1)到6)将只是简单的加减指定数量的日期或时间值，如果NNN的值为负数，则减，否则加。7)到9)则将时间串中的指定日期部分设置到当前月、年或日的开始。10)则将日期前进到下一个星期N，其中星期日为0。注：修改符的顺序极为重要，SQLite将会按照从左到右的顺序依次执行修改符。

4. 示例：
    –返回当前日期。
    sqlite> SELECT date(‘now’);  
    2012-01-15    
    –返回当前月的最后一天。
    sqlite> SELECT date(‘now’,’start of month’,’1 month’,’-1 day’);
    2012-01-31
    –返回从1970-01-01 00:00:00到当前时间所流经的秒数。
    sqlite> SELECT strftime(‘%s’,’now’);
    1326641166    
    –返回当前年中10月份的第一个星期二是日期。
    sqlite> SELECT date(‘now’,’start of year’,’+9 months’,’weekday 2′);
    2012-10-02  

为了帮助理解，我决定先上传一个工程截图，这个是我做的一个小作业，3、4个小时完成，没什么含金量，就是交差用的，这里给大家做个模板吧。   我把一个工程分6个部分来一一说好了。 1. 这里就是存放我们写的类的，由于我这个简单，就没有分很多包了，一个包搞定一切。 2. 这个是编译生成的，千万不要乱动它，会导致很可怕的错误，另外，如果明明写的很对，但是就是编译通不过的话，一定是这个东西除了问题，可以上网搜搜解决办法，不知道能不能删了这个文件重新编译。 3. 这个三个文件夹是用来放图片的，比如自己做的按钮啊什么的，分高(hdpi)中(mdpi)低(ldpi)三种像素图片文件夹，在不同屏幕下调用不同像素的图片。 4. 看名字就知道，这是些UI的地方，这里写好了以后，在java文件里调用。 5. 这个是存放一些字符串的，比如有些字符串常用到啊，多处被引用的话，就给它取个名字放到这里，然后就可以实现字符串共享了。 6. 就是上一篇介绍过的，声明activity和权限的地方。   所以，综上所述，一个Android程序被运行的时候，程序先在manifest文件里找到入口类，然后进入入口类的onCreate()函数开始执行，其中UI在layout文件夹中调用，图片在res文件夹中调用。

接下来我们进入代码，用代码稍微分析一下，就清楚了：

首先，我们看到在manifest文件里申明了入口类是SecretDiaryActivity.java：

<activity android:name=".SecretDiaryActivity"
 android:label="@string/app_name">
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />
                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
        </activity>

接着我们进入到SecretDiaryActivity.java文件，找到onCreate()函数：

@Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.diary_list);
        mDbHelper = new DiaryDbAdapter(this);   
        ll=(LinearLayout)findViewById(R.id.bg);   //part one
        mDbHelper.open();
    // code=(EditText)
 //取回所有库中的日记显示
 // if(currentbg)
        
        if(mDbHelper.isCode()){
            Intent i = new Intent(this, EnterPage.class);
            startActivityForResult(i, ACTIVITY_ENTER);
        }
        int bg=mDbHelper.getbg();
        Resources resources = getBaseContext().getResources();
        Drawable btnDrawable=resources.getDrawable(R.drawable.bg);
        switch(bg){
        case 0:
            break;
        case 1:
            btnDrawable=resources.getDrawable(R.drawable.bg2);
            break;
        case 2:
            btnDrawable=resources.getDrawable(R.drawable.bg3);
            break;            
        }
        
        ll.setBackgroundDrawable(btnDrawable);
         renderListView();  //part two
    }

可以看到，setContentView(R.layout.diary_list);这一句，就是定义了这个activity的layout调用的是哪个xml文件。

顺带看一下，标注了part one的这一句，就是用来申明一个UI的，根据ID来查找布局，这个时候我们就需要找到名字叫做bg的一个LinearLayout，这个时候用到的就是 上面的第二部分，gen文件夹下的R.java文件，编译器从这里找到bg的物理地址，我们看到bg的定义其实在diary_list.xml文件中：

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
 android:layout_width="fill_parent"
 android:layout_height="fill_parent"
 android:id="@+id/bg" 
 >"

    <ListView android:id="@+id/android:list"
 android:layout_width="wrap_content"
 android:layout_height="wrap_content"
 />"
    <TextView android:id="@+id/android:empty"
 android:layout_width="wrap_content"
 android:layout_height="wrap_content" 

 android:text="还没有开始写日记哦亲!\n点击Menu按钮开始写日记吧:)"
 android:layout_margin="20px"
 android:textSize="17px"
 android:textStyle="bold"
 android:textColor="#000"
 />
</LinearLayout>

文件第五行进行了对一个layout布局的id定义，这里任何一个控件，布局，都可以给它一个id，以方便在java文件中调用并操作它，利用ID找到它之后，我们就可以通过ll来操作它了，比如这里我用ll给bg设置了一个背景。
这就是一个Android软件的大致架构了，知道了运作流程，可以很方便的知道什么时候该在哪里写东西了，接下来如何去做具体的功能还是要查看官方的guide了~。