DNS Prefetch，即DNS预获取，是前端优化的一部分。一般来说，在前端优化中与 DNS 有关的有两点： 一个是减少DNS的请求次数，另一个就是进行DNS预获取 。

DNS 作为互联网的基础协议，其解析的速度似乎很容易被网站优化人员忽视。现在大多数新浏览器已经针对DNS解析进行了优化，典型的一次DNS解析需要耗费 20-120 毫秒，减少DNS解析时间和次数是个很好的优化方式。DNS Prefetching 是让具有此属性的域名不需要用户点击链接就在后台解析，而域名解析和内容载入是串行的网络操作，所以这个方式能 减少用户的等待时间，提升用户体验 。

默认情况下浏览器会对页面中和当前域名（正在浏览网页的域名）不在同一个域的域名进行预获取，并且缓存结果，这就是隐式的 DNS Prefetch。如果想对页面中没有出现的域进行预获取，那么就要使用显示的 DNS Prefetch 了。 继续阅读 →

在项目迭代的过程中，不可避免需要”上线“。上线对应着部署，或者重新部署；部署对应着修改；修改则意味着风险。

目前有很多用于部署的技术，有的简单，有的复杂；有的得停机，有的不需要停机即可完成部署。本文笔者简单讨论一下目前比较流行的几种部署方案，或者说策略。如有不足之处请指出，如有谬误，请指正^_^。 继续阅读 →

目前市面上很多移动端加速产品。但是都是基于sdk这种，然后劫持请求回边缘CDN节点。做链路加速，这种产品在一定程度并不能加速你的移动app。
我们的最佳实践是抛弃dns请求，全部使用ip，然后通过高速链路、高质量的BGP节点进行数据获取。在移动端，如果你放一个http://www.sklinux.com/1.jpg的请求，那么移动端会首先请求www.sklinux.com的dns解析。

然而，在移动网络非常复杂的今天，dns劫持是非常正常的事情。再加之dns解析时间太长，体验很慢也在情理之中。
然而市面上也有这种加速解析的方案，比如httpdns。但是httpdns，虽然加快了dns的解析，但是不是真正的走的去域名化道路。
所以，我们抛弃了域名。拥抱回归了ip的直接请求方式。比如：http://ip/1.jpg 那么问题来了，多个业务域名需要单ip路由
我们需要在nginx进行上进行业务区分，然后路由回源。这样就可以了，目前这种方案可以支持http、https。网络连通性效果非常的不错
希望做移动端app的研发、运维人员可以考虑。这种方案的连通性可以提升移动端的用户体验，移动端性能提升90%左右。
效果非常好！在这里分享给大家，共勉！

HTTP 1.1与HTTP 1.0的比较

一个WEB站点每天可能要接收到上百万的用户请求，为了提高系统的效率，HTTP 1.0规定浏览器与服务器只保持短暂的连接，浏览器的每次请求都需要与服务器建立一个TCP连接，服务器完成请求处理后立即断开TCP连接，服务器不跟踪每个客户也不记录过去的请求。但是，这也造成了一些性能上的缺陷，例如，一个包含有许多图像的网页文件中并没有包含真正的图像数据内容，而只是指明了这些图像的URL地址，当WEB浏览器访问这个网页文件时，浏览器首先要发出针对该网页文件的请求，当浏览器解析WEB服务器返回的该网页文档中的HTML内容时，发现其中的<img>图像标签后，浏览器将根据<img>标签中的src属性所指定的URL地址再次向服务器发出下载图像数据的请求，如图3.3所示。 继续阅读 →

通过对一些静态资源简单的设置，例如设置静态资源的过期时间、以及压缩，可以减少网站的加载时间，同时也能减少服务器的带宽。

在nginx下对静态的过期时间设置为：

        location ~* \.(ico|gif|bmp|jpg|jpeg|png|swf|js|css) {
            root    /var/www/netingcn.com;
            expires 7d;
        }

上述配置能对图片、flash、js、css文件设置了过期时间为7天，当用户在7天内再次访问网站时，大部分情况下都是直接使用本地的缓存，减少网络传输，从而加快了页面加载速度。

压缩的配置如下：

        gzip  on;
        gzip_min_length  1000;
        gzip_buffers     4 8k;
        gzip_types       text/plain application/x-javascript text/css;

对文本、js和css文件进行压缩，一般情况下，压缩后的大小是原始大小的25%，甚至更小。

php5.3以后源码中已经内嵌了 php-fpm，不用象以前的php版本一样专门打补丁了，只需要在configure的时候添加编译参数即可。

