亚马逊平台上的最佳实践会话管理

Question

i have performance issue regarding sessions, i'm using the following components 1. MongoDB as my application database 2. MySQL as my analytics database 3. Memcache to reduce call to MongoDB

My application is based on Amazon Servers, MongoDB installed on a standalone instance, MySQL on RDS and the application itself installed on a standalone instance.

I tried to remove the session handling between MongoDB and MySQL saw that MongoDB has better performance but still it is very slow.

I heard about Elastic Cache but i'm not sure this is the suitable solution, and i wonder What is the best practice for session handling in Amazon.

BTW, my code is written in PHP, my client is flash.

Thanks.

Answer 1

There is no right answer to your question as there are too many variables in an application to declare one obvious best practice. Here are some considerations you should make:

1. Analyze the performance of your existing solutions more carefully to better understand the nature of the problem you're having before switching to a new option. MongoDb should be fast enough in many cases to meet your needs if properly configured and scaled. It's hard to troubleshoot why it's not performing adequately on StackOverflow (and then may be a better match for another StackExchange web site). I'd read up on recommendations for configurations of any DB you select. You may find the cost of an ideal setup exceeds your budget.
2. If you're managing your own DB server, you should consider buying Provisioned IOPs, to help assure a consistent level of disk IO. This will significantly affect the performance of MongoDb for example.
3. Consider what performance you require compared to your budget
4. Minimize the size of session data. Developers often treat it as an inexpensive magic data bucket unfortunately, and don't realize the nature of how session providers work in a general sense. Disk IO will be slower than RAM.
5. Cache more, put less in session. For example, keep the absolute basics of the user in session if you need to, but put the details in Memcached for example.
6. Decide what type of resiliency you need if a memory backed cache is used and the cache fails or reboots. If you chose an option that is non-disk backed and session is stored there, your users may be unhappy during this recycle if they need to login again.
7. The AWS team would recommend that you strongly consider DynamoDb as the backing for your session provider. You can essentially purchase the performance you need. It's not inexpensive, but you're buying a very robust service.
8. Using Elastic Cache could be an option. While the Memcached option offers no session resiliency in case of failure (data is lost), the Redis option with the master/slave and multi AZ option may meet your needs.