博客园_eaglet

获取ALL USER 的特殊目录的类

2012-05-23T06:39:00Z

.net 框架中提供的 System.Environment.GetFolderPath 只能获取当前用户的特殊目录，无法获取所有用户的特殊目录。我做了一个类，可以帮助获取所有用户的特殊目录。这个类调用SHGetFolderPath windows API 来获取ALL USER 的特殊目录路径，网上有很多相关的文章用的API是有些过时了，这篇文章中的API可以适用于windows 2000 后的任何操作系统。

using System;using System.Collections.Generic;using System.Text;using System.Runtime.InteropServices; namespace MySystem{ public class Environment { [DllImport("shell32.dll")] static extern int SHGetFolderPath(IntPtr hwndOwner, SpecialFolderCSIDL nFolder, IntPtr hToken, uint dwFlags, [Out] StringBuilder pszPath); private const int MAX_PATH = 260; public enum SpecialFolderCSIDL : int { CSIDL_DESKTOP = 0x0000, // <desktop> CSIDL_INTERNET = 0x0001, // Internet Explorer (icon on desktop) CSIDL_PROGRAMS = 0x0002, // Start Menu\Programs CSIDL_CONTROLS = 0x0003, // My Computer\Control Panel CSIDL_PRINTERS = 0x0004, // My Computer\Printers CSIDL_PERSONAL = 0x0005, // My Documents CSIDL_FAVORITES = 0x0006, // <user name>\Favorites CSIDL_STARTUP = 0x0007, // Start Menu\Programs\Startup CSIDL_RECENT = 0x0008, // <user name>\Recent CSIDL_SENDTO = 0x0009, // <user name>\SendTo CSIDL_BITBUCKET = 0x000a, // <desktop>\Recycle Bin CSIDL_STARTMENU = 0x000b, // <user name>\Start Menu CSIDL_MYMUSIC = 0x000d, // CSIDL_DESKTOPDIRECTORY = 0x0010, // <user name>\Desktop CSIDL_DRIVES = 0x0011, // My Computer CSIDL_NETWORK = 0x0012, // Network Neighborhood CSIDL_NETHOOD = 0x0013, // <user name>\nethood CSIDL_FONTS = 0x0014, // windows\fonts CSIDL_TEMPLATES = 0x0015, CSIDL_COMMON_STARTMENU = 0x0016, // All Users\Start Menu CSIDL_COMMON_PROGRAMS = 0x0017, // All Users\Programs CSIDL_COMMON_STARTUP = 0x0018, // All Users\Startup CSIDL_COMMON_DESKTOPDIRECTORY = 0x0019, // All Users\Desktop CSIDL_APPDATA = 0x001a, // <user name>\Application Data CSIDL_PRINTHOOD = 0x001b, // <user name>\PrintHood CSIDL_LOCAL_APPDATA = 0x001c, // <user name>\Local Settings\Applicaiton Data (non roaming) CSIDL_ALTSTARTUP = 0x001d, // non localized startup CSIDL_COMMON_ALTSTARTUP = 0x001e, // non localized common startup CSIDL_COMMON_FAVORITES = 0x001f, CSIDL_INTERNET_CACHE = 0x0020, CSIDL_COOKIES = 0x0021, CSIDL_HISTORY = 0x0022, CSIDL_COMMON_APPDATA = 0x0023, // All Users\Application Data CSIDL_WINDOWS = 0x0024, // GetWindowsDirectory() CSIDL_SYSTEM = 0x0025, // GetSystemDirectory() CSIDL_PROGRAM_FILES = 0x0026, // C:\Program Files CSIDL_MYPICTURES = 0x0027, // C:\Program Files\My Pictures CSIDL_PROFILE = 0x0028, // USERPROFILE CSIDL_SYSTEMX86 = 0x0029, // x86 system directory on RISC CSIDL_PROGRAM_FILESX86 = 0x002a, // x86 C:\Program Files on RISC CSIDL_PROGRAM_FILES_COMMON = 0x002b, // C:\Program Files\Common CSIDL_PROGRAM_FILES_COMMONX86 = 0x002c, // x86 Program Files\Common on RISC CSIDL_COMMON_TEMPLATES = 0x002d, // All Users\Templates CSIDL_COMMON_DOCUMENTS = 0x002e, // All Users\Documents CSIDL_COMMON_ADMINTOOLS = 0x002f, // All Users\Start Menu\Programs\Administrative Tools CSIDL_ADMINTOOLS = 0x0030, // <user name>\Start Menu\Programs\Administrative Tools CSIDL_CONNECTIONS = 0x0031, // Network and Dial-up Connections }; public static string GetAllUsersFolderPath(SpecialFolderCSIDL csidl) { StringBuilder path = new StringBuilder(MAX_PATH); SHGetFolderPath(IntPtr.Zero, csidl, IntPtr.Zero, 0, path); return path.ToString(); } public static string GetAllUsersFolderPath(System.Environment.SpecialFolder specialFolder) { SpecialFolderCSIDL csidl; switch (specialFolder) { case System.Environment.SpecialFolder.ApplicationData: csidl = SpecialFolderCSIDL.CSIDL_APPDATA; break; case System.Environment.SpecialFolder.CommonApplicationData: csidl = SpecialFolderCSIDL.CSIDL_COMMON_APPDATA; break; case System.Environment.SpecialFolder.CommonProgramFiles: csidl = SpecialFolderCSIDL.CSIDL_COMMON_PROGRAMS; break; case System.Environment.SpecialFolder.Cookies: csidl = SpecialFolderCSIDL.CSIDL_COOKIES; break; case System.Environment.SpecialFolder.Desktop: csidl = SpecialFolderCSIDL.CSIDL_COMMON_DESKTOPDIRECTORY; break; case System.Environment.SpecialFolder.DesktopDirectory: csidl = SpecialFolderCSIDL.CSIDL_COMMON_DESKTOPDIRECTORY; break; case System.Environment.SpecialFolder.Favorites: csidl = SpecialFolderCSIDL.CSIDL_COMMON_FAVORITES; break; case System.Environment.SpecialFolder.History: csidl = SpecialFolderCSIDL.CSIDL_HISTORY; break; case System.Environment.SpecialFolder.InternetCache: csidl = SpecialFolderCSIDL.CSIDL_INTERNET_CACHE; break; case System.Environment.SpecialFolder.LocalApplicationData: csidl = SpecialFolderCSIDL.CSIDL_LOCAL_APPDATA; break; case System.Environment.SpecialFolder.MyComputer: csidl = SpecialFolderCSIDL.CSIDL_DRIVES; break; case System.Environment.SpecialFolder.MyDocuments: csidl = SpecialFolderCSIDL.CSIDL_COMMON_DOCUMENTS; break; case System.Environment.SpecialFolder.MyMusic: csidl = SpecialFolderCSIDL.CSIDL_MYMUSIC; break; case System.Environment.SpecialFolder.MyPictures: csidl = SpecialFolderCSIDL.CSIDL_MYPICTURES; break; case System.Environment.SpecialFolder.ProgramFiles: csidl = SpecialFolderCSIDL.CSIDL_PROGRAM_FILES; break; case System.Environment.SpecialFolder.Programs: csidl = SpecialFolderCSIDL.CSIDL_COMMON_PROGRAMS; break; case System.Environment.SpecialFolder.Recent: csidl = SpecialFolderCSIDL.CSIDL_RECENT; break; case System.Environment.SpecialFolder.SendTo: csidl = SpecialFolderCSIDL.CSIDL_SENDTO; break; case System.Environment.SpecialFolder.StartMenu: csidl = SpecialFolderCSIDL.CSIDL_COMMON_STARTMENU; break; case System.Environment.SpecialFolder.Startup: csidl = SpecialFolderCSIDL.CSIDL_COMMON_STARTUP; break; case System.Environment.SpecialFolder.System: csidl = SpecialFolderCSIDL.CSIDL_SYSTEM; break; case System.Environment.SpecialFolder.Templates: csidl = SpecialFolderCSIDL.CSIDL_COMMON_TEMPLATES; break; default: csidl = SpecialFolderCSIDL.CSIDL_COMMON_DOCUMENTS; break; } return GetAllUsersFolderPath(csidl); } }}

本文链接

i—比 i++ 快？

2012-05-21T01:44:00Z

今天在微博上看到有人说 i—比 i++ 快，我用C写了个程序测试了一下，还真的是快，难道减法运算比加法快？从原理上分析感觉不可能啊，于是深入研究了一下，终于找到原因。

先看一下测试代码：

#include <stdio.h>
#include <time.h>

int main()
{
int count = 1000000000;

clock_t cl = clock ();

for(int i = count; i > 0 ; i--)
{
}

printf("Elapse %u ms\r\n", (clock () - cl));

cl = clock ();

for(int i = 0; i < count ; i++)
{
}

printf("Elapse %u ms\r\n", (clock () - cl));

return 0;
}

以上代码在VC 2008 下编译，编译时取消优化选项（如果不取消优化的话，上面两个循环语句由于什么都没干，会被编译器优化掉)。

运行后的结果是
Elapse 2267 ms
Elapse 2569 ms

也就是说减法循环比加法循环10亿次时快300毫秒，超过10%。

从C语言层面上分析，这两个代码几乎是一样的，我一开始也是楞了1分多钟，后来仔细比较两个代码，感觉它们的差别主要在两个地方，一个是加法和减法的差别，一个是for循环的第二个语句中一个是和立即数比较一个是和变量比较。以我掌握的计算机硬件原理知识，我首先排除了第一个差别造成性能影响的可能，那么问题很可能就出在第二个差别上，因为我知道在汇编语言中两个内存变量是不能直接比较的，中间必须要通过寄存器转储一次。这样就会多出至少一个指令。问题可能就在这里。为了验证我的判断，我们来看一下上面代码的汇编语句到底是什么样子的：

1: int main() 2: { 3: 00CC1000 push ebp 4: 00CC1001 mov ebp,esp 5: 00CC1003 sub esp,10h 6: 7: int count = 1000000000; 8: 00CC1006 mov dword ptr [count],3B9ACA00h 9: 10: 11: clock_t cl = clock (); 12: 00CC100D call dword ptr [__imp__clock (0CC209Ch)] 13: 00CC1013 mov dword ptr [cl],eax 14: 15: for(int i = count; i > 0 ; i--) 16: 00CC1016 mov eax,dword ptr [count] 17: 00CC1019 mov dword ptr [i],eax 18: 00CC101C jmp main+27h (0CC1027h) 19: 00CC101E mov ecx,dword ptr [i] //把i的内存值拷贝到寄存器ecx中 20: 00CC1021 sub ecx,1 //ecx 减1 21: 00CC1024 mov dword ptr [i],ecx //把ecx 的值拷贝到i对应的内存地址,这里完成i--操作 22: 00CC1027 cmp dword ptr [i],0 //i对应的内存值和0进行比较 23: 00CC102B jle main+2Fh (0CC102Fh) //如果小于等于0，跳转到98行 24: { 25: } 26: 00CC102D jmp main+1Eh (0CC101Eh)//如果大于0，跳转到19行，继续循环 27: 28: printf("Elapse %u ms", (clock () - cl)); 29: 00CC102F call dword ptr [__imp__clock (0CC209Ch)] 30: 00CC1035 sub eax,dword ptr [cl] 31: 00CC1038 push eax 32: 00CC1039 push offset ___xi_z+30h (0CC20F4h) 33: 00CC103E call dword ptr [__imp__printf (0CC20A4h)] 34: 00CC1044 add esp,8 35: 36: cl = clock (); 37: 00CC1047 call dword ptr [__imp__clock (0CC209Ch)] 38: 00CC104D mov dword ptr [cl],eax 39: 40: for(int i = 0; i < count ; i++) 41: 00CC1050 mov dword ptr [i],0 42: 00CC1057 jmp main+62h (0CC1062h) 43: 00CC1059 mov edx,dword ptr [i]//把i的内存值拷贝到寄存器edx中 44: 00CC105C add edx,1 //edx 加 1 45: 00CC105F mov dword ptr [i],edx //将edx的值拷贝到i变量对应地址 46: 00CC1062 mov eax,dword ptr [i] //将i变量值拷贝到寄存器eax中 47: 00CC1065 cmp eax,dword ptr [count] //用eax 和 count地址上的值进行比较 48: 00CC1068 jge main+6Ch (0CC106Ch)//如果大于等于count，跳出循环 49: { 50: } 51: 00CC106A jmp main+59h (0CC1059h)//否则跳转到43行继续循环

我把汇编语句中的循环部分用红色标记出来，并加上注释。我们可以清楚的看到第二个循环中的汇编指令为7个，第一个为6个，也就是说第一个要比第二个要快 1/7 左右，这个和实际测试出来的结果基本上是吻合的。

那么我们再看看为什么编译器要多一个机器指令。原因是汇编语句不可能对两个内存值直接比较，内存值只能和寄存器进行比较，这个应该是计算机硬件结构决定的，这个问题就导致编译器必须要加一个指令来转储内存值到寄存器中。

再进一步，我们发现编译器似乎很蠢，如果在循环之前把 dword ptr[count] 拷贝到一个寄存器中，比如 ecx ，然后在46 行直接 cmp ecx, dword ptr [i] ，就不需要第47行这个指令了。但事实上编译器可能并没有蠢到这个地步，本文前面说过，我将编译器的优化给禁用了，因为如果优化的话，上面两个for循环将被完全忽略掉，根本不会执行，测试出来的时间为0秒。那么既然我们告诉编译器不优化，编译器也就不会优化这个指令，如果真的按照上面方法优化了，那么在调试环境下，如果我们想在循环中更改 count 的值就比较困难了，需要调试器来做一些编译器要做的事情。

再深入一点，我们还会发现这个汇编语句中还有一个地方可以优化，就是

21: 00CC1024 mov dword ptr [i],ecx //把ecx 的值拷贝到i对应的内存地址,这里完成i--操作 22: 00CC1027 cmp dword ptr [i],0 //i对应的内存值和0进行比较

第22行这个地方完全可以优化为 cmp ecx, 0

我们知道对寄存器的读写是最快的，其次是一级缓存，二级缓存，三级缓存，然后才是内存，最后是磁盘。

如果22行优化为 cmp ecx, 0 其运行速度肯定要比 cmp dword ptr[i], 0 要快，因为后面的语句要进行一次寻址，从缓存中读取数据（如果CPU有缓存的话），如果没缓存，就是从内存读一次，那就更慢了。

最后我们把i++那个循环改成

for(int i = 0; i < 1000000000 ; i++) 再测一次，结果为

Elapse 2334 ms
Elapse 2290 ms

可以看出两个循环的用时基本上相等了

for(int i = 0; i < 1000000000 ; i++)
01201050 mov dword ptr [i],0
01201057 jmp main+62h (1201062h)
01201059 mov edx,dword ptr [i]
0120105C add edx,1
0120105F mov dword ptr [i],edx
01201062 cmp dword ptr [i],3B9ACA00h
01201069 jge main+6Dh (120106Dh)
{
}
0120106B jmp main+59h (1201059h)

看一下汇编语句，for 循环的第二句改成立即数比较后，汇编语句变成了6个指令了。所以用时也基本相同了。

结论：

i++ 和 i-- 性能是没有区别的，之所以我们感觉i--快，是因为在汇编层面上，i++ 那个循环中多了一个机器指令造成的。另外通过本文，我们也了解了一些关于汇编的指令优化的知识，希望对大家能有帮助。

微博： http://weibo.com/hubbledotnet

本文链接

多线程环境下调用 HttpWebRequest 并发连接限制

2012-05-18T00:54:00Z

.net 的 HttpWebRequest 或者 WebClient 在多线程情况下存在并发连接限制，这个限制在桌面操作系统如 windows xp , windows 7 下默认是2，在服务器操作系统上默认为10. 如果不修改这个并发连接限制，那么客户端同时可以建立的 http 连接数就只有2个或10个。对于一些诸如浏览器或网络蜘蛛的应用，2个或10个并发数量实在太少，大大影响应用的性能。之所以有这个并发连接限制，是因为 http 1.0 和 http 1.1 标准规定并发连接数最大为2. 不过目前主流的浏览器都已经不遵循这个规则了，但 .net framework 依然默认遵循这个规则。

很多文章说用异步方式访问 HttpWebRequest 可以提高并发性能，但我测试下来，如果不修改这个默认并发连接数，同步或异步方式访问性能都很不好。

调整这个默认并发连接限制的方法很简单

只要在程序中设置：

System.Net.ServicePointManager.DefaultConnectionLimit = 512;

这个值最好不要超过1024。

我们也可以在app.config 中对最大并发连接数进行设置，方法如下：

修改了这个设置后，并发性能明显提高，从原来每秒钟20次直接上升到每秒钟1000多次。

本文链接

HubbleDotNet+Mongodb 构建高性能搜索引擎--概述

2012-05-10T04:01:00Z

HubbleDotNet 从 1.2.3 版本以后开始在官方代码中支持和 Mongodb 对接，Mongodb 是10gen 公司开发的 no-sql 数据库，其读写性能比传统关系数据库要快很多，而且可以非常方便的分布式部署。HubbleDotNet 通过支持 Mongodb 也使其本身同时具备了 no-sql 的解决方案。本文将重点概述Hubble+Mongodb 的功能以及和hubble+sql , lucene.net 的一些性能测试对比。

Mongodb 的安装

在开始本文之前，我们简单介绍一下 Mongodb 在 windows 下的安装，其他操作系统下的安装也是类似的。

首先在这个链接 http://www.mongodb.org/downloads 找到对应操作系统的版本，下载下来后解压。我们假设解压到 C:\mongodb

我们在 c:\mongodb 下建立一个 data 目录和一个 log 目录。下面是目录结构：

然后我们在run 中运行 cmd ，然后执行 cd c:\mongodb\bin 进入mongodb可执行程序目录

接下来执行 mongod --dbpath ../data --logpath ../log/mongodb.log

完成上述步骤后，mongodb 的服务程序就启动了。

默认端口

如果要远程访问 mongodb ，我们需要在防火墙中将 mongodb 的默认端口打开，下面是 mongodb 相关服务的默认端口：

Standalone mongod : 27017
mongos : 27017
shard server (mongod --shardsvr) : 27018
config server (mongod --configsvr) : 27019
web stats page for mongod : add 1000 to port number (28017, by default)

安装为服务

上面说的命令行只是用于调试用的，如果要正式在服务器上部署，我们需要将 mongodb 安装为服务来运行。

在windows 下安装mongodb服务的命令行如下:

C:\mongodb\bin>mongod --dbpath c:\mongodb\data --logpath c:\mongodb\log\mongodb.log --logappend –install

这里我们需要注意下面两点：

命令行中的路径必须是绝对路径，如果输入相对路径，需要修改服务的启动路径，否则服务无法运行。
如果是在 windows 7 或者 windows 2008 server 操作系统下安装，必须以 administrator 方式运行 cmd 才行。

卸载服务

如果我们不想要mongodb 了，我们可以通过如下命令行卸载服务：

C:\mongodb\bin>mongod --remove

Hubble中mongodb 数据库适配器的连接字符串

在HubbleDotNet 中，没有采用 mongodb 默认的连接字符串来连接mongodb，而是用了标准的连接字符串来连接

无用户名和密码连接 mongodb

这个是mongodb没有设置用户名和密码时通过 hubbledotnet 连接mongodb 数据库适配器的连接字符串

Data Source=127.0.0.1;Initial Catalog=News;Integrated Security=True

我们只要指定服务器IP地址 Data Soruce 和数据库名 Initial Catalog 就可以了

通过用户名和密码连接 mongodb

这个是mongodb设置用户名和密码时通过 hubbledotnet 连接mongodb 数据库适配器的连接字符串

Data Source=127.0.0.1;Initial Catalog=News;User Id=myUsername;Password=myPassword;

HubbleDotNet+Mongodb 功能一览

支持标准的数据类型如 int, string, double,datetime 等
支持对mongodb的指定字符串字段进行全文索引和查询。mongodb 本身不支持全文查询，hubbledotnet 通过配置后可以支持对mongodb进行全文查询，查询语法和与其他数据库类型的语法相同。这个是hubble+mongodb 的核心功能。
支持主库为关系数据库，比如 sql server ，镜像表用 mongodb。这个是推荐方式，可以做到数据的读写分离和分布式部署。
支持 mongodb 作为主库的主动模式索引，这种模式对于实时索引将会比较有用
支持 mongodb 作为主库的被动模式索引。这种模式目前还不支持通过hubble来同步索引，需要自己写代码手工同步。原因是mongodb 不支持触发器。
支持通过 mongodb 实现数据的分布式部署
支持用SQL语句对mongodb进行非全文查询。如 select top 10 * from table where price > 100 and price < 200 order by price。这个是 hubbleDotNet 特有的功能。hubbledotnet 实现了一个sql 到 bson 的语法转换，调用者可以像访问sql server 那样来通过标准sql语句访问 mongodb ，这为不喜欢 bson 查询的开发者提供了很大的便利。
支持通过bson 语句访问或配置 mongodb。 hubbledotnet 提供了两个存储过程 sp_excutesql 和 sp_querysql 来方便用户通过hubble直接用 bson 操作mongodb
对不完整文档的支持。Mongodb 是文档型数据库，它并不强制每条记录的字段像关系数据库那样是固定不变的，可能每条记录的字段都不一样。HubbleDotNet 支持这种设计，对于在记录中没有出现的字段，作为NULL来处理，如果指定了默认值，则按默认值处理。
对 sub-field 的支持。mongodb 是文档型数据，支持子字段。hubble 将在后续版本中对子字段进行支持。

性能测试

测试环境：

软件版本

HubbleDotNet 版本 1.2.5.0

Mongodb 版本 2.0.5

SQL SERVER 2008

Lucene.net 2.9.4

系统环境

Intel i5 2430M 2.40GHz 8GB windows 7 64bit

7800 转机械硬盘

测试数据

测试数据为2000万行互联网网页数据。数据文件大小为4GB。

测试目标：

测试hubble+sqlserver, Hubble+Mongodb 以及 lucene.net 在单机系统高并发时的性能比较。

测试方法：

通过测试代码每秒钟查询10次，查询840个常用英文单词的搜索，返回前10条 title 和 content ，按匹配度排序

测试用例1：

在这个测试用例中，我们取消 hubbledotnet 所有的缓存，让 hubbledotnet 每次都从硬盘读索引，lucene.net 也设置为从文件读取。对840个英文单词的查询全部是首次查询。而且每次测试前重启计算机以清除操作系统的文件缓存。

测试结果如下：

	每秒钟查询次数	最大查询时间(ms)	平均查询时间(ms)	最小查询时间(ms)
Hubble+Mongodb	10	1573	431	3
Hubble+SQL SERVER	10	8997	931	4
Lucene.net	10	209196	108665	9430

从这个测试看冷启动情况下， hubbledotnet+mongodb 的性能是最佳的，而lucene.net 几乎比 hubbledotnet+mongodb 慢200多倍。lucene.net 比 hubbledotnet 慢这么多的原因主要是lucene.net 访问IO 的速度较慢，以及lucene.net 的索引大小比hubbledotnet 大4倍多。lucene.net 的索引大小是 3.6GB 而 hubbledotnet 只有 800MB 。HubbleDotNet 1.2.5.0 对于首次查询的磁盘IO做了一定的优化，也是 hubbledotnet 比 lucene.net 性能高这么的主要原因。

测试用例2：

在这个测试用例中，我们在 hubbledotnet 中指定RamIndex 为Full，即将索引全部加载到内存，lucene.net 也设置为内存索引。这个测试主要是测试内存索引的性能。

测试结果如下：

	每秒钟查询次数	最大查询时间(ms)	平均查询时间(ms)	最小查询时间(ms)	内存(MB)
Hubble+Mongodb	10	148	5.53	1	1,164
Hubble+SQL SERVER	10	157	6.17	0	1,170
Lucene.net	10	230	3.58	0	3,611

从这个测试结果看，平均查询时间上 lucene.net 要比 hubbledotnet 略快，最大查询时间上 hubbledotnet 比 lucene.net 快。平均查询时间 lucene.net 快的原因，我分析是这样的，lucene.net 是单进程运行，而 hubbledotnet 是3个进程互动，即测试进程，hubble 服务进程和 mongodb 进程（或 sql server 进程) 。三个进程互动时，每次查询都会触发进程的切换，这个过程会消耗一定的系统资源，特别是在查询时间为微妙级时，这个性能的损耗就会比较突出一些。不过这个查询速度无论对于那种环境来说都已经足够，从这个测试来看，如果要达到系统的满负荷，hubbledotnet 大概可以支持到每秒钟200次查询左右，相当于每天查询1600万次，这个对于单机系统性能已经非常高了，如果一个网站的访问量达到这么大，一半是需要考虑分布式解决方案了。

而最大查询时间hubble比lucene快将近1倍，这个基本反映出查询算法性能的优劣。这个和我的另外的测试结果(另文阐述)基本是吻合的，即按照score 排序，hubble 的查询速度大概是 lucene.net 的2倍，按其它字段排序，大概为5倍左右。

内存占用方法，Lucene.net 占用3.6GB内存，hubbledotnet占用 1.1 GB 内存，这个主要是因为 hubbledotnet 的索引比 lucene.net 要小的缘故。HubbleDotNet 的内存占用还可以优化，优化后对于本例来说应该可以减少到800MB 左右。

持久化方面，hubbledotnet的内存索引是可以自动持久化的，就是说运行过程中的增删改的变化会自动存储到文件介质中，并更新到内存中，这样即使机器重启也不会丢失数据。lucene.net 的内存索引方案是无法自动持久化的，需要另外写程序持久化。

HubbleDotNet 首页： http://hubbledotnet.codeplex.com/

HubbleDotNet开源全文搜索数据库项目--技术详解

HubbleDotNet 微博： http://weibo.com/hubbledotnet

本文链接

C# 重启计算机的问题

2012-04-13T05:54:00Z

C# 程序重启计算机的方法很多，网上也有不少这方面的文章，不过很多网上提供的方法在某些情况下无法获取重启计算机的权限导致重启失败。本文对这些方法做一些简单的讨论。

作者:eaglet

网上介绍最多的两种方法分别是：

System.Diagnostics.Process.Start("shutdown",@"/r");

和

[DllImport("user32.dll")]
static extern bool ExitWindowsEx(ExitWindows uFlags, ShutdownReason dwReason);

[STAThread]
static void Main(string[] args)
{
ExitWindowsEx(ExitWindows.LogOff, ShutdownReason.MajorOther & ShutdownReason.MinorOther);
//这个语句将实现计算机注销操作
}

这两种方法在通常情况下工作是没有问题的，但在某些特殊情况下，比如桌面被其它用户锁定时就无法重启计算机。本人在实际工作中遇到过当当前屏幕被远程控制软件锁定后，我做的后台守护进程试图重启计算机,结果用上述两种方法都无法成功。分析原因，应该是远程控制软件用另外的帐号锁定了屏幕（通常应该是windows service 或者 network service)，这时守护进程用当前帐号重启计算机就因为没有权限而失败。

要解决这个问题，我们必须要给进程赋予足够的权限才行，于是我在调用 ExitWindowsEx 前运行了如下代码来赋予当前进程关闭计算机权限

//give current process SeShutdownPrivilege TokPriv1Luid tp; IntPtr hproc = GetCurrentProcess(); IntPtr htok = IntPtr.Zero; if (!OpenProcessToken(hproc, TOKEN_ADJUST_PRIVILEGES | TOKEN_QUERY, ref htok)) { throw new Exception("Open Process Token fail"); } tp.Count = 1; tp.Luid = 0; tp.Attr = SE_PRIVILEGE_ENABLED; if (!LookupPrivilegeValue(null, SE_SHUTDOWN_NAME, ref tp.Luid)) { throw new Exception("Lookup Privilege Value fail"); } if (!AdjustTokenPrivileges(htok, false, ref tp, 0, IntPtr.Zero, IntPtr.Zero)) { throw new Exception("Adjust Token Privileges fail"); }

上面代码为当前进程赋予了关闭计算机的权限。这里需要注意的是上述代码要执行成功同样需要足够的权限，通常当前进程需要以拥有至少是系统管理员权限的账户运行。如果没有足够权限，需要用程序模拟系统管理员权限，模拟其它帐号权限的问题不在本文讨论范围内。

加上如上代码后，在其他用户锁定机器后，重启计算机成功。

下面给出完整代码

using System;using System.Collections.Generic;using System.Text;using System.Runtime.InteropServices;using System.Threading; public class ExitWindows{ #region win32 api [StructLayout(LayoutKind.Sequential, Pack = 1)] private struct TokPriv1Luid { public int Count; public long Luid; public int Attr; } [DllImport("kernel32.dll", ExactSpelling = true)] private static extern IntPtr GetCurrentProcess(); [DllImport("advapi32.dll", ExactSpelling = true, SetLastError = true)] private static extern bool OpenProcessToken(IntPtr h, int acc, ref IntPtr phtok); [DllImport("advapi32.dll", SetLastError = true)] private static extern bool LookupPrivilegeValue(string host, string name, ref long pluid); [DllImport("advapi32.dll", ExactSpelling = true, SetLastError = true)] private static extern bool AdjustTokenPrivileges(IntPtr htok, bool disall, ref TokPriv1Luid newst, int len, IntPtr prev, IntPtr relen); [DllImport("user32.dll", ExactSpelling = true, SetLastError = true)] private static extern bool ExitWindowsEx(int flg, int rea); #endregion private const int SE_PRIVILEGE_ENABLED = 0x00000002; private const int TOKEN_QUERY = 0x00000008; private const int TOKEN_ADJUST_PRIVILEGES = 0x00000020; private const string SE_SHUTDOWN_NAME = "SeShutdownPrivilege"; #region Exit Windows Flags private const int EWX_LOGOFF = 0x00000000; private const int EWX_SHUTDOWN = 0x00000001; private const int EWX_REBOOT = 0x00000002; private const int EWX_FORCE = 0x00000004; private const int EWX_POWEROFF = 0x00000008; private const int EWX_FORCEIFHUNG = 0x00000010; #endregion public static void DoExitWin(int flg) { //give current process SeShutdownPrivilege TokPriv1Luid tp; IntPtr hproc = GetCurrentProcess(); IntPtr htok = IntPtr.Zero; if (!OpenProcessToken(hproc, TOKEN_ADJUST_PRIVILEGES | TOKEN_QUERY, ref htok)) { throw new Exception("Open Process Token fail"); } tp.Count = 1; tp.Luid = 0; tp.Attr = SE_PRIVILEGE_ENABLED; if (!LookupPrivilegeValue(null, SE_SHUTDOWN_NAME, ref tp.Luid)) { throw new Exception("Lookup Privilege Value fail"); } if (!AdjustTokenPrivileges(htok, false, ref tp, 0, IntPtr.Zero, IntPtr.Zero)) { throw new Exception("Adjust Token Privileges fail"); } //Exit windows if (!ExitWindowsEx(flg, 0)) { throw new Exception("Exit Windows fail"); } } /// <summary> /// Reboot computer /// </summary> /// <param name="force">force reboot</param> public static void Reboot(bool force) { if (force) { DoExitWin(EWX_REBOOT | EWX_FORCE); } else { DoExitWin(EWX_REBOOT | EWX_FORCEIFHUNG); } } /// <summary> /// Reboot computer force if hung /// </summary> public static void Reboot() { Reboot(false); } /// <summary> /// Shut down computer /// </summary> /// <param name="force">force shut down</param> public static void Shutdown(bool force) { if (force) { DoExitWin(EWX_SHUTDOWN | EWX_FORCE); } else { DoExitWin(EWX_SHUTDOWN | EWX_FORCEIFHUNG); } } /// <summary> /// Shut down computer force if hung /// </summary> public static void Shutdown() { Shutdown(false); } /// <summary> /// Log off /// </summary> /// <param name="force">force logoff</param> public static void Logoff(bool force) { if (force) { DoExitWin(EWX_LOGOFF | EWX_FORCE); } else { DoExitWin(EWX_LOGOFF | EWX_FORCEIFHUNG); } } /// <summary> /// logoff computer force if hung /// </summary> public static void Logoff() { Logoff(false); }}

本文链接

HubbleDotNet 索引分词的测试方法和分词技巧

2012-02-15T01:27:00Z

在中文搜索中，分词技术是一个比较关键的技术，我们往往会遇到查询某个关键字无法匹配到相应文档的问题，这种问题往往都是索引的分词不理想造成的，倒排索引的技术特点决定了如果查询的关键字不在索引的分词中，则无法查出相应的文档。为了帮助使用者分析分词问题，hubbledotnet 专门提供几个存储过程来帮助检查索引分词的情况。

分词的测试方法

首先要找到要测试的原始文本

我们往往发现某些记录包含有查询关键字，但查不出来，这个时候我们需要先找到这个出问题的记录的原始文本。查找原始文本的方法很多，你可以通过 docid 或者id 或者其他条件来查找。

下面给出一个通过 id 来查找的示例。如果我们发现id = 1 的记录 title 无法匹配出来，我们可以执行

select * from table where id = 1 找到记录的原始文本。

找到原始文本后我们有两种方法来查看记录在索引中的分词情况。

方法1： SP_TestAnalyzer

SP_TestAnalyzer 这个存储过程用于测试分词器的分词结果，它的作用是在服务器侧执行分词器的 Tokenize 方法。

这个存储过程有两个参数，第一个参数为分词器名字，这里我们输入 ‘PanguSegment’，第二个参数是要测试的句子。

下面我们执行如下语句，看看效果SP_TestAnalyzer 'PanguSegment', '六方会谈无核化工作组会议将在沈阳召开'

如上图所示，执行后，可以看到分词的结果。从这个分词结果可以看到原始文本的分词有一些问题，比如无核化和工作组这两个词没有分出来，这时如果搜索”工作组”这个词，则无法匹配到这条记录。我们需要把无核化和工作组两个词加入到盘古的字典中再测试，如果分词正确了，重新索引后，问题就可以解决。

方法2：SP_FieldAnalyze

SP_FieldAnalyze 这个存储过程是针对指定表的指定字段的分词器来分词

它有4个参数，参数1为表名，参数2为字段名，参数3为要分词的句子，参数4指定是用 Tokenize 函数还是 TokenizedForSqlClient 函数来分词。第4个参数为可选参数，

如果不输入，就是以 Tokenize 函数分词，如果输入 ‘SqlClient’ 就是以 TokenizedForSqlClient 函数来分词

下面我们首先执行默认的情况，即用 Tokenize 函数分词SP_FieldAnalyze 'VNews', 'Title', '六方会谈无核化工作组会议将在沈阳召开'这个语句是采用 VNews 表的 Title 字段的分词器来对 '六方会谈无核化工作组会议将在沈阳召开' 这个句子进行分词，我们可以看出，分词的结果和方法1是一样的。

我们加上 SqlClient 参数后来分词看看效果：SP_FieldAnalyze 'VNews', 'Title', '六方会谈无核化工作组会议将在沈阳召开','SqlClient'

可以看到后面加了 SqlClient 后，分词结果不同了，这是因为 SqlClient 采用了不同的分词参数。对于盘古分词来说，如果调用 SqlClient 来分词，则服务器侧调用的是program/hubbledotnet/default/PanGuSqlClient.xml 这个配置文件来对文本进行分词，如果不加 SqlClient 参数，则是调用program/hubbledotnet/default/PanGu.xml 这个配置文件分词。

SqlClient 的功能主要是帮助进行查询字符串的分词，HubbleCommand 这个类中有一个函数 GetKeywordAnalyzerStringFromServer 就是用于对查询字符串进行分词的，hubble 的示例代码中也是调用的这个函数，这个函数的里面实际上就是调用 SP_FieldAnalyze 这个存储过程加 SqlClient 来分词。当然在实际项目中，使用着并不是必须要调用这个函数来对查询字符串进行分词，使用者可以用自己的程序对查询字符串分词。

分词的技巧

对于搜索来说，查全率和查准率是一对矛盾，为了尽量平衡这对矛盾，我们在索引和查询时可以采用一些技巧。

技巧1.

索引时最大化分词，如果是用盘古分词进行索引，索引时打开多元分词和强制一元分词。但对查询字符串的分词则采用精确分词，这样可以保证查准的情况下获得较大的查全率。

技巧2.

同义词分词。对于同义词的分词，我们不要在索引中分词，而是在查询字符串中增加同义词的分解，这样可以使查询更灵活，并且可以在查询时设置原词和同义词不同的权重以影响得分排名。

技巧3.

全部一元分词，然后通过索引组件来实现匹配，类似 like ‘%xxx%’ 这样的功能。由于索引组件知道单词在原文本中的位置，所以理论上可以实现类似 like ‘%xxx%’ 这样的功能，这种功能对于短文本的搜索比较有效，而且不需要关心中文的分词。hubbledotnet 将在未来的版本中提供这种方式的快速解决方案，目前版本提供了 like ‘*xxx*’ 的功能，但这个功能还不够完善，速度比较慢。

注意事项

索引分词的检查功能，实际上只是在server 端执行了对应的分词器来进行分词，并不是从倒排索引中查询出对应文本的分词结果。从倒排索引中获取分词结果需要遍历整个倒排索引，效率很低，所以hubble 没有提供这样的功能。由于是动态执行分词器分词，如果在索引过程中分词参数或字典调整过，则得到的结果有可能不是实际索引中的分词结果。

返回 Hubble.net 技术详解

本文链接

Windows 启动顺序详解

2012-02-14T02:22:00Z

本文详细阐述 windows 操作系统的启动顺序，以方便IT从业者对windows 启动问题的分析和解决。

windows 的启动过程包括以下几个阶段：

启动自检阶段

这个阶段主要是读取 BIOS ，然后内存，CPU，硬盘，键盘等设备进行自检。这个阶段在屏幕上显示就是自检的那些打印信息。

屏幕显示：自检的打印信息

初始化启动阶段

这个阶段根据 BIOS 指定的启动顺序，找到可以启动的优先启动设备，比如本地磁盘，CD Driver ， USB 设备等等，然后准备从这些设备启动系统。

屏幕显示：黑屏

Boot 加载阶段

这个阶段首先从启动分区(比如 C 盘) 加载 Ntldr ，然后Ntldr 做如下设置：

设置内存模式，如果是 x86 的处理器，并且操作系统是 32位，则设置为 32-bit flat memory mode, 如果是 64 位操作系统 + 64位处理器，则设置为64位内存模式。
启动文件系统
读取 boot.ini 文件

屏幕显示：黑屏，如果按F8或者多系统时会显示启动选项菜单。

检测和配置硬件阶段

这个阶段检查和配置一些硬件设备，它们分别是：

系统固件，比如时间和日期
总线和适配器
显示适配器
键盘
通讯端口
磁盘
软盘
输入设备（如鼠标)
并口
在ISA总线上运行的设备

屏幕显示：黑屏

内核加载阶段

在内核加载阶段，Ntldr 将首先加载windows 内核 Ntoskrnl.exe 和硬件抽象层 (HAL). HAL 有点类似于嵌入式操作系统下的BSP（Borad support package)，这个抽象层对硬件底层的特性进行隔离，对操作系统提供统一的调用接口，操作系统移植到不同硬件时只要改变相应的 HAL 就可以，其它的内核组件不需要修改，这个是操作系统通常的设计模式。