关于php-fpm的编译参数有 –enable-fpm –with-fpm-user=www –with-fpm-group=www –with-libevent-dir=libevent位置。
但是，php5.3以后的版本，下的php-fpm不再支持php-fpm以前具有的xx/sbin/php-fpm(start|stop|reload)等命令，需要使用信号控制：
master进程可以理解以下信号
INT, TERM 立刻终止
QUIT 平滑终止
USR1 重新打开日志文件
USR2 平滑重载所有worker进程并重新载入配置和二进制模块
示例：
php-fpm 关闭：
kill -INT `cat /usr/local/php/var/run/php-fpm.pid`
php-fpm 重启：
kill -USR2 `cat /usr/local/php/var/run/php-fpm.pid`
查看php-fpm进程数：
ps aux | grep -c php-fpm

或者这样：

ps axu|grep master|grep php|awk ‘{print $2}’|xargs kill -USR2

Web应用性能优化黄金法则：先优化前端程序(front-end)的性能，因为这是80%或以上的最终用户响应时间的花费所在。下面细细道来14条法则。

• 法则1. 减少HTTP请求次数

80%的最终用户响应时间花在前端程序上，而其大部分时间则花在各种页面元素，如图像、样式表、脚本和Flash等的下载上。减少页面元素将会减少HTTP请求次数。这是快速显示页面的关键所在。

一种减少页面元素个数的方法是简化页面设计。但是否存在其他方式，能做到既有丰富内容，又能获得快速响应时间呢？

Image maps组合多个图片到一张图片中。总文件大小变化不大，但减少了HTTP请求次数从而加快了页面显示速度。该方式只适合图片连续的情况；但坐标的定义是烦人又容易出错的工作。

CSS Sprites是更好的方法。它可以组合页面中的图片到单个文件中，并使用CSS的background-image和background-position属性来现实所需的部分图片。

Combined files通过组合多个脚本文件到单一文件来减少HTTP请求次数。样式表也可采用类似方法处理。这个方法虽然简单，但没有得到大规模的使用。10大美国网站每页平均有7个脚本文件和2个样式表。当页面之间脚本和样式表变化很大时，该方式将遇到很大的挑战，但如果做到的话，将能加快响应时间。

减少HTTP请求次数是性能优化的起点。这对提高首次访问的效率起到很重要的作用。据Tenni Theurer的文章Browser Cache Usage – Exposed!描述，40-60%的日常访问是首次访问。因此，为首次访问者加快页面访问速度是用户体验的关键。

• 法则2. 使用CDN(Content Delivery Network, 内容分发网络)

用户离web server的远近对响应时间也有很大影响。从用户角度看，把内容部署到多个地理位置分散的服务器上将有效提高页面装载速度。但是该从哪里开始呢？ 继续阅读 →

PostgreSQL主要优势：
1. PostgreSQL完全免费，而且是BSD协议，如果你把PostgreSQL改一改，然后再拿去卖钱，也没有人管你，这一点很重要，这表明了 PostgreSQL数据库不会被其它公司控制。oracle数据库不用说了，是商业数据库，不开放。而MySQL数据库虽然是开源的，但现在随着SUN 被oracle公司收购，现在基本上被oracle公司控制，其实在SUN被收购之前，MySQL中最重要的InnoDB引擎也是被oracle公司控制 的，而在MySQL中很多重要的数据都是放在InnoDB引擎中的，反正我们公司都是这样的。所以如果MySQL的市场范围与oracle数据库的市场范 围冲突时，oracle公司必定会牺牲MySQL，这是毫无疑问的。
2. 与PostgreSQl配合的开源软件很多，有很多分布式集群软件，如pgpool、pgcluster、slony、plploxy等等，很容易做读写分离、负载均衡、数据水平拆分等方案，而这在MySQL下则比较困难。
3. PostgreSQL源代码写的很清晰，易读性比MySQL强太多了，怀疑MySQL的源代码被混淆过。所以很多公司都是基本PostgreSQL做二次开发的。
4. PostgreSQL在很多方面都比MySQL强，如复杂SQL的执行、存储过程、触发器、索引。同时PostgreSQL是多进程的，而MySQL是线 程的，虽然并发不高时，MySQL处理速度快，但当并发高的时候，对于现在多核的单台机器上，MySQL的总体处理性能不如PostgreSQL，原因是 MySQL的线程无法充分利用CPU的能力。

PostgreSQL与oracle或InnoDB的多版本实现的差别

