XHProf是facebook开源出来的一个php轻量级的性能分析工具，跟Xdebug类似，但性能开销更低，还可以用在生产环境中，也可以由程序开 关来控制是否进行profile。基于浏览器的性能分析用户界面能更容易查看，或是与同行们分享成果。也能绘制调用关系图。在数据收集阶段，它记录调用次 数的追踪和包容性的指标弧在动态callgraph的一个程序。它独有的数据计算的报告/后处理阶段。在数据收集时，XHProfd通过检测循环来处理递 归的函数调用，并通过给递归调用中每个深度的调用一个有用的命名来避开死循环。
XHProf的轻量级性质和汇聚功能，使得它非常适合用于收集“生产环境”的性能统计数据的统计。

一、编译安装XHProf
[root@localhost src]# wget http://pecl.php.net/get/xhprof-0.9.2.tgz
[root@localhost src]# tar zxf xhprof-0.9.2.tgz
[root@localhost src]# cd xhprof-0.9.2
[root@localhost xhprof-0.9.2]# cp -r xhprof_html xhprof_lib /var/www/html/
[root@localhost xhprof-0.9.2]# cd extension/
[root@localhost extension]# /usr/local/webserver/php/bin/phpize
[root@localhost extension]# ./configure  –with-php-config=/usr/local/webserver/php/bin/php-config

二、配置 php.ini 文件
vi vi /usr/local/webserver/php/etc/php.ini  修改php.ini


OK 重启WEB服务器。为了更加清晰显示程序执行、调用结构，安装Graphviz。