接下来Ntldr 从HKEY_LOCAL_ MACHINE\SYSTEM\CurrentControlSet 下读取这台机器安装的驱动程序，然后依次加载驱动程序。

驱动程序加载完成后，windows 做如下设置：

1. 创建系统环境变量

2. 启动 win32.sys ，这个是windows 子系统的内核模式部分。

3. 启动 csrss.exe，这个是windows 子系统的用户模式部分。

4. 启动 winlogon.exe

5. 创建虚拟内存页面文件

6. 对一些必要的文件进行改名，（主要是驱动文件，如果更新后，需要在下次重启前改名)

屏幕显示：显示windows logo 界面和进度条

登录阶段

这个阶段会做如下几件事：

1. 启动机器上安装的所有需要自动启动的 windows 服务

2. 启动本地安全认证 Lsass.exe

3. 显示登录界面

屏幕显示：显示登录界面

本文参考如下文档：

Troubleshooting the Startup Process

本文链接

记录windows操作系统启动日志

2012-02-12T23:04:00Z

在一些基于windows的设备中，我们希望在程序控制windows重启时，windows每次都能正常启动，但有时候windows会遇到种种原因无法启动，这时我们需要定位到底是在启动什么步骤时出错，为了定位故障原因，我们需要将windows 的启动日志记录下来。

