Simulating a slow DB connection

4
votes

We are developing a fat client application that connects to a SQL Server DB using Entity Framework.

We obviously develop using a local DB, but one of the requirements is that the performance needs to be acceptable when ran over VPN connections with high lag (say, 200ms) *

I think a good way to test this would be injecting something that would add a 200ms delay to every command execution, so it would "feel" just like the real deal, and that can be enabled/disabled easily.

Any ideas on how to accomplish this?

sidenote: I would have done it differently, using a service-oriented architecture with DB access on an app server and coarser-grained interfaces, but it wasn't my call

4
sql-serverperformanceentity-frameworktestingado.net
How are you talking to the database? Are you using internal services, data-access-layer objects, repositories, what? - Lasse V. Karlsen
@Lasse: a thin dao/repository which just delegates to DbSet calls. But I can't just introduce a delay there, as many of the data accesses are caused by lazy loading. - Diego Mijelshon

4 Answers

6
votes

Put an instance of Wanem between the db server and the client. Wanem allows you to emulate a wide area network, with lots of configuration options. Don't forget that aside from the considerable lag you also have to factor in the reduced network speed.

Probably the biggest advantage of this setup is that you don't have to make any changes to the test machines.

2
votes

Another way would be to host your database in a virtual machine, for instance VMware, then you can tune the network performance of the virtual machines so that you get the exact environment you want to test in.

0
votes

If you are looking for programming solution and you are using ObjectContext API you can also check EF Provider wrappers. The provider wrapper creates instance of DbCommand. Commands are wrapped by DbCommandWrapper so you can introduce simple Thread.Sleep into ExecuteScalar, ExecuteNonQuery and ExecuteDataReader. You can use provider wrappers only in tests.

But I agree that solution offered by @fvu is much better and works with DbContext API as well.

-2
votes

Buy each developer a small-ish server (say a rackmount unit with hardware raid1 and 16G of ram; if you have more than a few developers, use blades). They should really have one anyway for experimentation purposes. Put your favourite virtualisation platform on it (e.g. Vmware). Have each developer run several VMs in this environment, one for the DB and one for the app, plus any others you need. You can then add boxes to simultate latency between the app server and the database, as much as you want.

This is not unreasonable, and it won't require any more software licenses; each developer needs a MSDN subscription license anyway in order to do anything in the Microsoft world. Such subscriptions allow you to run pretty much arbitrary Microsoft software for personal non-production use.

Getting developers a decent development environment is NOT expensive, and IS worth it in my opinion.

Of course developers should not be carrying out performance testing on their normal development rig. Performance testing requires a dedicated hardware-based environment which is configured the same as production.