n1concepts Posted July 15, 2013 Share Posted July 15, 2013 (edited) Hi, I have a situation where I need to develop code that: 1. can manage an constant and high amount of affiliate clicks and conversation stats (24/7). Currently, this setup is operating with PHP (frontend) and MySQL (data storage). Results: quickly seeing lag time due to the constant queries, updates, and/or inserts (backend forth to the db). Note: all of the queries are looking for same (unchanged info - actually, the info will NEVER change so perfect for caching). ---- My question: Is this better suited for Redis - which can handle both READ/WRITE operations or Memcache - which only READ. I know Redis is the answer but I'm wanting to hear from someone that works w/Redis to know the following: 1. is Redis realiable enough to not have t worry about lost data - i read where it's not 100% but Redis clusters could be implemented to shard data (is this a good idea)? Any insight and/or examples of affiliate or click scripts links to review appreciated. Thx! Edited July 15, 2013 by n1concepts Quote Link to comment https://forums.phpfreaks.com/topic/280179-redis-vs-memcache/ Share on other sites More sharing options...
mac_gyver Posted July 15, 2013 Share Posted July 15, 2013 you do know that mysql has a query cache? have you checked if it is turned on and has enough memory available? also, your series of performance questions indicates you likely have an issued in your application logic that you need to fix before you can worry about caching, otherwise you are just putting bandaids on top of a problem. Quote Link to comment https://forums.phpfreaks.com/topic/280179-redis-vs-memcache/#findComment-1440833 Share on other sites More sharing options...
n1concepts Posted July 15, 2013 Author Share Posted July 15, 2013 Hey mac_gyver, Yeah, I'm aware of all of that but I don't think (still) you see what I'm getting at... There is no reason to perform (repeat) queries for same info so the objective is to cache that info which is what I've read and confirmed from multiple authorities. Managing this in MySQL is just not the most efficient way to do this.... The application logic is what I'm looking to do w/Redis as that data never changes and serving via Redis oppose to querying MySQL just make sense (not just from my conclusion) but from all the info I've gathered (including examples from Dig, Facebook, etc...) My question - here - was to see if anyone had actually worked w/it in this matter - that's all. As always: I appreciate your input (thx!) Quote Link to comment https://forums.phpfreaks.com/topic/280179-redis-vs-memcache/#findComment-1440836 Share on other sites More sharing options...
kicken Posted July 15, 2013 Share Posted July 15, 2013 If the data never changes, then why the bit about READ/WRITE vs READ-ONLY (for that matter, why do you think memcache is read-only?) since never changing data would by definition only need to be read? Second, if the queries and results never change, then the mysql query cache should be providing a good caching option already if configured. Thirdly, since you cache would essentially be read-only, your question about lost data would not really be particularly relevant. If for some reason the cache did loose the data, just re-query the database and re-add it to the cache. It seems like either there is more to this problem than you are making known, or you're trying to over-engineer a solution to a problem that either doesn't exist or has been incorrectly-diagnosed. Quote Link to comment https://forums.phpfreaks.com/topic/280179-redis-vs-memcache/#findComment-1440843 Share on other sites More sharing options...
n1concepts Posted July 15, 2013 Author Share Posted July 15, 2013 (edited) It would take too long to explain everything and i feel the responses are filled with ego - not sure why. I just wanted to hear from someone that had experience w/Redis..... Disregard providing help. I will figure ut out... Thx Edited July 15, 2013 by n1concepts Quote Link to comment https://forums.phpfreaks.com/topic/280179-redis-vs-memcache/#findComment-1440847 Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.