最近看到了一篇介绍一个德国的交友网站架构的文章，网站规模在High Scalability上只能算是个中等的了，不过对于绝大多数普通网站来说，比那些Facebook，Google的案例更有指导意义。这个网站的状况是这样的：

• 2.000.000 users
• 20.000 concurrent users
• 300.000 private messages per day
• 250.000 logins per day
• We have a team of eleven developers, two designers and two sysadmins for this project.

在国内除了屈指可数的几个大网站，一般的大网站也就是这样的一个规模了。文章里逐一说明了它用到的各种技术，和具体的应用形式和优劣。有些地方还是有些借鉴的价值的。

Nginx：似乎很多大网站都已经放弃了Apache而转向Nginx或者Lighttpd了，Poppen前端是2台四岁的老服务器用来支撑峰值为150,000/min的页面请求，另外有3台nginx服务器专门处理图片请求。他们的特别之处在于应用了nginx的memcached模块来实现前端的缓存，这样一来多台前端服务器可以共用同一份缓存，相对于squid或varnish的解决方案，由于同一个页面无需重复生成，就能节省Web应用近一半的运算量。图片服务器的文件保存在本地磁盘， 用户上传的图片集中在一台图片服务器上，另外的三台图片服务器接收到请求后，如果本地没有这个图片，就回到那一个上传图片的服务器去取，然后保存在本地。这里我觉得用豆瓣那样的分布式存储，空间利用上可能会更高效一些，但他们这种的方式更加Simple & Reliable。

PHP-FPM：他们的应用服务器是28台运行着PHP5.3的服务器，每台运行着100个PHP-FPM工作进程，安装了APC。网站是用Symfony1.2开发的，一开始开发速度还是比运行速度重要的，在后期再通过Profile找出性能瓶颈，修改框架的底层代码，通过缓存一些重复的计算，降低框架带来的性能损失。性能分析是使用Facebook开源的XHProf模块实现的，由于XHProf的性能损耗很小，完全可以安装在正式环境中，对真实运行的系统进行Profile，对于发现真正的热点会有很大的帮助。不过对于他们这个规模的访问量（峰值2500/s），还是没算上缓存，他们的服务器数量也太多了点儿，不知道是缓存没起啥作用，还是Symfony的性能损失太大。

MySQL：MySQL似乎是个不变的主角，Scale中最棘手的问题都是在数据库上。Poppen根据网站功能对数据库做了大体的划分。用户相关的数据放在一台服务器上，并且正在准备着进行Sharding，很自然的会用userId进行分区；用户论坛的数据放在由三台机器组成的主从数据库上；用户的custom message存放在4台机器组成的主从数据库上；另外用到了一个NDB集群存放一些写密集的记录用户交互活动的数据；数据库引擎主要用了MyISAM，一切为了速度，但是越来越多的Table Lock让他们开始考虑转向XtraDB。我的上一篇博客有关于MySQL各种引擎的介绍，可以作为参考。

Memcached：他们把Memcache用的挺狠，45G的内存用来存储Session，页面缓存，函数缓存（保存一些函数的执行结果）等，但由于Memcache的功能有限，他们也正准备用MongoDb或Redis Hash API来替代，这样缓存更新时可以更灵活一些。

RabbitMQ：一个用Erlang实现的AMQP（高级消息队列协议），用来做任务的异步处理，现在正在把越来越多的任务交给队列去处理：写日志、发邮件、发消息、图片上传、等等。另外还用到了PHP-FPM的一个比较酷的功能：fastcgi_finish_request()，这个函数可以在PHP执行过程中，先结束HTTP请求的处理，把结果返回给用户，然后PHP脚步继续执行，处理一些用户不需要看到反馈的善后工作，这样就可以给用户更快的页面响应。队列中任务的处理是由两台服务器上的80个PHP进程完成的，每个进程只处理一个任务，然后重启一个进程， 这样来避免资源的泄露。不过这儿还是个保留的可以改进性能的点。

