2010-03-13 13:53:41 WDK驱动开发与VS2008开发环境整合

分类:(关于我们) | 评论:(2) | 浏览:(408)

一、下载与安装WDK

《寒》说，以前说的DDK、IFS已成为历史，现在已经改为使用WDK了，具体下载地址可以这里注册并下载：http://connect.microsoft.com，目前的版本是6001.18002，大小只有577MB。

下载安装后，假设安装路径为“c:\winddk”，接下来要设计环境变量，添加：BASEDIR，值为：“c:\winddk\6001”。必须设置此环境变量，否则下面编译时会出问题。

二、Visual Studio的开发环境

笔者用的是Visual Studio 2005，所以就以此版本介绍，其他版本的类似。

首先新建项目，类型选择Visual C++->General中的“Makefile Project”，这里的项目保存路径不要包括空格、中文等字符，否则会造成后面编译时的出错。

下一步，在Debug Configuration Settings中设置如下：

Build command line: ddk_build chk wxp

Clean commands: ddk_clean chk wxp

Rebuild command line: ddk_build chk wxp /a

Output: first.sys

如图：

下一步，在Release Configuration Settings中与Debug的一样，只是把“chk”改为“fre”即可，如下图：

接下来设置工程属性，在All Configurations中，Configuration Properties->NMake->Include Search Path中添加路径：

C:\WinDDK\6000\inc\ddk;C:\WinDDK\6000\inc\api

接下来添加源代码文件，举个例子：

first.c

#include <ntddk.h>

VOID DriverUnload(PDRIVER_OBJECT driver)
{
DbgPrint("Driver unloading...\n");
}

NTSTATUS DriverEntry(PDRIVER_OBJECT driver, PUNICODE_STRING reg_path)
{
DbgPrint("Entered Driver Entry!\n");

driver->DriverUnload = DriverUnload;
return STATUS_SUCCESS;
}

现在可以发现在VS中可以使用VS开发环境带来的强大功能，如查看PDRIVER_OBJECT的定义、查看某变量的成员函数（Ctrl+J)等等。

接下来要为编译作准备，添加以下这些文件：

makefile

!IF 0

Module Name:

makefile.

Notes:

    DO NOT EDIT THIS FILE!!! Edit .\sources. if you want to add a new source
    file to this component. This file merely indirects to the real make file
    that is shared by all the components of Windows NT (DDK)

!ENDIF

!INCLUDE $(NTMAKEENV)\makefile.def

sources

TARGETNAME=first
TARGETTYPE=DRIVER
TARGETPATH=obj

SOURCES=first.c

ddk_build.bat

@echo on
@echo %1 is chk or fre %2 is WXP or W2K or WNET.

if "%4"=="/a" call ddk_clean %1 %2

pushd.
call %BASEDIR%\bin\setenv.bat %BASEDIR% %1 %2
popd

@echo on
build

ddk_clean.bat

if exist Debug rd /s /q Debug
if exist Release rd /s /q Release
if exist obj%1_%2_x86 rd /s /q obj%1_%2_x86

现在，按F7就可以编译连接了。

以上就是搭建VS的内核开发环境过程。

三、调试环境

使用到的工具是：VMware、WinDbg、srvinstw.exe等。

标签: 驱动开发阅读更多...

2010-03-02 17:03:56 问答系统的模型图

分类:(关于我们) | 评论:(0) | 浏览:(66)

标签:

2010-02-21 09:47:50 Web2.0架构下散列实现数据库负载均衡

分类:(技术研究) | 评论:(0) | 浏览:(129)

在Web 2.0时代，网站将会经常面临着快速增加的访问量，但是我们的应用如何满足用户的访问需求，而且基本上我们看到的情况都是性能瓶颈都是在数据库上，这个不怪数据库，毕竟要满足很大访问量确实对于任何一款数据库都是很大的压力，不论是商业数据库Oracle、MS sql Server、DB2之类，还是开源的MySQL、PostgreSQL，都是很大的挑战，解决的方法很简单，就是把数据分散在不同的数据库上（可以是硬件上的，也可以是逻辑上的），本文就是主要讨论如何数据库分散存储的的问题。

目前主要分布存储的方式都是按照一定的方式进行切分，主要是垂直切分（纵向）和水平切分（横向）两种方式，当然，也有两种结合的方式，达到更贴切的切分粒度。

