Index
- Intro
- Hidden exceptions
- Serialiation
- SSL Overhead
- Garbage collection
- SQL performance
- References
Intro
Here you will find some useful tips to improve the performance in your web applications based on Matt Watson webinar from Stackify. This is not the typical stuff about how to build your queries or caching calls to your backend. This is more the next things you should be taking care of.Besides, today I want to introduce you to Prefix. A free tool that runs on the developers machine (not in servers) which helps you understanding where your apps spend most of its time.
Hidden exception
In our apps, exceptions happen even when nothing is notified to us. Take a look at the "Output view" in Visual Studio when you spin up your new MVC project. You will see some exceptions poping up there. This "hidden" exceptions required a handling process we should get rid of.Add break on first time exceptions in your project configuration and you will start getting this like: first time you access the memory cache provider will trigger an exception because there's not a performance counter assigned to it.
Automatically log First time exceptions and Unhandled Exceptions with the following snippet:
Now I'm getting the whole stack trace from the exceptions triggered behind the scenes. Another best practice is the usage of TryParse functions when working with transformations.
Exceptions best practices:
- Avoid them at all costs
- Find hidden exceptions with Prefix
- Track all first chance exceptions to hunt them down
- Aggregate all exceptions in production
Serialization
Making calls to web services or databases and waiting for the answer takes a lot of time. My recommendation it's always check the database query or the process that happens on the backend. But when that bit can't be improved more (theoretically), then it's the time to talk about how the information travels from one place to another.Web requests typically have the following steps:
- Serialize request
- Send request
- Receive response headers
- Download response
- Deserialize response.
You can get a really good insight of the time for each of those steps by using a tool like Prefix. Just install and it will start monitoring the traffic on your local dev box. Take a look at the following picture where a data binding happens and spends 119 ms. just on that.
A good approach on web services is always the use of asynchronous operations so the interface will respond the user commands. Check these two code methods where I'm passing an input parameter on the first one and I'm waiting for the interface to send an asynchronous string on the second one.
I found this table very useful to help you understand how long it takes the serialization process in different frameworks. Keep an eye on MVC serialization process when using objects as it's the slowest one.
Serialization best practices:
- Understand payload size
- Customize JSON serializers
- Consider manually reading incoming data
SSL Overhead
Broadly used across many applications, the security handler runs on your machines and takes care of the user validation and message encryption.
SSL best practices:
- Offload SSL to load balancer or hardware if possible (Netscaler, F5, etc.)
- User Azure Application Gateway for SSL offloading
- AWS use ELB with SSL
Garbage collection
One key metric to monitor is called "CLR Memory % Time in GC" which comes out of the box with Stackify.
GC best practices:
- Avoid the large object heap
- Use streams where you can (example above)
- Avoid large strings
- Microsoft new feature: Server vs workstation GC mode
- Monitor GC performance counters
SQL Performance
In the following example I validate the execution time for a SQL query which takes a few ms. to be executed. Notice on the bottom right corner it takes 6 seconds to download. This is very important to understand as your current performance analysis reports might be wrong.
This is why we need to understand not only how long it takes to run a query, we need the download time for the user to get the query on its computer (serialization).
SQL best practices:
- SQL server performance is not exactly the same as real world performance
- Your SQL performance reports are probably wrong
- Use your logging or Prefix to understand real world performance.
0 comments:
Post a Comment