eWEEK Labs/PC Labs可以说是做基准测试的老大了，早在1993年10月份他们的姐妹杂志PC Magazine就做过同样的测试。这次和PC Magazine合作测试了五种数据库在Java应用服务器上的表现，结果显示MySQL最新的4.0.1版本性能可以和Oracle 9i媲美，垫低的当然是微软的SQL Server 2000。:-)

　　测试的这五种数据库是：IBM的DB2 7.2 FixPack 5，微软的SQL Server 2000企业版SP2，MySQL AB的MySQL 4.0.1 Max，Oracle的Oracle9i企业版9.0.1.1.1以及Sybase的ASE (Adaptive Server Enterprise) 12.5.0.1。

　　测试兼容性也是基准测试的一个主要目的，所有的数据库都在同样的硬件条件下测试：

　　HP NetServer LT 6000r带有四颗700MHz Xeon CPU，2GB内存以及24台10000 rpm的9.1GB Ultra3 SCSI磁盘，操作系统为Windows 2000 Advanced Server SP2。

　　测试的应用程序是一个叫做Nile的基于Web的书店应用。Nile采用了Empirix公司的测试套件6.0，能加载50到10000个并发用户。

　　测试采用的应用服务器是BEA的WebLogic 6.1 SP1，并用JSP编写了Nile应用。

　　每种测试运行一个小时产生五万张订单，15万到20万相关的记录数，我们得到的最好的伸缩性是在两台6路HP NetServer LT 6000r ( 4GB内存，千兆网卡)服务器上运行6个WebLogic例程。HTTP流量均衡的分配到这六个例程中。

　　测试的总体结果显示Oracle9i和MySQL有最好的性能和伸缩性，但是9i仅仅略微比MySQL好一些，ASE, DB2, Oracle9i和MySQL到达550个并发用户时已经“力不从心”了，ASE的性能下降到了每秒500个页面，比9i和MySQL要低100个页面，DB2在高负荷情况下，性能下降也很厉害，只有每秒200个页面了。

　　由于JDBC驱动存在问题，SQL Server在整个测试中都只能达到每秒200个页面。

　　驱动，内存优化和数据库设计问题是影响性能的主要因素，经过手工细调后的性能会和没有调优的性能差两倍。

　　Oracle和MySQL的驱动具有完整的JDBC特色和稳定性(MySQL的员工采用了Mark Matthews编写的JDBC驱动，因为他们没有自己的JDBC驱动程序)。

　　为各种数据库找到最好的内存配置是一件具有挑战性的工作，我们在这个问题上花了好几天。

　　SQL Server和MySQL的配置最简单，而Oracle9i是最复杂的。9i采用了很多独立的内存缓冲，每个数据库连接需要消耗很大的内存(大约400KB)，而DB2只需要177 KB，SQL Server, MySQL和ASE都只需要50KB就够了，结果是9i的数据和执行计划的缓冲就比别的数据库要小。

　　MySQL的高性能源自采用了内存内的查询结果集缓冲，这是4.0.1的新特色，我们不采用这个缓冲的话，MySQL的性能会下降三分之二。另外，MySQL的员工还根据表的不同采用不同的数据库引擎。

　　所有的订单表采用MySQL的InnoDB引擎(支持事务，行锁，多版本同步)，目录和用户表则不需要事务支持，采用了MySQL的轻量的，非事务的MyISAM引擎。

　　MySQL 4.0.1的新引入的高速查询缓冲引人注目，其他的数据库没有这个特色。如果查询的文本具有和缓冲中一模一样的匹配的话，MySQL能直接从缓冲去数据，而不需要编译查询语句，取锁或者搜索索引，这项技术在表不被经常更新的情况下十分有用。

　　微软的SQL 2000虽然在Java平台上没有上好表现，但是当我们用ASP.Net重写基准测试，并采用IIS 5.0，和OLE DB连接，得到的结果或许会让Bill Gates松口气，每秒870个页面。

　　在测试前，我们邀请五家公司派员参与测试，只有MySQL和Sybase欣然前往，IBM只是答应通过电子邮件交流，微软和Oracle都拒绝参加。因此他们的数据库调整都是我们代劳的。

　　在测试中，我们惊奇的发现驱动程序是问题的最大根源。

　　在五种被测试的数据库中，只有9i和MySQL能连续运行Nile 8个小时，DB2的JDBC驱动不支持可更新的结果集，因此我们只能打开所有的结果集(采用CONCUR_READ_ONLY)，采用SQL update语句来更新，最终还是通过了8个小时的稳定性测试。

　　在采用Sybase的JConnect 5.5驱动时，我们发现当应用请求的结果集包含双向游标时，JConnect把整个结果集存储在客户端的内存里来增加后续游标的命令处理速度，这项工作在低负荷时还马马虎虎，但是当用户达到上百时，应用服务器消耗了几百兆的内存。结果不到8个小时，我们的6个应用服务器进程统统挂起了。

　　为了解决这个问题，我们把应用的浏览逻辑重新改写，只采用前向游标(JConnect不在客户端内存缓冲)，为了保证查阅到前面的图书，我们需要把相同的查询运行两遍，得到图书的总数然后得到图书的数据，这样就影响了ASE的性能。

　　但是，这样做的结果是ASE的能整夜的跑基准测试，客户端能从C/S结构的应用中获益，但是对于应用服务器而言，这是一个可怜的选择。

　　微软的JDBC设计有缺陷，在WebLogic的控制台上我们发现每次Java虚拟机作garbage collection，释放出来的内存就少了一些，所以微软的JDBC驱动用不到8小时就歇菜了。(FreeLAMP 徐永久 提供)

   特别推荐：《流星花园》铃声图片专辑
      点一支歌送朋友，带给他(她)春天的信息和你的心意！