记录启动日志的方式是

在 boot.ini 中加一个 /bootlog 的参数，加了这个参数后，机器重启后，会自动把启动的日志记录在 c:\windows 目录下的 ntbtlog.txt 文件中。通过查看这个日志文件，我们可以了解windows启动过程中的一些详细情况。

下面列出boot.ini 的所有参数：

转自：Windows XP 和 Windows Server 2003 的 Boot.ini 文件的可用开关选项

/basevideo

/basevideo 开关通过使用与所有视频适配器都兼容的视频驱动程序来强制系统进入标准 640x480 16 色 VGA 模式。该开关允许您在选择了错误的视频分辨率或刷新频率时加载系统。请将该开关与 /sos 开关一起使用。如果安装了新的视频驱动程序，而该驱动程序工作不正常，则可使用该参数来启动操作系统。然后可以删除、更新或回滚到有问题的视频驱动程序。

博客园_eaglet

获取ALL USER 的特殊目录的类

i—比 i++ 快？

多线程环境下调用 HttpWebRequest 并发连接限制

HubbleDotNet+Mongodb 构建高性能搜索引擎--概述

C# 重启计算机的问题

HubbleDotNet 索引分词的测试方法和分词技巧

Windows 启动顺序详解

记录windows操作系统启动日志

C# 程序自动批量生成 google maps 的KML文件

通过 Windows 7 共享上网