1. 垂直切分（纵向）数据是数据库切分按照网站业务、产品进行切分，比如用户数据、博客文章数据、照片数据、标签数据、群组数据等等每个业务一个独立的数据库或者数据库服务器。

2. 水平切分（横向）数据是把所有数据当作一个大产品，但是把所有的平面数据按照某些Key（比如用户名）分散在不同数据库或者数据库服务器上，分散对数据访问的压力，这种方式也是本文主要要探讨的。

本文主要针对的的 MySQL/PostgreSQL 类的开源数据库，同时平台是在 linux/FreeBSD，使用 php/Perl/Ruby/Python 等脚本语言，搭配 Apache/Lighttpd 等Web服务器的平台下面的Web应用，不讨论静态文件的存储，比如视频、图片、CSS、JS，那是另外一个话题。

说明：下面将会反复提到的一个名次“节点”（Node），指的是一个数据库节点，可能是物理的一台数据库服务器，也可能是一个数据库，一般情况是指一台数据库服务器，并且是具有 Master/Slave 结构的数据库服务器，我们查看一下图片，了解这样节点的架构：

一、基于散列的分布方式

1. 散列方式介绍

基于散列（Hash）的分布存储方式，主要是依赖主要Key和散列算法，比如以用户为主的应用主要的角色就是用户，那么做Key的就可以是用户ID 或者是用户名、邮件地址之类（该值必须在站点中随处传递），使用这个唯一值作为Key，通过对这个Key进行散列算法，把不同的用户数据分散在不同的数据库节点（Node）上。

我们通过简单的实例来描述这个问题：比如有一个应用，Key是用户ID，拥有10个数据库节点，最简单的散列算法是我们用户ID数模以我们所有节点数，余数就是对应的节点机器，算法：所在节点 = 用户ID % 总节点数，那么，用户ID为125的用户所在节点：125 % 10 = 5，那么应该在名字为5的节点上。同样的，可以构造更为强大合理的Hash算法来更均匀的分配用户到不同的节点上。

2. 散列分布存储方式的扩容

我们知道既然定义了一个散列算法，那么这些Key就会按部就班的分散到指定节点上，但是如果目前的所有节点不够满足要求怎么办？这就存在一个扩容的问题，扩容首当其冲的就是要修改散列算法，同时数据也要根据散列算法进修迁移或者修改。

(1) 迁移方式扩容：修改散列算法以后，比如之前是10个节点，现在增加到20个节点，那么Hash算法就是[模20]，相应的存在一个以前的节点被分配的数据会比较多，但是新加入的节点数据少的不平衡的状态，那么可以考虑使用把以前数据中的数据按照Key使用新的Hash算法进行运算出新节点，把数据迁移到新节点，缺点但是这个成本相应比较大，不稳定性增加；好处是数据比较均匀，并且能够充分利用新旧节点。

(2) 充分利用新节点：增加新节点以后，Hash算法把新加入的数据全部Hash到新节点上，不再往旧节点上分配数据，这样不存在迁移数据的成本。优点是只需要修改Hash算法，无须迁移数据就能够简单的增加节点，但是在查询数据的时候，必须使用考虑到旧Key使用旧Hash算法，新增加的Key使用新的Hash算法，不然无法查找到数据所在节点。缺点很明显，一个是Hash算法复杂度增加，如果频繁的增加新节点，算法将非常复杂，无法维护，另外一个方面是旧节点无法充分利用资源了，因为旧节点只是单纯的保留旧Key数据，当然了，这个也有合适的解决方案。

总结来说，散列方式分布数据，要新增节点比较困难和繁琐，但是也有很多适合的场合，特别适合能够预计到未来数据量大小的应用，但是普遍 Web2.0 网站都无法预计到数据量。

二、基于全局节点分配方式

1. 全局节点分配方式介绍

就是把所有Key信息与数据库节点之间的映射关系记录下来，保存到全局表中，当需要访问某个节点的时候，首先去全局表中查找，找到以后再定位到相应节点。全局表的存储方式一般两种：

(1) 采用节点数据库本身（MySQL/PostgreSQL）存储节点信息，能够远程访问，为了保证性能，同时配合使用 Heap(MEMORY) 内存表，或者是使用 Memcached 缓存方式来缓存，加速节点查找

(2) 采用 BDB(BerkeleyDB)、DBM/GDBM/NDBM 这类本地文件数据库，基于 key=>value 哈希数据库，查找性能比较高，同时结合 APC、Memcached 之类的缓存加速。