三、安装Graphviz：
[root@localhost src]# wget http://www.graphviz.org/pub/graphviz/stable/SOURCES/graphviz-2.24.0.tar.gz
[root@localhost src]# tar zxf graphviz-2.24.0.tar.gz
[root@localhost graphviz-2.24.0]# cd graphviz-2.24.0
[root@localhost graphviz-2.24.0]# ./configure
[root@localhost graphviz-2.24.0]# make
[root@localhost graphviz-2.24.0# make install

四、应用XHProf
客户端能很灵活地保存他们从XHProf运行中得到的XHProf原始数据。用户界面层的XHProf提供了一个 iXHProfRuns接口（见xhprof_lib/utils/xhprof_runs.php ），客户端可以利用。这使得客户端能够告诉用户界面层，如何获取XHProf运行后产生的对应数据。
XHProf的UI 库自带的有一个基于文件的iXHProfRUns接口实现，即“ XHProfRuns_Default”（见xhprof_lib/utils/xhprof_runs.php）。这个自带的实现将XHProf运行结 果存在ini配置的xhprof.output_dir参数指定的某个目录下。
一次XHProf运行，必须用一个命名空间和运行编号来唯一确定。
假设使用iXHProfRuns接口的XHProfRuns_Default这个默认实现方式，如：

//xhprofStart.php 文件


//xhprofEnd.php 文件


程序中应用：


将profile开关程序放在你所要进行分析的程序部分，就会将运行结果保存在xhprof.output_dir ini参数指定的特定目录下。文件的名称可能会是23dffaa3a3f66.xhprof_foo类似的文件; 两部分分别是运行编号（23dffaa3a3f6）和命名空间（xhprof_foo）。


最后，一些术语解释:
1. Inclusive Time (或子树时间)：包括子函数所有执行时间。
2. Exclusive Time/Self Time：函数执行本身花费的时间，不包括子树执行时间。
3. Wall时间：花去了的时间或挂钟时间。
4. CPU时间：用户耗的时间+内核耗的时间
更多：http://mirror.facebook.net/facebook/xhprof/doc.html

GFS(Google File System):
http://www.codechina.org/doc/google/gfs-paper/

MogileFS:
http://www.danga.com/mogilefs

Hadoop/HDFS:
http://hadoop.apache.org/core

KFS(Kosmos Distributed File System):
http://kosmosfs.sourceforge.net

NDFS(Nutch Distributed File System):
http://lucene.apache.org/nutch/
http://wiki.apache.org/nutch/NutchDistributedFileSystem

Gluster(Gluster File System):
http://www.gluster.org

Coda(Coda File System):
http://www.coda.cs.cmu.edu/

Global(Red Hat Global File System Redhat并购):
http://www.redhat.com/gfs

Lustre(Lustre File System Sun并购):
http://www.lustre.org

PVFS(Parallel Virtual File System，非开源):
http://www.parl.clemson.edu/pvfs

GPFS(IBM General Parallel File System, 非开源):
http://www-03.ibm.com/systems/clusters/software/gpfs

OpenAFS(Open Andrew File System IBM):
http://www.openafs.org

XFS(SGI, 不算分布式文件系统):
http://oss.sgi.com/projects/xfs

MOSIX:
http://www.mosix.org

还有一个国内牛人写的FastDFS一个高效的分布式文件系统
http://code.google.com/p/fastdfs/

      一些操作系统的最新版本已经更新了 /proc/cpuinfo 文件,以支持多路平台.如果您的系统中的 /proc/cpuinfo 文件能够正确地反映出处理器信息,那么就不需要执行上述步骤.反之,可采用本文中的信息进行解释.

      /proc/cpuinfo 文件包含系统上每个处理器的数据段落./proc/cpuinfo 描述中有 6 个条目适用于多内核和超线程(HT)技术检查：processor, vendor id, physical id, siblings, core id 和 cpu cores.

processor 条目包括这一逻辑处理器的唯一标识符.
physical id 条目包括每个物理封装的唯一标识符.
core id 条目保存每个内核的唯一标识符.
siblings 条目列出了位于相同物理封装中的逻辑处理器的数量.
cpu cores 条目包含位于相同物理封装中的内核数量.
如果处理器为英特尔处理器,则 vendor id 条目中的字符串是 GenuineIntel.

      拥有相同 physical id 的所有逻辑处理器共享同一个物理插座.每个 physical id 代表一个唯一的物理封装.Siblings 表示位于这一物理封装上的逻辑处理器的数量.它们可能支持也可能不支持超线程(HT)技术.每个 core id 均代表一个唯一的处理器内核.所有带有相同 core id 的逻辑处理器均位于同一个处理器内核上.如果有一个以上逻辑处理器拥有相同的 core id 和 physical id,则说明系统支持超线程(HT)技术.如果有两个或两个以上的逻辑处理器拥有相同的 physical id,但是 core id 不同,则说明这是一个多内核处理器.cpu cores 条目也可以表示是否支持多内核.

      例如,如果系统包含两个物理封装,每个封装中又包含两个支持超线程(HT)技术的处理器内核,则 /proc/cpuinfo 文件将包含此数据.(注：数据并不在表格中.)


processor    0  1  2  3  4  5  6  7
physical id    0  1  0  1  0  1  0  1
core id        0  2  1  3  0  2  1  3
siblings        4  4  4  4  4  4  4  4
cpu cores    2  2  2  2  2  2  2  2

      此例说明逻辑处理器 0 和 4 驻留在物理封装 0 的内核 0 上.这就表示逻辑处理器 0 和 4 支持超线程(HT)技术.相同的工作可用于封装 0 内核 1 上的逻辑处理器 2 和 6,封装 1 内核 2 上的逻辑处理器 1 和 5,以及封装 1 内核 3 上的逻辑处理器 3 和 7.此系统支持超线程(HT)技术,因为两个逻辑处理器共享同一个内核.有两种方式可以确定是否支持多内核.由于内核 0 和 1 存在于封装 0 上,而内核 2 和 3 存在于封装 1 上,所以这是一个多内核系统.此外,cpu cores 条目为 2,也说明有两个内核驻留在物理封装中.这是一个多路系统,因为有两个封装.

      值得注意的是 physical id 和 core id 的编号可能是也可能不是连续的.系统上有两个物理封装并不罕见,而且 physical id 等于 0 和 3

通过physical id来判断，硬件的CPU Socket到底有几个，即按照插槽来计算的CPU
个数，如果你的是两个四核CPU，那么physical id应该是0和1;
通过sibling来判断，一个socket上的CPU是否是双核或者超线程：

如果sibling是2，而后面的cpu cores也是2，那么这个CPU则是双核；
如果sibling是1，而后面的cpu cores若是1，那么这个CPU是单核但支持超线程；
如果sibling是4，而后面的cpu cores也是2，那么这个CPU则是双核且每个核都支
持超线程；
如果sibling是4，而后面的cpu cores若是4，那么这个CPU是4核但不支持超线程

core id通常表示在一个CPU Socket上物理核心的id编号。

在搭建squid网页加速的时候，对于大的css 或者js要进行压缩,然后再进行缓存,这样能够提高减小下载量提高页面响应速度。如果你用的是squid 3.0以前的版本并且用的是 ngnix server的话可能会碰到如下问题： 不用squid直接打开页面则客户端返回的是压缩的状态，如果启用squid加速会发现下载下来的页面不是压缩状态。这里面主要是没有启动ngnix 的静态缓存模块(ngx_http_gzip_static_module)导致。打开静态缓存问题就解决了
1.nginx编译选项
./configure --with-http_gzip_static_module
2.修改nginx.conf

gzip_static on;

gzip_http_version 1.1;
gzip_proxied expired no-cache no-store private auth;
gzip_disable "MSIE [1-6] \.";
gzip_vary on;


参考：
1.http://wiki.nginx.org/NginxHttpGzipStaticModule
2.http://bbs.chinaunix.net/viewthread.php?tid=1329820

注意修改安装路径了

[code]#!/bin/bash
#
# Init file for nginx server daemon
#
# chkconfig: 234 99 99
# description: nginx server daemon
#

# source function library
. /etc/rc.d/init.d/functions

# pull in sysconfig settings
[ -f /etc/sysconfig/nginx ] && . /etc/sysconfig/nginx

RETVAL=0
prog="nginx"

PAT=/usr/local/nginx
NGINXD=/usr/local/nginx/sbin/nginx
PID_FILE=/usr/local/nginx/nginx.pid
<