PostgreSQL与oracle或InnoDB的多版本实现最大的区别在于最新版本和历史版本是否分离存储，PostgreSQL不分，而oracle和InnoDB分，而innodb也只是分离了数据,索引本身没有分开。
PostgreSQL的主要优势在于：
1. PostgreSQL没有回滚段，而oracle与innodb有回滚段，oracle与Innodb都有回滚段。对于oracle与Innodb来说， 回滚段是非常重要的，回滚段损坏，会导致数据丢失，甚至数据库无法启动的严重问题。另由于PostgreSQL没有回滚段，旧数据都是记录在原先的文件 中，所以当数据库异常crash后，恢复时，不会象oracle与Innodb数据库那样进行那么复杂的恢复，因为oracle与Innodb恢复时同步 需要redo和undo。所以PostgreSQL数据库在出现异常crash后，数据库起不来的几率要比oracle和mysql小一些。
2. 由于旧的数据是直接记录在数据文件中，而不是回滚段中，所以不会象oracle那样经常报ora-01555错误。
3. 回滚可以很快完成，因为回滚并不删除数据，而oracle与Innodb，回滚时很复杂，在事务回滚时必须清理该事务所进行的修改，插入的记录要删除，更新的记录要更新回来(见row_undo函数)，同时回滚的过程也会再次产生大量的redo日志。
4. WAL日志要比oracle和Innodb简单，对于oracle不仅需要记录数据文件的变化，还要记录回滚段的变化。
PostgreSQL的多版本的主要劣势在于：
   1、最新版本和历史版本不分离存储，导致清理老旧版本需要作更多的扫描，代价比较大，但一般的数据库都有高峰期，如果我们合理安排VACUUM，这也不是很大的问题，而且在PostgreSQL9.0中VACUUM进一步被加强了。
2、由于索引中完全没有版本信息，不能实现Coverage index scan，即查询只扫描索引，直接从索引中返回所需的属性，还需要访问表。而oracle与Innodb则可以;

进程模式与线程模式的对比
PostgreSQL和oracle是进程模式，MySQL是线程模式。
进程模式对多CPU利用率比较高。
进程模式共享数据需要用到共享内存，而线程模式数据本身就是在进程空间内都是共享的，不同线程访问只需要控制好线程之间的同步。
线程模式对资源消耗比较少。
所以MySQL能支持远比oracle多的更多的连接。
对于PostgreSQL的来说，如果不使用连接池软件，也存在这个问题，但PostgreSQL中有优秀的连接池软件软件，如pgbouncer和pgpool，所以通过连接池也可以支持很多的连接。

堆表与索引组织表的的对比

Oracle支持堆表，也支持索引组织表
PostgreSQL只支持堆表，不支持索引组织表
Innodb只支持索引组织表
索引组织表的优势：
表内的数据就是按索引的方式组织，数据是有序的，如果数据都是按主键来访问，那么访问数据比较快。而堆表，按主键访问数据时，是需要先按主键索引找到数据的物理位置。
索引组织表的劣势：
索引组织表中上再加其它的索引时，其它的索引记录的数据位置不再是物理位置，而是主键值，所以对于索引组织表来说，主键的值不能太大，否则占用的空间比较大。
对于索引组织表来说，如果每次在中间插入数据，可能会导致索引分裂，索引分裂会大大降低插入的性能。所以对于使用innodb来说，我们一般最好让主键是一个无意义的序列，这样插入每次都发生在最后，以避免这个问题。
由于索引组织表是按一个索引树，一般它访问数据块必须按数据块之间的关系进行访问，而不是按物理块的访问数据的，所以当做全表扫描时要比堆表慢很多，这可能在OLTP中不明显，但在数据仓库的应用中可能是一个问题。

PostgreSQL9.0中的特色功能：
PostgreSQL中的Hot Standby功能
也就是standby在应用日志同步时，还可以提供只读服务，这对做读写分离很有用。这个功能是oracle11g才有的功能。

PostgreSQL异步提交（Asynchronous Commit）的功能：
这个功能oracle中也是到oracle11g R2才有的功能。因为在很多应用场景中，当宕机时是允许丢失少量数据的，这个功能在这样的场景中就特别合适。在PostgreSQL9.0中把 synchronous_commit设置为false就打开了这个功能。需要注意的是，虽然设置为了异步提交，当主机宕机时，PostgreSQL只会 丢失少量数据，异步提交并不会导致数据损坏而数据库起不来的情况。MySQL中没有听说过有这个功能。

PostgreSQL中索引的特色功能：
PostgreSQL中可以有部分索引，也就是只能表中的部分数据做索引，create index 可以带where 条件。同时PostgreSQL中的索引可以反向扫描，所以在PostgreSQL中可以不必建专门的降序索引了。