第一种存储方式是容易查询（包括远程查询），缺点是性能不太好（这个是所有关系型数据库的通病）；第二种方式的有点是本地查询速度很快（特别是hash型数据库，时间复杂度是O(1)，比较快），缺点是无法远程使用，并且无法在多台机器中间同步共享数据，存在数据一致的情况。

我们来描述实施大概结构：假如我们有10个数据库节点，一个全局数据库用于存储Key到节点的映射信息，假设全局数据库有一个表叫做 AllNode ，包含两个字段，Key 和 NodeID，假设我们继续按照上面的案例，用户ID是Key，并且有一个用户ID为125的用户，它对应的节点，我们查询表获得：

Key NodeID
13 2
148 5
22 9
125 6

可以确认这个用户ID为125的用户，所在的节点是6，那么就可以迅速定位到该节点，进行数据的处理。

我们来查看一下分布存储结构图：

2. 全局节点分布方式的扩容

全局节点分配方式同样存在扩容的问题，不过它早就考虑到这个问题，并且这么设计就是为了便于扩容，主要的扩容方式是两种：

(1) 通过节点自然增加来分配Key到节点的映射扩容

这种是最典型、最简单、最节约机器资源的扩容方式，大致就是按照每个节点分配指定的数据量，比如一个节点存储10万用户数据，第一个节点存储0-10w用户数据，第二个节点存储10w-20w用户数据，第三个节点存储20w-30w用户信息，依此类推，用户增加到一定数据量就增加节点服务器，同时把Key分配到新增加的节点上，映射关系记录到全局表中，这样可以无限的增加节点。存在的问题是，如果早期的节点用户访问频率比较低，而后期增加的节点用户访问频率比较高，则存在节点服务器负载不均衡的现象，这个也是可以想方案解决的。

(2) 通过概率算法来映射Key到节点的的扩容

这种方式是在既然有的节点基础上，给每个节点设定一个被分配到Key的概率，然后分配Key的时候，按照每个节点被指定的概率进行分配，如果每个节点平均的数据容量超过了指定的百分比，比如50%，那么这时候就考虑增加新节点，那么新节点增加Key的概率要大于旧节点。

一般情况下，对于节点的被分配的概率也是记录在数据库中的，比如我们把所有的概率为100，共有10个节点，那么设定每个节点被分配的数据的概率为10，我们查看数据表结构：

NodeID Weight
1 10
2 10
3 10

现在新加入了一个节点，新加入的节点，被分配Key的几率要大于旧节点，那么就必须对这个新加入的节点进行概率计算，计算公式：10х+у=100, у>х，得出：у{10...90}，х{1...9}，x是单个旧节点的概率，旧节点的每个节点的概率是一样的，y是新节点的概率，按照这个计算公式，推算出新节点y的概率的范围，具体按照具体不同应用的概率公式进行计算。

三、存在的问题

现在我们来分析和解决一下我们上面两种分布存储方式的存在的问题，便于在实际考虑架构的时候能够避免或者是融合一些问题和缺点。

1. 散列和全局分配方式都存在问题

(1) 散列方式扩容不是很方便，必须修改散列算法，同时可能还需要对数据进行迁移，它的优点是从Key定位一个节点非常快，O(1)的时间复杂度，而且基本不需要查询数据库，节约响应时间。

(2) 全局分配方式存在的问题最明显的是单点故障，全局数据库down掉将影响所有应用。另外一个问题是查询量大，对每个Key节点的操作都必须经过全局数据库，压力很大，优点是扩容方便，增加节点简单。

2. 分布存储带来的搜索和统计问题

(1) 一般搜索或统计都是对所有数据进行处理，但因为拆分以后，数据分散在不同节点机器上，无法进行全局查找和统计。解决方案一是对主要的基础数据存储在全局表中，便于查找和统计，但这类数据不宜太多，部分核心数据。

(2) 采用站内搜索引擎来索引和记录全部数据，比如采用 Lucene 等开源索引系统进行所有数据的索引，便于搜索。对于统计操作可以采用后台非实时统计，可采用遍历所有节点的方式，但效率低下。

3. 性能优化问题

(1) 散列算法，节点概率和分配等为了提高性能都可以使用编译语言开发，做成lib或者是所有php扩展形式。

(2) 对于采用 MySQL 的情况，可以采用自定义的数据库连接池，采用 Apache Module 形式加载，能够自由定制的采用各种连接方式。

