In my latest project, I have to write a web service API to return data from a database.
Techs are - SQL Server 08 R2 - WCF
The data is mainly key-value pairs, e.g. for get user X's favourite colour.
The load isn't massive, but not small-fry either - about 1,000 requests / sec at peak.
My initial thoughts are to use Redis as the cache, meaning we don't hit SQL Server as often. However I've been trying to get some benchmarks etc out of this configuration, and it's not great, making me wonder if Redis will really offer any benefit for my problem!
Architecture is - separate db server - WCF App Server - IIS - Linux Redis server
When playing around on my desktop, the Redis benchmarks at ~ 20K ops / sec. Great stuff.
However, given that each call will go through a web service, when I put a WCF layer I can only get 300 ops / sec. Not great. Admittedly, web service client, web service and database are all on the same machine, so that might skew the results!
Also, when moving to the real environment, network latency will be a major factor.
I can't batch these requests up in any way.
So - my question - I'm all for using Redis as a cache - I know I should use a cache in this situation - but given that I can't have Redis on the same box as my Web Services then won't network latency kill performance?
Any advice greatly appreciated!
Duncan
I'd try to test and tune your layers separately. Test the web services with dummy data not involving the db, but with similar data size and concurrent connections. Same with the database, tuning your queries again with realistic load and table sizes, using synthetic data (or real if you can) to match the size of your expected user base. Test these two together, making careful measurements so you can verify how your changes affect overall performance and where the bottlenecks are. Finally, add the caching layer, again testing for effectiveness. If the db is the bottleneck, caching may help, but if the web services layer is the issue, caching likely won't. If you're only using Redis for a cache, you might like the simpler memcached better.
You could also check if using .NET 4 which I think you should the System.Runtime.Caching library.
Gives you great flexibility as soon as you use 1 server. If you need a web farm, or when things can be more tricky like synchronization, invalidation, expire etc, meaning some distributed cache (memory in my opinion), supporting Local store (in-memory usually, local) and distributed store. You could use this namespace too with AppFabric to get the desired caching.
Hope this works for you.
来源：https://stackoverflow.com/questions/10675578/using-redis-to-scale-web-services