一进后台超级不适应，整个后台大换脸，看来还是要有短时间来适应下，不过整体来看还是很漂亮的，使用起来非常舒服，新加入的评论分页还没有机会尝试，毕竟来小窝串门的人还不是很多，以后还是有机会的，其他的新功能在慢慢研究了，已经2点了，明天还要去单位参加培训，休息去喽O(∩_∩)O

在[name]Slyar,http://www.slyar.com/blog/[/name]的blog上看到相关的一篇文章[name]修改WordPress标签云的字体大小以及显示数量,http://www.slyar.com/blog/tag-cloud-font.html[/name]介绍到标签云的一系列参数，顺便也转录过来了：

smallest – Adjusts the size of the smallest tags in the cloud. Default is “8″.
largest – Adjusts the size of the biggest tags in the cloud. Default is “22″.
unit – Sets the unit type for font size (i.e. point or em). Default is “pt”.
number – How many tags will display in the cloud. Default is “45″.
format – “Flat” displays an inline cloud with each term separated by whitespace. “List” generates an unordered list. “Array” lets you define an array of tags. Default is “flat”.
orderby – Sort the cloud by “name” or “count”. Default is “name”.
order – Sort the cloud in ascending or descending order. Default is “ASC”.

把参数值写入wp-includeswidgets.php中的wp_tag_cloud()函数中即可，例如：

wp_tag_cloud('unit=px&smallest=12&largest=20&number=50&orderby=count');

即把标签云设置成最大字体20像素，最小字体12像素，显示数目50，按照使用次数排序

在上篇文章中曾经提到了字体小等等一些问题，这几天好好看了下附带的说明文档，其实这些都可以设置的。在说明文档Chart XML Reference栏目下就有详细的参数说明，针对不同的统计图表都用不同的参数说明。公共部分比如baseFont：设置字体样式；baseFontSize：设置字体大小，将<graph>中间加上baseFontSize=‘12’,字体就变成12号字了；还有numberPrefix、numberSuffix：前缀、后缀，根据说明中的提示“To use special characters for numberPrefix or numberSuffix, you’ll need to URL Encode them.”，比如后缀想显示“元”，在graph标签种应该设置成numberSuffix=‘%D4%AA’，一些文本编辑器支持代码转换可以直接转，实在找不到可以借用搜索引擎，例如百度，在搜索框输入“元”，点搜索，在地址栏里面“http://www.baidu.com.cn/s?wd=%D4%AA”中的wd=后面的字符串就是“元”字转过的编码。参数有许多，根据不同的图表，参数也有不同之处，可以通过设置不同的参数显示出很有个性的统计图出来。这里就不再一一说明了，可以参照说明文档中的说明，虽然都是英文版的，但是很简单明了，一般写过程序的基本都能看得懂。

最后顺便提下LICENSE，免费版只用于individual/research/commercial（个人/研究/交流），要尊重别人的劳动成果和知识产权。LICENSE如下：

• FusionCharts Free can be used for free if you are a individual/research/commercial user.
• FusionCharts Free can be distributed for free with your free or commercial softwares, irrespective of whether they’re open source or closed source.
• You must not sell FusionCharts Free as a component in itself. However, your commercial product can embed FusionCharts Free.
• You must not represent in any way that you’re the author of FusionCharts Free.

WP居然不自带文章点击数的统计，难道国外的博客都不将点击数作为一种衡量标准吗？虽然说点击数水分比较大，但是也不至于舍弃这个功能吧，也仅仅是加个字段，加几句代码罢了。依旧发挥懒猫精神，下了[name]wp-postviews,http://lesterchan.net/wordpress/readme/wp-postviews.html[/name]，安装后，在样式侧边管理里面多了一个新的模块，可以显示热门文章了，不过我遇到了两个很奇怪的问题，一个就是将计数器控制调整成everyone，怎么刷新都不见点击数加1；另外就是之前All in One SEO Pack所设置的meta标签内容全部乱码了-_-!暂时先停止这个插件，之后慢慢研究那块冲突了。

懒猫还是比较爱吃的，准备抽个时间把以前网上搜索的食谱整理下，发出来，一是方便自己查找，二是有福共享嘛。

晚上天气还是好冷。。。打一会字就手脚冰凉了，不多写了，钻被窝了。O(∩_∩)O

前几天又遇到网站显示统计图的需求，网上找了一下，大部分是要求组件。检索到一个用VML的解决方案，显示效果还比较满意，就先使用着了。不过随后发现VML只支持IE，没办法，只有放弃。