(3) 对于全局数据或都频繁访问的数据，可以采用APC、Memcache、DBM、BDB、共享内存、文件系统等各种方式进行缓存，减少数据库的访问压力。

(4) 采用数据本身的强大处理机制，比如 MySQL5 的表分区或者是 MySQL5 的Cluster 。另外建议在实际架构中采用InnoDB表引擎作为主要存储引擎，MyISAM作为一些日志、统计数据等场合，不论在安全、可靠性、速度都有保障。

标签: Web2.0 HASH 数据库

2010-01-25 13:10:55 Crawler对页面评分的标准

分类:(关于我们) | 评论:(0) | 浏览:(123)

页面元素	评分
内部链接文字	10
<head>内的<title>元素	10
域名	7
<h1> <h2>标题	5
每段首句	5
路径与文件名	4
相似度	4
每句开头	1.5
加粗与斜体	1
文本内容	1
Title属性	1
图片的alt属性	0.5
Meta description属性	0.5
Meta keywords属性	0.05

标签: SEO

2010-01-25 11:42:43 利用客户端缓存对网站进行优化

分类:(关于我们) | 评论:(0) | 浏览:(77)

你的网站在并发访问很大并且无法承受压力的情况下,你会选择如何优化?
很多人首先会想从服务器缓存方面着手对程序进行优化,许多不同的服务器缓存方式都有他们自己的特点,像我曾经参与的一些项目中,根据缓存的命中率不同使用过 Com+/Enterprise Libiary Caching/Windows服务,静态文件等方式的服务器端缓存和 HTTP Compression技术,但客户端缓存往往却被人们忽略了,即使服务器的缓存让你的页面访问起来非常地快,但她依然需要依赖浏览器下载并输出,而当你加入客户端缓存时,会给你带来非常多的好处.因为她可以对站点中访问最频繁的页进行缓存充分地提高 Web 服务器的吞吐量（通常以每秒的请求数计算）以提升应用程序性能和可伸缩性。
一个在线购物调查显示，大多数人愿意去商店排队，但在在线购物时却不愿意等待。Websense调查公司称多达70%的上网者表示不愿意在页面读取上超过10秒钟。超过70%的人会因为中途速度过慢而取消当前的订单。

基础知识

        1) 什么是”Last-Modified”?

        在浏览器第一次请求某一个URL时，服务器端的返回状态会是200，内容是你请求的资源，同时有一个Last-Modified的属性标记此文件在服务期端最后被修改的时间，格式类似这样：

        Last-Modified: Fri, 12 May 2006 18:53:33 GMT

        客户端第二次请求此URL时，根据 HTTP 协议的规定，浏览器会向服务器传送 If-Modified-Since 报头，询问该时间之后文件是否有被修改过：

        If-Modified-Since: Fri, 12 May 2006 18:53:33 GMT

        如果服务器端的资源没有变化，则自动返回 HTTP 304 （Not Changed.）状态码，内容为空，这样就节省了传输数据量。当服务器端代码发生改变或者重启服务器时，则重新发出资源，返回和第一次请求时类似。从而保证不向客户端重复发出资源，也保证当服务器有变化时，客户端能够得到最新的资源。

        2) 什么是”Etag”?

        HTTP 协议规格说明定义ETag为“被请求变量的实体值” 。另一种说法是，ETag是一个可以与Web资源关联的记号（token）。典型的Web资源可以一个Web页，但也可能是JSON或XML文档。服务器单独负责判断记号是什么及其含义，并在HTTP响应头中将其传送到客户端，以下是服务器端返回的格式：

        ETag: "50b1c1d4f775c61:df3"

        客户端的查询更新格式是这样的：

        If-None-Match: W/"50b1c1d4f775c61:df3"

        如果ETag没改变，则返回状态304然后不返回，这也和Last-Modified一样。本人测试Etag主要在断点下载时比较有用。

Last-Modified和Etags如何帮助提高性能?

        聪明的开发者会把Last-Modified 和ETags请求的http报头一起使用，这样可利用客户端（例如浏览器）的缓存。因为服务器首先产生 Last-Modified/Etag标记，服务器可在稍后使用它来判断页面是否已经被修改。本质上，客户端通过将该记号传回服务器要求服务器验证其（客户端）缓存。
        过程如下:
                1. 客户端请求一个页面（A）。
                2. 服务器返回页面A，并在给A加上一个Last-Modified/ETag。
                3. 客户端展现该页面，并将页面连同Last-Modified/ETag一起缓存。
                4. 客户再次请求页面A，并将上次请求时服务器返回的Last-Modified/ETag一起传递给服务器。
                5. 服务器检查该Last-Modified或ETag，并判断出该页面自上次客户端请求之后还未被修改，直接返回响应304和一个空的响应体。