CouchDB：一个Erlang实现的文档型的数据库，感觉和MongoDB类似，他们用来集中的记录日志，不知道为什么他们不选择MongoDB来做这个事。

Graphite：实时的系统状态监控程序。

RED5：据介绍是个Open Source Flash Server，我还不太了解这个概念，不知道Flash Server都提供什么Service，在Poppen是用来支持在线视频播放和视频聊天的。文章后面的介绍中，他们似乎对这个系统不怎么满意，准备转移到Oneteam Media Server，written in Erlang.

TSUNG：Poppen的人似乎对Erlang情有独钟，这个东西也是个Erlang写的，分布式性能测试工具。

本文大致讲解一下MySQL目前除了主要的 MyISAM、InnoDB、Heap(Memory)、NDB 等引擎之外的其他引擎的发展和现状，以及MySQL主干以外的分支的状况，为了我们未来更好的使用MySQL或者其他分支建立一个了解基础。

要了解主要存储引擎，请参考手册：http://dev.mysql.com/doc/refman/5.1/zh/index.html
或者相关介绍文章：http://www.javaeye.com/topic/211951

【MySQL存储引擎介绍】

[ Falcon存储引擎 ]

Falcon存储引擎是MySQL当时寄以厚望的存储引擎，主要是为了面对当时Oracle收购了InnoBase公司的情况，用来取代InnoDB的一个存储引擎。Falcon引擎的主导人员是数据库大师Jim Starkey，从2006年开始开发，到2008年发布Beta版本，至今为止也没有走入主流。2008年中旬，Falcon的主架构师Jim Starkey宣布从MySQL公司辞职，加入了一家创业公司NimbusDB担任CEO，去设计和开发运行在云计算上面的关系/语义数据库，按照2010年目前NoSQL市场的发展来看，他的选择是正确的，但是带来的结果是Falcon陷入一个没有主导人员的地步，导致了至今都属于性能糟糕，半死不活的状态。

Falcon引擎是MySQL AB公司基于Netfrastrucure公司的产品开发的(Netfrastrucure公司被MySQL AB收购)，Falcon 当初的目标是嵌入到MySQL 6.0中用来取代InnoDB引擎，基本很多功能设计都是按照InnoDB的目标去设计的。

Falcon是面向多CPU、拥有大量内存的当代硬件环境和典型Web应用的数据库操作特点而开发的，主要功能包括多版本并发控制、完善的ACID支持、支持前缀压缩的B+树索引、数据页压缩（在磁盘上以压缩形式存储，在内存中以非压缩形式存储）、成组提交等。从功能方面来说没有什么新鲜事，大体也就实现了一个事务型存储引擎必须要有的功能（很多高级的功能如多表空间、分区等都还没有），但其架构上却有很多独特之处。

通过网上的一些测试结果Falcon的性能还是很糟糕的，写入速度是  MyISAM 的 1/10 ~ 1/20，Select 的优化也有问题，添加了索引感觉还会进行全表扫描。所以，我终究感觉 Falcon 是个杯具的引擎。

Falcon特性：http://dev.mysql.com/doc/falcon/en/se-falcon-features.html
Falcon测试：http://blog.gslin.org/archives/2008/02/12/1425/
Falcon手册：http://dev.mysql.com/doc/falcon/en/

[ SolidDB存储引擎]

