What are the most common application performance anti-patterns?
The most important item from the performance checklist is identifying anti-patterns. This will save valuable time once you already know the weak spots.
Nosy neighbor
Imagine you have a microservice that is deployed as a Docker container, and it is eating more CPU and memory than other containers. This can lead to outages since other services might not receive enough resources. For example, if you use Kubernetes, it may kill other containers to release some resources. You can easily fix this by setting up CPU and memory limits at the very beginning of the design and implementation phases.
No caching
Some applications that tend to work under a high load do not contain any caching mechanisms. This may lead to fetching the same data and overusing the main database. You can fix this by introducing a caching layer in your application. This can be based on a Redis cache or just a memory cache module. Of course, you don’t need to use caching everywhere, since that may lead to data inconsistency. Sometimes, you can improve your performance by simply adding output caching to your code. For example:
namespace MvcApplication1.Controllers
{
[HandleError]
public class HomeController : Controller
{
[OutputCache(Duration=10, VaryByParam="none")]
public ActionResult Index()
{
return View();
}
}
}
Above, we’ve added the output cache attribute to the MVC application. It will cache static content for 60 seconds.
Busy database
This issue is often found in modern microservice architectures when all services are in a Kubernetes cluster and deployed via containers, but they all use a single database instance. You can fix this problem by identifying the data scope for each microservice and splitting one database into several. You can also use the database pools mechanism. For example, Azure provides the Azure SQL elastic pool service.
Retry storm
Retrying storms and the issues they cause usually occur in microservice or cloud-distributed applications. When some component or service is offline, other services try to reach it. This often results in a never-ending retry loop. It can be fixed, however, by using the circuit breaker pattern. The idea of circuit breakers comes from radio electronics. It can be implemented as a separate component like an auto switch. When the circuit runs into an issue (like a short circuit), then the switch turns the circuit off.
Please check out the following shots for more information regarding this topic:
Free Resources
- undefined by undefined