网上搜索时无意在一篇[name]博文,http://hi.baidu.com/phoenix_lee15/blog/item/effcac13cc66f8045baf5330.html[/name]中看到了一款叫[name]FusionChartsFree,http://www.filetransit.com/go.php?id=34476-4-1[/name]的Flash版统计图，下来试用了下，内附的使用文档还是很全面的，包括用法和例子。有点遗憾的是没有源码，不过一个free版也不能要求太多。还有一点就是中文汉字显示很小，估计只有10号，英文还能看清，中文基本就是一团。暂时先不填写XML中的标题和描述，先凑合用了。继续寻找更好的统计图。

后附几张效果图，从自带说明文档里面截取的：

上网查了下资料，遇到这个问题的人并不多，还在有人提起，也有热心人回复了大概原因以及大概解决方案：原因是空间商启用了某种缓存机制导致取IP产生错误，使得结果都是本机IP，也就是127.0.0.1。解决方案也很简单，更换获取IP语句就好。

查了下PHP获取IP的语句，主要是以下几种

$_SERVER["HTTP_X_FORWARDED_FOR";
$_SERVER["HTTP_CLIENT_IP"];
$_SERVER["REMOTE_ADDR"];
getenv("HTTP_X_FORWARDED_FOR");
getenv("HTTP_CLIENT_IP");
getenv("REMOTE_ADDR");

剩下的就很简单了，写一个测试页面，一个一个试，看那个能显示正确的IP地址，在修改/wp-includes/comment.php ,我的文件是在第718行

$commentdata['comment_author_IP'] = preg_replace( '/[^0-9a-fA-F:., ]/', '',$_SERVER['REMOTE_ADDR'] );

将$_SERVER['REMOTE_ADDR']改成上面测试正确IP的语句，问题解决。

本人对PHP还是初学者阶段，如有叙述不当之处，还希望多多斧正。

在网上搜索了下，先用的是[name]Syntax Highlighter,http://code.google.com/p/syntaxhighlighter/[/name]，页面显示还是很漂亮的，不过可能是纯JS的缘故，我这显示总是用一种滞后。页面打开后，显示的是普通的代码，代码比较长，页面版面变形厉害，等页面输出完毕后，代码部分才变成需要的高亮样式，感觉比较难受，而且个人喜欢使用禁用JS的火狐上网，看自己页面效果全无。只有先放一边了。

下载[name]iG Syntax Hiliter,http://blog.igeek.info/still-fresh/2006/02/25/code-for-fun/[/name]，启用的时候不同的提示严重错误，无法启动，错误代码是：路径/geshi.php不存在，一头雾水，在服务器上查了下，文件的确在那，头晕中。

[name]Highlight Source Pro,http://blog.kno.at/tools/highlight-source-pro[/name]和[name]WP-Syntax,http://wordpress.org/extend/plugins/wp-syntax/[/name]有点类似，使用pre标签，每行代码短还好，代码一长，滚动条就出来了，有点破坏整体风格，虽然有些人可能喜欢滚动条。

暂时先用着WP-Syntax了，毕竟用到代码的地方并不是很多，有空再去网上找找其他的高亮插件了。

在论坛上常见有朋友抱怨，说SQL Server太吃内存了。这里笔者根据经验简单介绍一下内存相关的调优知识。首先说明一下SQL Server内存占用由哪几部分组成。SQL Server占用的内存主要由三部分组成：数据缓存(Data Buffer)、执行缓存(Procedure Cache)、以及SQL Server引擎程序。SQL Server引擎程序所占用缓存一般相对变化不大，则我们进行内存调优的主要着眼点在数据缓存和执行缓存的控制上。本文主要介绍一下执行缓存的调优。数据缓存的调优将在另外的文章中介绍。

对于减少执行缓存的占用，主要可以通过使用参数化查询减少内存占用。

1、使用参数化查询减少执行缓存占用

我们通过如下例子来说明一下使用参数化查询对缓存占用的影响。为方便试验，我们使用了一台没有其它负载的SQL Server进行如下实验。下面的脚本循环执行一个简单的查询，共执行10000次。
　　首先，我们清空一下SQL Server已经占用的缓存：

dbcc freeproccache

　　然后，执行脚本：

DECLARE @t datetime
SET @t = getdate()
SET NOCOUNT ON
DECLARE @i INT, @count INT, @sql nvarchar(4000)
SET @i = 20000
WHILE @i <= 30000
BEGIN
    SET @sql = 'SELECT @count=count(*) FROM P_Order WHERE MobileNo = ' + cast( @i as varchar(10) )
    EXEC sp_executesql @sql ,N'@count INT OUTPUT', @count OUTPUT
    SET @i = @i + 1
END
PRINT DATEDIFF( second, @t, current_timestamp )

输出：
DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。
11

使用了11秒完成10000次查询。

我们看一下SQL Server缓存中所占用的查询计划：

Select Count(*) CNT,sum(size_in_bytes) TotalSize From sys.dm_exec_cached_plans

查询结果：共有2628条执行计划缓存在SQL Server中。它们所占用的缓存达到：
92172288字节 = 90012KB = 87 MB。

我们也可以使用dbcc memorystatus 命令来检查SQL Server的执行缓存和数据缓存占用。执行结果如下：

执行缓存占用了90088KB，有2629个查询计划在缓存里，有1489页空闲内存（每页8KB）可以被数据缓存和其他请求所使用。

我们现在修改一下前面的脚本，然后重新执行一下dbcc freeproccache。再执行一遍修改后的脚本：

DECLARE @t datetime
SET @t = getdate()
SET NOCOUNT ON
DECLARE @i INT, @count INT, @sql nvarchar(4000)
SET @i = 20000
WHILE @i <= 30000
BEGIN
    SET @sql = 'select @count=count(*) FROM P_Order WHERE MobileNo = @i'
    EXEC sp_executesql @sql, N'@count int output, @i int', @count OUTPUT, @i
    SET @i = @i + 1
END
PRINT DATEDIFF( second, @t, current_timestamp )

输出：
DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。
1
即这次只用1秒钟即完成了10000次查询。

我们再看一下sys.dm_exec_cached_plans中的查询计划：

Select Count(*) CNT,sum(size_in_bytes) TotalSize From sys.dm_exec_cached_plans

查询结果：共有4条执行计划被缓存。它们共占用内存： 172032字节 = 168KB。
如果执行dbcc memorystatus，则得到结果：



有12875页空闲内存(每页8KB)可以被数据缓存所使用。

到这里，我们已经看到了一个反差相当明显的结果。在现实中，这个例子中的前者，正是经常被使用的一种执行SQL脚本的方式（例如：在程序中通过合并字符串方式拼成一条SQL语句，然后通过ADO.NET或者ADO方式传入SQL Server执行）。

解释一下原因：

我们知道，SQL语句在执行前首先将被编译并通过查询优化引擎进行优化，从而得到优化后的执行计划，然后按照执行计划被执行。对于整体相似、仅仅是参数不同的SQL语句，SQL Server可以重用执行计划。但对于不同的SQL语句，SQL Server并不能重复使用以前的执行计划，而是需要重新编译出一个新的执行计划。同时，SQL Server在内存足够使用的情况下，此时并不主动清除以前保存的查询计划（注：对于长时间不再使用的查询计划，SQL Server也会定期清理）。这样，不同的SQL语句执行方式，就将会大大影响SQL Server中存储的查询计划数目。如果限定了SQL Server最大可用内存，则过多无用的执行计划占用，将导致SQL Server可用内存减少，从而在执行查询时尤其是大的查询时与磁盘发生更多的内存页交换。如果没有限定最大可用内存，则SQL Server由于可用内存减少，从而会占用更多内存。

对此，我们一般可以通过两种方式实现参数化查询：一是尽可能使用存储过程执行SQL语句（这在现实中已经成为SQL Server DBA的一条原则），二是使用sp_executesql 方式执行单个SQL语句（注意不要像上面的第一个例子那样使用sp_executesql)。