solidDB存储引擎是由Solid Information Technology(http://www.soliddb.com)开发的，这是一款利用MVCC来实现的事务型存储引擎。它既同时支持悲观和乐观并发控制，这一点其他的存储引擎目前都不支持。solibDB的MySQL版本包括对外键的完全支持。它在许多方面与InnoDB很相似，比如它使用了簇索引。solidDB还包括一个没有额外开销的在线备份功能。

solidDB公司已经由2008年被IBM收购，主要是用于整合为IBM数据库整合方案的一部分，目前是作为一个前端数据缓存的这么一个角色存在。IBM收购solidDB公司，主要是因为甲骨文在2005年6月收购了Solid Information Technology主要竞争对手TimesTen，为了在内存数据库这块市场上有所依托，所以收购了 solidDB公司。

solidDB产品是一个完整的打包程序，包括solidDB存储引擎、MyISAM存储引擎以及MySQL服务器。solidDB与MySQL之间的结合出现于2006年的晚些时候。但是底层的技术以及代码却是经过了该公司15年的完善。Solid公司保证和支持了整个产品。它是基于GPL协议的，并且提供了一个类似于MySQL服务器形式的商业版本。
性能上来说，SolidDB for MySQL开源数据库再次被证明能够完全满足高吞吐量、关键任务级应用对系统性能和可扩展性的要求。

但是就 solidDB被IBM收购，MySQL对Oracle收购的情况来看，基本上 solidDB for MySQL 是一个没法继续被MySQL使用的引擎，所以也是一个杯具的MySQL引擎。

官方网站：http://www.ibm.com/software/data/soliddb/

[ XtraDB存储引擎 ]

XtraDB存储引擎是percona公司对于innodb存储引擎进行改进加强后的产品，第一个版本发布于2008年底。XtraDB兼容innodb的所有特性，并且在IO性能，锁性能，内存管理等多个方面进行了增强。

Percona是一个MySQL技术咨询公司，他们有一个在MySQL领域很有名的技术博客叫做 Mysql Performance Blog，同时他们编写了一本很有名的MySQL书叫做《High Performance MySQL》，目前也出版了中文版。他们公司还有一个很有名的MySQL备份工具叫做 XtraBackup。

XtraDB的设计目标也是取代InnoDB作为目标，它是基于InnoDB来做的开发，XtraDB 100%的兼容 InnoDB，通常可以认为 XtraDB 是 InnoDB的升级或者替代版本。在性能上来说，目前 XtraDB 是非常高的，在大部分情况下也是比较稳定的，值得你尝试使用。同样XtraDB也是未来感觉很有前途的一个存储引擎，值得我们期待。

性能测试：http://www.mysqlperformanceblog.com/2009/07/14/performance-improvements-in-percona-5-0-83-and-xtradb/
使用情况：http://www.ningoo.net/html/2009/xtradb_storage_engine.html

引擎介绍：http://www.percona.com/docs/wiki/percona-xtradb:start
引擎下载：http://www.percona.com/percona-builds/Percona-XtraDB/
公司官网：http://www.percona.com
性能博客：http://www.mysqlperformanceblog.com

[ Maria存储引擎 ]

Maria由MySQL的创始人，MyISAM的作者Monty (Michael Widenius) 开发，命名为Maria是因为他的第三个小孩就叫Maria。Maria是Monty在MySQL公司的时候就开始开发的一个MySQL的分支引擎，Sun收购MySQL后，因为与Sun针对MySQL团队的一些问题不和，然后在2009年初离开了Sun，成立了 Monty Program Ab 公司，专门用于针对 Maria 引擎的开发，同时开发了一个MySQL的分支，叫做 MariaDB。

Maria是一个MySQL的存储引擎，利用它来扩展MyISAM使之在异常退出时文件不至于损坏。Maria的主要目的是作为更好的MyISAM，提供崩溃后的故障恢复功能。更长远的目标是成为一个全功能的事务型存储引擎，支持ACID、回滚、多版本并发控制、行级锁、成组提交，同时也可以选择不支持事务，最终代替MyISAM成为MySQL的默认存储引擎。

目前Maria引擎有针对MySQL 5.1 的版本，基本上就是一个增加了崩溃恢复功能的MyISAM，使用表级锁，但可以做到读写不冲突，即在进行任何类型的更新操作的同时都可以进行读操作，但多个写操作不能并发。

Maria的特点：
1. 多版本并发控制，ACID支持
2. 通过拷贝日志就能进行增强备份
3. 高效的磁盘存储

Maria 引擎开发之初就是用来取代MyISAM的存储引擎，并且目前按照我了解有些在使用公司的情况，运行情况挺不错，大家也可以尝试一下。Maria 在目前有MySQL创始人带领的情况下，也是一个非常有前途的的存储引擎，值得期待。

Maria下载：http://askmonty.org/wiki/MariaDB:Download
Maria手册：http://askmonty.org/wiki/Maria

[ PrimeBase XT (PBXT) 存储引擎 ]

PBXT 是 PrimeBase 公司推出的MySQL插件引擎，其功能和 InnoDB 类似，它是一款事务型存储引擎，并且它的设计是很独特的。它的一个很与众不同的特征就是如何来使用事务日志和数据文件来防止“write-ahead”日志，这可以极大的减少事务提交的开销。这个架构给了PBXT很大的提高写并发的空间，并且测试也表明它在某些特定的操作下比InnoDB要快。PBXT也使用了MVCC并且支持外键约束，但是它不使用簇索引。

主要特性如下：

MVCC的 ：多版本并发控制，使读操作没有锁定
事务性 ：支持启动开始，COMMIT和ROLLBACK和恢复上
ACID标准 ：原子性，一致性，隔离，持久（一次提交的更改不能丢失）
行级锁定 ：更新使用行级锁的并发允许最大并发量
死锁检测 ：立即通知如果客户端进程已陷入死锁
参照完整性 ：外键的支持。
写一次 ：PBXT避免的架构双写入使用日志。
BLOB的流 ：在结合的 BLOB Streaming engine.。 (http://www.blobstreaming.org/)

按照有人的测试结果来看，PBXT存储引擎版本的TPS随着线程数的增长，表现比较稳定，性能上与innodb差不多，长期来看，它的目标也是作为一个能够取代InnoDB的存储引擎。而且目前 MariaDB 这个分支已经把 PBXT 作为内置的存储引擎，所以也是可以尝试使用的一个引擎。

性能测试：http://imysql.cn/2008_07_25_innodb_vs_pbxt
引擎下载：http://www.primebase.org/download/index.php
官方网站：http://www.primebase.org/

【MySQL分支介绍】

[ MariaDB 数据库]

MariaDB 是一个采用 Maria 存储引擎的 MySQL 分支版本，是由原来 MySQL 的作者 Michael Widenius (Monty) 创办的Monty Program Ab公司所开发的免费开源的数据库服务器。基本上 MariaDB 的历史跟我上面讲的 Maria 存储引擎历史一样。MariaDB的设计目标就是用来取代 MySQL Server。Monty是开源数据库联盟（Open Database Alliance）的发起者，所以 MariaDB 也是开源数据库联盟的成员。

MariaDB基于事务的Maria存储引擎，替换了MySQL的MyISAM存储引擎，它使用了Percona的 XtraDB引擎来替换InnoDB，MariaDB的存储引擎还包括了 PrimeBase XT (PBXT) 和 FederatedX 存储引擎，MariaDB基于GPL 2.0发布。

Monty Widenius提供了MySQL的分支MariaDB候选版本。MariaDB 5.1完全兼容MySQL 5.1，这个版本早在2008年11月就发布了，增加了很多新的功能和若干个新的补丁程序。开发者称这个候选版本非常稳定。基本上 MySQL，MariaDB 解决了很多问题，例如“pool of threads”功能提供解决多数据连接问题。目前 MariaDB 发布的Release版本是 5.1.44，基本上应该是跟 MySQL 5.1 的版本兼容的。

MariaDB 基本上名门之后，加上MySQL创始人Monty的实力和号召力，是作为MySQL一个非常好的替代品，前途发展无限，值得我们尝试使用。

MariaDB中存储引擎介绍：
Maria:  http://askmonty.org/wiki/Maria
XtraDB: http://www.percona.com/docs/wiki/percona-xtradb:start
PBXT:   http://www.primebase.org/
FederatedX: https://launchpad.net/federatedx

MariaDB下载：http://askmonty.org/wiki/MariaDB:Download
MariaDB网站：http://askmonty.org

[ Drizzle 数据库]

Drizzle，是从MySQL衍生出来的一个数据库服务器，一个精简版的MySQL分支，Drizzle项目的宗旨是构建一个“更精练、更轻量、更快速”的MySQL版本，它的扩展性和易用性与MySQL相当，但为了提高性能和扩展性，它从原来的核心系统里移除了部分功能。 Drizzle 也是开源数据库联盟（Open Database Alliance）成员。

MySql的架构设计总监Brian Aker在O’Reilly开放源码大会（OSCON）上对Drizzle做了介绍。Drizzle是一个能为某些特定类别的应用提供支持的数据库项目("what if" project)。Drizzle的设计目标：
1. Web应用。
2. 云计算组件。
3. 没有业务逻辑的数据库（又名存储过程）。
4. 多核架构。

Drizzle，一个精简版的MySQL分支，在目前的MySQL代码基本之上，将存储过程、视图、触发器、查询缓存、PREPARE语句等等没什么必要 的功能从代码中删掉，简化对数据类型和存储引擎的支持，并且进行大胆的重构。最终要实现的目的是将MySQL的代码大大简化，理顺MySQL的架构，改善 MySQL的代码质量，提高系统的稳定性和性能。将更适合 Web应用、云计算组件、没有业务逻辑的数据库（又名存储过程）、多核架构 等业务

Drizzle的特征有：
* 基于MySQL 6.0的源码树
* 无附加库
* 遵守POSIX
* 微内核设计
* 可插拔架构，适用于视图、存储过程、UDF、存储引擎等
* 跨多个节点的Sharding技术
* 智能代理
* 多CPU/多核CPU
* 优化的字段类型
* 高效的内存使用
* 没有内部ACL，使用LDAP/PAM
* 没有数据库数据格式化
* 整理有序的Make系统
* 缺省存储引擎为InnoDB
* 移除Windows兼容性

Drizzle 缺省的存储引擎是InnoDB，支持的数据类型更少，基本上设计目标跟 MariaDB 完全不同。MariaDB的设计目标是一个取代MySQL的数据库，而 Drizzle 基本上是一个除了MySQL之外你可以选择的产品，并且基本上设计目标是针对未来的云计算和分布式Web存储的方向去的，目前可能不是太稳定，不适合在运营环境使用，但是相当的值得期待。

Drizzle使用：http://database.51cto.com/art/200907/137239.htm
Drizzle下载：https://launchpad.net/drizzle
Drizzle网站：http://drizzle.org/

【总结语】

基本上来说，目前MySQL还是主流(MyISAM/InnoDB)，但是未来发展不可预测，并且有这些除了MySQL之外的选择，也许有一天Oracle把MySQL彻底消灭掉了，但是我们同样还有 MariaDB、Drizzle可以选择，这就是开源的力量。

对比几个MySQL的存储引擎，Maria 和 XtraDB 是值得大家目前投入逐步使用的行列的，多做一些测试，灰度放亮，获得一个合理结果然后再使用是比较合适的。MySQL的数据库分支来说，MariaDB 也是比较值得尝试使用的，毕竟目前 Drizzle 还不是太成熟稳定，并且不一定适合你所做的业务。我所了解国内部分互联网公司也有在使用 MariaDB 的，并且效果不错，大家也都可以按照自己的情况来使用。

目前NoSQL运动如火如荼，有些业务更适合采用Key==>Value或这是BigTable类型的数据存储方式，也许MySQL不是最好的，当然选择最合适存储，也许未来大部分数据库市场会被NoSQL所占领，但是我觉得关系型数据库还是未来几年很重要的存储方式。

在MySQL被Sun收购，已经Sun被Oracle收购的过程中，整个开源世界都是在翻天覆地的变化，特别是MySQL的命运一直都是所有使用和热爱开源数据库的人们所关注的，在这些商业竞争中，那些开源斗士(比如 Monty)，都通过别的方式，继续发扬了MySQL这种开源数据库。我们长期来看，总会有一些东西会消失，比如 Falcon存储引擎，有些东西会继续发展，比如 MariaDB或Drizzle，但是这些都为开源技术做出了贡献，也为数据库领域增添了色彩。

其实Python里对编码的处理能力还是很强大的，只是需要理解它处理字符的方式。Python里有两种字符串，str和unicode，他们都是字符的序列（相当于字符数组），区别在于字符的不同，str里一个字符就是一个字节，unicode中的一个字符是一个unicode里的字，长度可能是2字节，也可能是4字节。

Unicode是Python对多字节字符使用的一种内部编码，也就是说在Python内部处理多字节字符的官方编码，但它并不是我们常见的utf-8，具体是什么编码我也不清楚。在Python里处理字符串时，都需要先将来自文件、网络、或者str的字符串转换成Unicode格式，这一步是通过unicode工厂函数或者str的decode方法（decode可以理解为是从一种被编码的二进制字节流解码为Python内部通用的格式），但这是Python并不知道这个外部格式到底是什么格式，decode方法可以传入一个参数，表示这个数据是什么编码。

得到Unicode对象后，就可以对字符串进行各种操作了。在完成操作，要把字符串输出到文件、网络、或者数据库的时候，就要根据需要再把Unicode转换成需要的目标编码了，这是就要用到encode方法了，将字符串编码成需要的格式。

http://effbot.org/zone/unicode-objects.htm

今晚，在清华科技园Google楼前，人们献给Google的花束，和烛光

很迷惑为什么PostgreSQL这样优秀的一个项目总是不被接受，网上搜出的和MySQL的对比都在说PostgreSQL比MySQL慢得多，而证据都是三四年前的某个测试数据。昨晚找到了一个09年6月的帖子，测试方式还算比较严谨，数据在上面的链接里可以看到，作者得出了以下结论：

• MySQL 5.0.51a-24+lenny1 – Debian stable version is the worst performer (also the MySQL version is a little bit old).
• MySQL 5.1.30/InnoDB 1.0.3 with Google SMP patch – Compiled by SUN and InnoDB compiled by ORACLE outperform PostgreSQL in some cases.
• PostgreSQL 8.3.7-0lenny1 – Debian Stable version – It’s a top performer from the Debian standard distro and is out performed only by the latest InnoDB 1.0.3.
• Differences between PostgreSQL and MySQL 5.1.30/InnoDB 1.0.3 are very small
• PostgreSQL is outperforming any MySQL version on Creating, Loading, Created Indexes operations (this can be very usefull on a DB recovery).
• I don’t know why PostgreSQL is performing bad on bulk_delete() bulk_modify() querys … is possible to have a glitch in my configurations?

除了一个批量删除和批量修改的操作PostgreSQL慢的有点离谱（和MySQL相差6000多倍），应该能算是个Bug了，其他的性能大多还是比MySQL要好的。当然这里都是和InnoDB比较的，若是和MyISAM相比的话，慢点儿也是正常，因为MyISAM的功能太少，少了很多必要的操作和约束，对于任何一个业务系统，没有事务支持都是肯定不行的，不过这在MySQL的主要应用领域——网站上并不是个大问题。

网上传言太多，有必要出来说明一下，但又不能连累国内的idc背个非法接入的罪名，所以借个国外ip来说下，请大家广而告之，本页面稍后也会关闭。

BTCHINA 接广电通知 因无视听许可证 所以工信部删除备案号 关站 关于本人安全问题 再次证明网上传言不可信 特别是新闻最不可信

自从奥运以来，国家对版权的管理确实严格了很多，奥运的主题歌想播放都要买，国产大片过上仨月半年也难找到清晰的下载，还好需要下载的资源大多是国外的，不侵犯国内的利益，日子也还算安稳。如今btchina突然倒了，咱们的ZF办事确实爽快，不像欧盟那样还要磨磨唧唧的跟海盗湾打上半年官司，工信部一句话就全解决了。

这个事情让我们习惯了免费资源的人颇感担心，不知道这个行动时针对盗版，还是btchina上某个资源不小心越过了ZF的底线。世界各地的反盗版行动确实让盗版有点四面楚歌了，现在似乎很有必要出现一个完全去中心化的分享工具，构筑一个完全共享的Internet，道高一尺，魔就得高一丈嘛。

首先，在ASP.net的Web应用里，因为和用户交互是单线程的，异步的执行是没法把结果反馈给用户的，所以需要以同步（Synchronized）的方式执行工作流，这就需要创建一个ManualWorkflowSchedulerService得实例schedule，注册到WorkflowRuntime上，来覆盖了默认的DefaultWorkflowSchedulerService。在创建了Workfow Instance并调用了instance.Start()的时候，工作流还并没有开始运行，但已经On schedule了，这时候再调用schedule.RunWorkflow(instance.InstanceId)，这时工作流就开始执行了，RunWorkflow会在工作流进入等待，或者结束的时候返回。

另外就剩下工作流运行环境初始化的问题了。这部分工作可以在Global.asax文件里完成，一个ASP.net应用里，WorkflowRuntime的实例只需要又一个，所以在各个页面里去初始化就太浪费了，在Application_Start和Application_End里完成WorkflowRuntime的初始化和清理工作：

void Application_Start(object sender, EventArgs e)
{
	System.Workflow.Runtime.WorkflowRuntime workflowRuntime = new System.Workflow.Runtime.WorkflowRuntime("WorkflowRuntime");
	System.Workflow.ComponentModel.Compiler.TypeProvider typeProvider = new System.Workflow.ComponentModel.Compiler.TypeProvider(workflowRuntime);
	typeProvider.AddAssembly(typeof(Ganji.OA.Workflow.ExpensesClaim).Assembly);
	workflowRuntime.AddService(typeProvider);
	workflowRuntime.StartRuntime();
	Application["WorkflowRuntime"] = workflowRuntime;
}

void Application_End(object sender, EventArgs e)
{
	System.Workflow.Runtime.WorkflowRuntime workflowRuntime = Application["WorkflowRuntime"] as System.Workflow.Runtime.WorkflowRuntime;
	workflowRuntime.StopRuntime();
}

That’s all

# localhost name resolution is handled within DNS itself.
#    127.0.0.1       localhost
#    ::1             localhost

把localhost的解析也交给DNS了，不知道是出于什么考虑。造成的结果是，在本地开发时，IIS里运行的PHP用localhost连接不到数据库了，让我折腾了很久。在本地开发.net时，调试时用IE比FF，Chrome要快很多，我还以为微软搞了什么后门，原来是因为IE里缓存了DNS的查询结果，而FF和Chrome没有，所以总看到FF下面的状态栏显示“正在解析localhost”，在hosts里加上localhost的设置之后，FF和Chrome也和IE一样了。

先去下载了Windows下的PHP5.3.1  VC9 non thread safe 的安装程序，要注意，那个WinCache只支持非线程安全的版本，另外想用Apache的话，要下载VC6的版本，VC9编译的似乎不支持Apache（选择菜单里没有，也没有试过到底能不能用）。

安装之前要把IIS里的CGI功能装上，位于打开或关闭Windows功能 > Internet信息服务 > 万维网服务 > 应用程序开发功能 > CGI，现在的PHP安装程序已经很智能了，安装结束后，把默认网站的文档路径设置到原来的htdocs，从浏览器里打开localhost就能看到自己PHP的应用了，另外建议在根节点的FastCGI设置里，把FastCGI属性中的监视对文件做的更改设置为php.ini的路径，这样在更新了php配置之后，IIS就会刷新php-cgi的设置了。

另外在安装完之后还出现了一个奇怪的问题，用localhost为主机名连接mysql数据库时总是连接超时，改成127.0.0.1才能正常，看了一下hosts文件发现，Windows7的hosts文件里没有定义localhost，但在命令行ping localhost是正常的，还没有深究。

P.S.
今天在这个PHP环境里装了个Drupal，运行速度明显要比WAMP要快不少。另外，Wincache也有个wincach.php，相当于APC的apc.php，可以查看当前的缓存使用状况，不过wincache好像没有提供用户变量的缓存功能。