我已经在互联网上搜索了一段时间,但无法找到如何测试RavenDb查询速度的任何示例。
我尝试归档的是比较两个session.query并发现这两个中的女巫具有最佳的性能速度。我怎样才能做到这一点? //由于
编辑:
我正在构建一个mvc Notes-app,用户可以创建一个帐户并保存笔记。让我说我有这两个类:
public class SingleNote : ContentPage
{
public string Header { get; set; }
public string Note { get; set; }
public string Category { get; set; }
}
这一个:
public class LoginViewModel
{
[Required]
[Display(Name = "Username")]
public string UserName { get; set; }
[Required]
[DataType(DataType.Password)]
[Display(Name = "password")]
public string Password { get; set; }
}
最好在LoginViewodel中放置一个用户singleNotes列表并在那里存储所有用户注释,或者我应该在引用该用户的SingleNote-ravenDocument中放置一个属性。
我尝试实现的目的是对不同类型的查询进行测试,看看哪些查询获得最佳性能/速度。
如此相关的问题:我可以对此进行一些测试,并比较这两个查询,看看他们的女巫获得最佳性能速度:
案例1:我将道具字符串UserThatOwnsTheDoc放在SingleNote-class中 这里的风险我必须在集合" SingleNotes"中查询我的所有文档。这导致搜索许多文档。这可能是个问题吗?
var listOfSpecificUsersDocuments =
RavenSession.Query<SingleNote>()
.Where(o => o.UserThatOwnsTheDoc == User.Identity.Name)
.ToList();`
案例2:我已将道具List<SingleNote> SingleNotes
放入LoginViewModel
在这种情况下,我将每个笔记存储在UserDocument中。这里的风险是,如果单个注释列表中的文档大小可能会变得非常大。#34; SingleNotes&#34;。这可能是个问题吗?
var userDocumentWitchIncludesAListOfSingleNotes = RavenSession.Load<LoginViewModel>("UserName/1");
答案 0 :(得分:1)
我想说你感兴趣的不是性能测试,而是压力测试。假设您完成了性能分析并发现一种方法是“更快”,“更快”实际意味着什么?如果您的“更快”解决方案在负载下中断,这肯定没有任何意义。
您要做的测试类型是非常重要,需要付出实际努力才能实现。您不必孤立地查看性能,而是需要查看用户的整体体验。您需要规划一个场景(或可以并发运行的一系列场景),以模拟真实场景中系统的行为。
采取Twitter,“简单”压力测试可能涉及1000个用户注册,800个登录,400个帖子100个推文,200个帖子1000个推文,以及所有1000个搜索用户跟随链接到100个其他用户。同时做所有这些。监控系统各个部分的性能,是否会对其他部分造成损害?什么时候是系统的压裂点?
回过头来回答你的问题,这里的解决方案是建立两种可能的解决方案。然后对应用程序的MVC端使用标准负载测试器。这将向您显示有多少并发用户可以通过良好的体验,减慢体验并最终熄灯来支持。对于合法测试,请确保将应用程序部署到真实服务器,并运行具有可比质量生产服务器的IIS。 (也就是说不使用Windows 8,使用Windows Server 2012.在消费者版本上降级IIS以防止它被用作服务器)
在文档世界而不是关系世界中重新学习对象建模的一些简单建议。您正在寻求模拟交易边界。如果X改变,Y也需要改变?那些应该可能在同一份文件中。 LoginViewModel
这需要有一个List<Note>
,或者当用户登录时需要改写吗?我是否需要在每个时刻都需要所有相关注释的列表?如果答案是肯定的,我总是需要它们,这是它属于同一文档的明显标志。如果答案是“它取决于”或“有时”意味着它不属于同一文件。如果你想要做的事感觉“很难”,这是一个非常明显的标志,你有一个糟糕的文档模型。建模良好的非关系系统通常可以使用单个Load<T>
语句或单个Query<T>
来响应任何单个请求。如果您需要使用单个LoadStartingWith<T>
无法解决的多个负载,则可能存在错误,如果您进行多次查询,则类似。