我正在使用JMeter对我的MVC3（WebApp），EF6.1，SQL Azure（S2）应用程序运行压力测试。
V11和V12实例完全相同。基本上我使用相同的“bacpac”文件。在创建V12实例时，我创建了新的SQL Server，然后导入了“bacpac”，选择了S2定价层。所以两个实例都是相同的，除了一个在V11服务器上，另一个在V12服务器上。
我的JMeter测试用例中有大约60个电话。最初我运行一个循环，然后运行五个循环，并且具有不同数量的并发用户，如下所示：
1 User, 30 sec rampup, 1 loop V11/S2 550ms (average)
1 User, 30 sec rampup, 5 loop V11/S2 555ms (average)
1 User, 30 sec rampup, 1 loop V12/S2 755ms (average)
1 User, 30 sec rampup, 5 loop V12/S2 800ms (average)
5 User, 30 sec rampup, 1 loop V11/S2 620ms (average)
5 User, 30 sec rampup, 5 loop V11/S2 684ms (average)
5 User, 30 sec rampup, 1 loop V12/S2 800ms (average)
5 User, 30 sec rampup, 5 loop V12/S2 972ms (average)
10 User, 30 sec rampup, 1 loop V11/S2 868ms (average)
10 User, 30 sec rampup, 5 loop V11/S2 1317ms (average)
10 User, 30 sec rampup, 1 loop V12/S2 1000ms (average)
10 User, 30 sec rampup, 5 loop V12/S2 1686ms (average)
20 User, 30 sec rampup, 1 loop V11/S2 2422ms (average)
20 User, 30 sec rampup, 1 loop V12/S2 3000ms (average)
上面的测试用例混合了创建，更新和选择。时间也代表请求的完整时间。但是，通过查看我的NewRelic图表，我可以看到.NET组件是次要且一致的，而SQL服务器组件是主要的和可变的，即当用户数量增加时，它会出现。
我看过一些人应该加快25％的速度。有了上述结果，我似乎将从“网络版”迁移到V11，但不会迁移到V12。如果其他人经历过同样的事情，或者除了使用S3或P1之外你是否能提供理由或可能的解决方案，我会感兴趣....
修改
我已经使用与上述相同的测试计划（即大约60个http调用）进行了所有兼容性级别（即100,110和120）的进一步测试。我的原始数据库是在SQL 2008上开发的，并且设置为兼容级别100.但是V12上的兼容级别之间存在可忽略的差异，并且所有数据都与V11相比表现不佳。即：
S2/V11/100 10 users, rampup 300 secs, 3 loops 632ms (Av. Req.duration)
S2/V12/120 10 users, rampup 300 secs, 3 loops 1029ms
S2/V12/110 10 users, rampup 300 secs, 3 loops 1111ms
S2/V12/100 10 users, rampup 300 secs, 3 loops 1088ms
S2/V11/100 20 users, rampup 300 secs, 3 loops 1180ms
S2/V12/120 20 users, rampup 300 secs, 3 loops 4190ms
S2/V12/110 20 users, rampup 300 secs, 3 loops 4388ms
S2/V12/100 20 users, rampup 300 secs, 3 loops 4269ms
S2/V11/100 30 users, rampup 300 secs, 3 loops 2745ms
S2/V12/120 30 users, rampup 300 secs, 3 loops 7937ms
所以看来我可以在我的数据库上的S2 / V11上同时运行额外的10个用户而不是S2 / V12，这很重要。所以目前我似乎最好留在V11直到我需要S3。我唯一想到的原因是DB是使用SQL 2008开发的。另外我使用Entity Framework 6，也许我需要调整配置？我不相信，从来没有过。