We've installed SQL2012 on one of our servers and spotted an overall performance drop of around 20% when compared to SQL2008. On the same hardware and identical database settings (Optimize for Ad Hoc workload included), a repeated test of our application performs worse on SQL 2012.
In our test we clear the database plan cache, before a multi-threaded application server connects to the database and runs a set workload 10 times. After a number of runs the time taken against the SQL2008 database levels out at a consistent figure. When run against the SQL2012 database the time taken is 50-90% longer and does not find a consistent level.
We then repeated our test with a 2 application servers, and then with 4 application servers. They are able to spread the load to improve performance but do so by building a subset of the main database tables for themselves (to avoid locking issues, but yes, this means application servers can't reuse cached plans). We saw similar results comparing SQL2008 and SQL2012, the latter being slower and less consistent.
Our investigation so far has focused on the number of new compiled plans in the cache at the end of each run. We can see that at the end of each run for 1 or 2 application servers against SQL2008 the number of new plans in the plan cache settles down to around 50. For 4 application servers against SQL2008 the number of new plans settles down to around 2700. This is understandable as the application servers are not using the same database objects (remember they use a subset of the objects), and the plan cache may be filling up, with plans pushed out of the cache.
With the same test run against SQL2012 only 1 application server settles down to around 50 new plans per run. With 2 application servers the number fluctuates at around 1000 new plans, and with 4 application servers it's over 3500 new plans. The fluctuation is difficult to explain at all.
The conclusions we can draw from our numbers so far are that either SQL2012 cached plans are considerably bigger than SQL2008 cached plans, or that the plan cache is smaller in SQL2012 for the same settings, or that SQL2012 is recompiling code much more that it used to in SQL2008. Number 1 seems unlikely, number 2 a possibility but somebody would have noticed, and if it number 3, why are more recompiles taking place?
Any suggestions for where to go next?
Thanks,