在现实的同一个软件系统中，大量的负载类型往往是类似的，所区别的也只是每次传入的具体参数值的不同。所以使用参数化查询是必要和可能的。另外，通过这个例子我们也看到，由于使用了参数化查询，不仅仅是优化了SQL Server内存占用，而且由于能够重复使用前面被编译的执行计划，使后面的执行不需要再次编译，最终执行10000次查询总共只使用了1秒钟时间。

2、检查并分析SQL Server执行缓存中的执行计划

通过上面的介绍，我们可以看到SQL缓存所占用的内存大小。也知道了SQL Server执行缓存中的内容主要是各种SQL语句的执行计划。则要对缓存进行优化，就可以通过具体分析缓存中的执行计划，看看哪些是有用的、哪些是无用的执行计划来分析和定位问题。

通过查询DMV: sys.dm_exec_cached_plans,可以了解数据库中的缓存情况，包括被使用的次数、缓存类型、占用的内存大小等。

SELECT usecounts, cacheobjtype, objtype,size_in_bytes, plan_handle FROM sys.dm_exec_cached_plans

通过缓存计划的plan_handle可以查询到该执行计划详细信息，包括所对应的SQL语句：

SELECT TOP 100 usecounts,
    objtype,
    p.size_in_bytes,
    [sql].[text]