示例代码

下面的例子描述如何使用服务器端代码去操作客户端缓存:

1 //默认缓存的秒数
2 int secondsTime = 100;
3
4 //判断最后修改时间是否在要求的时间内
5 //如果服务器端的文件没有被修改过，则返回状态是304，内容为空，这样就节省了传输数据量。如果服务器端的文件被修改过，则返回和第一次请求时类似。
6 if (request.Headers["If-Modified-Since"] != null && TimeSpan.FromTicks(DateTime.Now.Ticks - DateTime.Parse(request.Headers["If-Modified-Since"]).Ticks).Seconds < secondsTime)
7 {
8     //测试代码,在这里会发现,当浏览器返回304状态时,下面的日期并不会输出
9     Response.Write(DateTime.Now);
10
11     response.StatusCode = 304;
12     response.Headers.Add("Content-Encoding", "gzip");
13     response.StatusDescription = "Not Modified";
14 }
15 else
16 {
17     //输出当前时间
18     Response.Write(DateTime.Now);
19
20     //设置客户端缓存状态
21     SetClientCaching(response, DateTime.Now);
22 }
23
24 #region SetClientCaching

..
25 /// <summary>
26 /// 设置客户端缓存状态
27 /// </summary>
28 /// <param name="response"></param>
29 /// <param name="lastModified"></param>
30 private void SetClientCaching(HttpResponse response, DateTime lastModified)
31 {
32     response.Cache.SetETag(lastModified.Ticks.ToString());
33     response.Cache.SetLastModified(lastModified);
34     //public 以指定响应能由客户端和共享（代理）缓存进行缓存。
35     response.Cache.SetCacheability(HttpCacheability.Public);
36     //是允许文档在被视为陈旧之前存在的最长绝对时间。
37     response.Cache.SetMaxAge(new TimeSpan(7, 0, 0, 0));
38     //将缓存过期从绝对时间设置为可调时间
39     response.Cache.SetSlidingExpiration(true);
40 }
41 #endregion

如果你的缓存是基于文件的方式,如XML或http中的.ashx处理,也可以使用下面的基于文件方式的客户端缓存:

1 #region SetFileCaching

..
2 /// <summary>
3 /// 基于文件方式设置客户端缓存
4 /// </summary>
5 /// <param name="fileName"></param>
6 private void SetFileCaching(HttpResponse response, string fileName)
7 {
8     response.AddFileDependency(fileName);
9     //基于处理程序文件依赖项的时间戳设置 ETag HTTP 标头。
10     response.Cache.SetETagFromFileDependencies();
11     //基于处理程序文件依赖项的时间戳设置 Last-Modified HTTP 标头。
12     response.Cache.SetLastModifiedFromFileDependencies();
13     response.Cache.SetCacheability(HttpCacheability.Public);
14     response.Cache.SetMaxAge(new TimeSpan(7, 0, 0, 0));
15     response.Cache.SetSlidingExpiration(true);
16 }
17 #endregion

使用HttpWatchPro在IE下运行,在Firefox下可以使用FireBug+YSlow进行测试.查看返回结果
YSlow是建立在FireBug基础上运行的一个小工具,它可以对你的网页进行分析为什么缓存,并给出评分和缓慢的原因.这个工具来自Yahoo的研发团队,所以规则也是Yahoo制定的.

结论

我们已经看了如何使用客户端缓存减少带宽和计算的方法,如前所述,如果能正确合理的利用各种不同的缓存,他们会给你带来很多的好处.我希望本文已为你当下或将来基于Web的项目提供了精神食粮，并正确地在底层利用Last- Modified和ETag响应头去优化你的项目。

标签: 客户端缓存阅读更多...

2010-03-13 13:53:41 WDK驱动开发与VS2008开发环境整合

2010-03-02 17:03:56 问答系统的模型图

2010-02-21 09:47:50 Web2.0架构下散列实现数据库负载均衡

2010-01-25 13:10:55 Crawler对页面评分的标准

2010-01-25 11:42:43 利用客户端缓存对网站进行优化

基础知识

Last-Modified和Etags如何帮助提高性能?

示例代码

结论

日志分类

日志搜索

最新评论

随机文章

热门标签

系统信息

合作伙伴