In the first best practice, we looked at how we can gain maximum performance out of SSDS by partitioning our data across multiple containers. In this post, we are going to look at how we can take advantage of the many SSDS front end servers to maximize our applications performance.
SSDS is an Internet based data storage and query processing utility service. Lets face it, SSDS can only be as fast as your Internet connection. With that being said, when we architect our applications, we need to keep that in mind and be sure that we take whatever steps necessary to ensure that our application performs well. There are a handful of access and caching patterns we can use to ensure that any latency doesn't impact our applications performance. In this post we are going to concentrate on concurrency.
If we once again look at how SSDS is architected, we will see that we have many, many front end servers that expose the service via our SOAP and REST interfaces. This is the area in the diagram below in blue. In addition, those front end servers can accept many concurrent connections.
Those front end servers look at the operation you are performing, and route the request to the back end server that your container is located on. The back end servers are in the orange area in the diagram above.
To gain maximum performance from SSDS, don't just perform your operations in a singleton fashion. Issue those operations concurrently!!! If you architect your application so that it can make multiple simultaneous asynchronous calls, you can be assured that you are best utilizing SSDS and that your application will perform well - at least from a data access perspective ;)
One thing to watch out for....SSDS only supports a simple concurrency model today. Cases where you need to perform multiple entity updates as part of an single operation, this batch of updates needs to be managed in your application (SSDS doesn't support batched updates today, but its a feature we have in our plans). These operations can be multithreaded, but you need to ensure that you save both the original version of your entity and the updated version of the entity within your application. This way, should one of the operations fail, you can have your application perform any remediation necessary.
So to recap...
If anything is not clear, or if you have specific questions around your scenarios, let me know. I'd be happy to help.
-Dave