What an outstandingly excellent explaination !!! Yes handling mutexes and semaphores has it's own throughput headaches
An incredibly simple yet detailed explanation, thank you
Beautifully explained. Thank you!
this is a really good explanation πππ
Very great and thorough content! Thanks for the nice work!
BTW, the system calls for such network I/O multiplexing are generally either select or epoll. Nice to see an explanation of those someday from you. Good stuff!
Itni deep me reddis padai hai aapne sir thank you very much sir β€οΈπ₯ππππ
This channel should gain more reach β£
I used sorted redis sets in my company project for leaderBoard π , completely removing db here. Fetched the leaderboard combining two scores into one
Every embedded systems guy who works with C would find the 'single thread' design just another day in life.
@arpit as you said redis create connection fromTCP and in a single thread all those connection comes and execute. But i have also seen i can only create one connection in redis and that one connection can also serve as many request as multiple connection does. Which is more scaleble single connection with multiple request or connection per request is the ideal practice
Very well explained. Thanks a tonπ
Network IO is slow but execution is fast (in memory ) implies it has no waiting data (queue of commands ) to process thus IO multiplexing seems to be a wonderful solution
amazing content!!! Thank you!!!
NodeJs also works in similar fashion of single thread, if this is the key reason of its fast computation why no other cache tech implemented it at first end?
Hi Arpit , Is there a way we can limit number of tcp connection to redis at application layer in synchronous way ?
Pls add some videos on api performance improvements, error handling in micro services, performance testing of micro services
thanks bro
Hi Arpit, in this video are we using connection and request terms interchangeably in some cases? Also to achieve concurrency in single process mode (Generically speaking in terms of web services and processes like redis) either we can have thread per connection doing read() on socket (waste of thread since we usually have thread pools now especially in web servers) or Async IO + event loop or once connection is created monitor socket when request comes and we get notified trigger read() on it using a thread from thread pool (hybrid of above two) right? Btw great video loved it.
@kommisettyveerendranath53