FROM sys.dm_exec_cached_plans p
OUTER APPLY sys.dm_exec_sql_text (p.plan_handle) sql
ORDER BY usecounts

我们可以选择针对那些执行计划占用较大内存、而被重用次数较少的SQL语句进行重点分析。看其调用方式是否合理。另外，也可以对执行计划被重复使用次数较多的SQL语句进行分析，看其执行计划是否已经经过优化。进一步，通过对查询计划的分析，还可以根据需要找到系统中最占用IO、CPU时间、执行次数最多的一些SQL语句，然后进行相应的调优分析。篇幅所限，这里不对此进行过多介绍。读者可以查阅联机丛书中的：sys.dm_exec_query_plan内容得到相关帮助。

附：
1:关于DBCC MEMORY，可以查看微软的知识库: http://support.microsoft.com/kb/907877/EN-US
2:关于sys.dm_exec_cached_plans和sys.dm_exec_sql_text，请参阅联机丛书。

Yahoo! 的 Exceptional Performance team 在 Web 前端方面作出了卓越的贡献。广为人知的优化规则也由 13 条到 14 条，再到 20 条，乃至现在的 34 条–真是与时俱进啊。最新的 34 条也针对不同的角度做了分类。

面向内容的优化规则目前有 10 条。

1. 尽量减少 HTTP 请求 (Make Fewer HTTP Requests)

作为第一条，可能也是最重要的一条。根据 Yahoo! 研究团队的数据分析，有很大一部分用户访问会因为这一条而取得最大受益。有几种常见的方法能切实减少 HTTP 请求：
    * 1) 合并文件，比如把多个 CSS 文件合成一个；
    * 2) CSS Sprites 利用 CSS background 相关元素进行背景图绝对定位；参见：CSS Sprites: Image Slicing’s Kiss of Death
    * 3) 图像地图
    * 4) 内联图象 使用 data: URL scheme 在实际的页面嵌入图像数据.

2. 减少 DNS 查找 (Reduce DNS Lookups)

必须明确的一点，DNS 查找的开销是很大的。另外，我倒是觉得这是 Yahoo! 所有站点的通病，Yahoo！主站点可能还不够明显，一些分站点，存在明显的类似问题。对于国内站点来说，如果过多的使用了站外的 Widget ，也很容易引起过多的 DNS 查找问题。

3. 避免重定向 (Avoid Redirects)

不是绝对的避免，尽量减少。另外，应该注意一些不必要的重定向。比如对 Web 站点子目录的后面添加个 / (Slash) ，就能有效避免一次重定向。http://www.dbanotes.net/arch 与 http://www.dbanotes.net/arch/ 二者之间是有差异的。如果是 Apache 服务器，通过配置 Alias 或mod_rewrite 或是 DirectorySlash 能够消除这个问题。

4. 使得 Ajax 可缓存 (Make Ajax Cacheable)

响应时间对 Ajax 来说至关重要，否则用户体验绝对好不到哪里去。提高响应时间的有效手段就是 Cache 。其它的一些优化规则对这一条也是有效的。

5. 延迟载入组件 (Post-load Components)

6. 预载入组件 (Preload Components)

上面两条严格说来，都是属于异步这个思想灵活运用的事儿。

7. 减少 DOM 元素数量 (Reduce the Number of DOM Elements)

8. 切分组件到多个域 (Split Components Across Domains)

主要的目的是提高页面组件并行下载能力。但不要跨太多域名，否则就和第二条有些冲突了。

9. 最小化 iframe 的数量 (Minimize the Number of iframes)

熟悉 SEO 的朋友知道 iframe 是 SEO 的大忌。针对前端优化来说 iframe 有其好处，也有其弊端，一分为二看问题吧。

10. 杜绝 http 404 错误 (No 404s)

对页面链接的充分测试加上对 Web 服务器 error 日志的不断跟踪能有效减少 404 错误，亦能提升用户体验。值得一提的是，CSS 与 Java Script 引起的 404 错误因为定位稍稍”难”一点而往往容易被忽略。

这是内容篇的 10 条。应该说具体引导性的内容还不够详细。逐渐会根据自己的理解补充上来。

原理：当程序试图访问网络的时候，首先调用ws2_32.dll这个动态链接库！但一般蓝屏代码0x000000f4程序有个问题就是先找自己目录下面有没有这个文件，有个话就调用自己目录下面的！否则的话就调用WIN目录下面的。

DLL文件：ws2_32或者ws2_32.dll DLL
名称：WinSock2.032bit
描述： ws2_32.dll是WindowsSocket蓝屏死机s应用程序接口，用于支持Internet和网络应用程序。