LightSwitch – 10 Performance Tweaks Anyone Can Do

“HOW can I improve performance in my LightSwitch app?” – is a question that pops up in the MSDN Forums frequently enough (like here and here).

I’ve got some basic tips below that show how to make some some simple tweaks to your LightSwitch app that could improve your performance:

1) Non active "tabs"

If you have non active “tabs” on your screen, you should know that they still execute HTTP queries over your network to retrieve data. . One work around for this is to break out your tabs into separate screens.

2) Data columns you don’t care about

IF you have control over the data model, consider breaking out columns that you don't show on the screen into separate tables, and then create a 0..1 relationship with that table. For example, let's say you have a Customers entity that has a picture of the current customer, but you don't show that picture on the screen. That picture data is still going to be requested and thus hurt performance. A way around that would be to refactor the data model and place the picture data into a separate table that is related to customers by a 0..1 relationship.

Reference properties on your entities are another piece of data that can slow down your performance. If you have reference properties on your entity, but you don’t care about them, then consider removing them from your screen

3) Computed Properties and Validators

Avoid performing queries in computed properties and validators. Or consider "persisting" computed properties IF it makes sense (I do just that on my blog here: OData Apps In LightSwitch, Part 1)

4) Editable Grid Screens vs. List and Details

As a general rule, List and Details screens perform better than a Editable Grid screen.

5) A bit more advanced IIS Server tweaks

There are other options that you could consider on the IIS Server (assuming there is one). Enabling dynamic compression could be helpful if you have CPU cycles to spare on the IIS Server, and you suffer from limited available network bandwidth.

Having your data tier machine (for example the SQL Server) and your IIS Server on the same machine, if possible, would obviously reduce network latency issues.

6) Screen methods

If you are doing filtering of data in one of your screen methods, consider doing that on the server tier if possible. That way, by filtering the data on the server side, you can reduce the amount of data that is sent across the network since that additional data that you filtered out won’t get sent over to the client now.

Another one to be careful of is the Screen_InitializeDataWorkspace() method. Keep in mind that any code you run in that method has to complete before the any of the screen queries will be executed. It can be a bit of a bottleneck if used incorrectly.

7) Profiling

Don't be afraid to use profilers to profile your client, and middle tier logic. Use SQL profiler to analyze the queries you application is executing. Use Fiddler to track the number of middle tier requests and the response sizes.

8) Load Testing

Load testing is a great and easy way to get some data on how your LightSwitch application will perform in the real world. Visual Studio Ultimate has some great tools for doing your own load testing (and there are a number of 3rd party tools as well). Also see my friend Saar's post about Load Testing with LightSwitch Apps.

 

9) Giant screens with lots of data 

Probably obvious by this time, but keeping your LightSwitch screens small as possible, and not too complex will almost certainly help you avoid many a performance issue.

10) Queries (the messy ones)

Queries can be difficult to get “right” sometimes. They can be messy and just slow everything down. That is a blog post by itself, and fortunately my smart co-worker Beth Massi has already written one - check it out - LightSwitch Tips & Tricks on Query Performance.  

That’s it for now. We’ve been working on some awesome stuff here at the Fargo office, and I’m looking forward to blogging on that shortly. But first I’ve got some more testing to do.

Let me know if this helps (or not).

Thanks a lot – Matt Sampson