有一个项目的选型，采用了微软提供的ORM框架Entity FrameWork 4.1。经过这些天和同事们的验证和搭建，昨天出来了一个初步的版本。针对该版本我们做了一次并发测试，测试的策略是这样的：
1：LoadRunner模拟一个用户打开页面，该页面中执行一个联表查询，由Entity FrameWork提供出来的数据库操作方法来执行，该方法查询出对象集后，Entity FrameWork将对该对象集跟踪，可以做延迟加载的操作。查询的SQL语句如下：
public List<DemoUserBM> GetUserList()
{
string strSql = "SELECT TOP 100 u.cniId as Id,u.cnvcUserName as UserName,u.cnvcPassWork as PassWork,getDate() as CreateTime,0 as Version FROM tbDemo_User u JOIN tbDemo_Address a ON u.cniID = a.tbDemo_UserId ORDER BY u.cniID DESC";
return this.SqlQuery(strSql);
}
该查询中采用了ORDER BY u.cniID DESC语句，尽量减少SQL SERVER查询的缓存命中率，提高并发测试的准确率。
2：LoadRunner接着做一个Insert操作，该操作是一个联表的插入，同时将user和Address的数据插入表中。由Entity FrameWork维护事务。
Random ro = new Random(99999999);
DemoUserBLL bll = DemoUserBLL.Instance;
//测试保存数据
DemoUserBM user = new DemoUserBM();
user.UserName = "jadesun";
user.PassWork = "123456";
user.CreateTime = DateTime.Now;
user.AddressList.Add(new DemoAddressBM() { Phone = ro.Next().ToString(), Address = "测试地址" });
bll.Save(user);
3，LoadRunner 继续做一个 Update 操作，该操作也是一个联表的更新。更新了User表，并再新增 Address 的一条记录。同样由 Entity FrameWork维护事务。
//测试更新事务数据
user.UserName = Guid.NewGuid().ToString();
user.AddressList.Add(new DemoAddressBM() { ColumnUser_Id = user.Id, Phone = ro.Next().ToString(), Address = "测试地址2" });
bll.Update(user);
bll.Dispose();
并发测试的策略就是一个用户做了查询、新增、更改的操作，由200个用户并发交替的执行。和陟昕讨论了一下，这样的测试对框架的验证可以提供参考性。
LoadRunner使用200个并发进行压力测试一个半小时的截图。
测试的数据量
LoadRunner在15分钟前，反映了平均响应时间有6秒左右，每秒执行的事务只有50多个。我检查了数据库，原来没有给tbDemo_Address表的tbDemo_UserId字段加入索引。添加索引之后，Loadrunner的平均响应大幅度下降（在一秒左右），执行事务的个数增加（300个左右）。
在并发测试至一个小时以后，数据的量达到百万级，tbDemo_User表有100多万，tbDemo_Address有200多万。这时侯的平均的响应时间增加（2秒左右），执行的事务个数下降（120个左右）。
posted @ 2011-07-26 11:56 jadesun 阅读(1262) 评论(3) 编辑