why concurrency is not implemented in redis

[KARTHICK VIJAYAYAKUMAR]

If we have concurrency ( more than one thread ), redis will respond more faster.

Regards,

karthick

[Salvatore Sanfilippo]

Long story short: for now the benefits would be small, but it is not impossible that in the future we'll have a model where slow O(N) requests that are sensed to take a lot of time since the key is associated with a big value, will be served via threads, while normal O(1) or O(log(N)) requests, or O(N) requests that are executed against small encoded collections, will take the usual path. I'm not sure I'll do this at some point but it is a design that makes sense for some workload where partitioning with cluster or alike does not make sense and there are a number of intersections and so forth.

Salvatore

--
You received this message because you are subscribed to the Google Groups "Redis DB" group.
To unsubscribe from this group and stop receiving emails from it, send an email to redis-db+u...@googlegroups.com.
To post to this group, send email to redi...@googlegroups.com.
Visit this group at http://groups.google.com/group/redis-db.
For more options, visit https://groups.google.com/groups/opt_out.

--
Salvatore 'antirez' Sanfilippo
open source developer - GoPivotal
http://invece.org

To "attack a straw man" is to create the illusion of having refuted a proposition by replacing it with a superficially similar yet unequivalent proposition (the "straw man"), and to refute it
       — Wikipedia (Straw man page)

[Angel Java Lopez]

But in this way, Redis using one thread:

- Redis is simpler

- No concurrency/lock issue on shared data (internal lists, arrays, etc...)

But we could think about:

- Determining the incoming pending requests are all "reads"

- Then, execute them in parallel

but then, when a request is a "write", how to determine all "reads" are complete, before executing the "write"?

We could use some fast sync primitives, but, Redis choose another way. Less is more ;-)

(I had a C# implementation of key/value trying the "reads" vs "write")

Angel "Java" Lopez

@ajlopez

--

[Itamar Haber]

Concurrency is a performance killer, Redis' (mostly) single-threaded architecture was deliberately chosen for its killer performance. If you want concurrency, use multiple instances or a cluster.

More info: http://redis.io/topics/latency & http://redis.io/topics/benchmarks & http://redis.io/topics/faq

Itamar Haber

VP Customer Relations

Redis Labs | formerly Garantia Data

Mobile: +1 (415) 688-2443

Mobile (IL): +972 (54) 567-9692

Skype: itamar.haber

Blog  |  Twitter  |  LinkedIn

--

[Didier Spezia]

But, Redis does provide concurrency. What it does not provide is parallelism of user commands.

See http://stackoverflow.com/questions/10489298/redis-is-single-threaded-then-how-does-it-do-concurrent-i-o/10495458#10495458

Regards,

Didier.

[Marc Gravell]

If there is one thing I can't criticise redis on, it is raw performance. Even when we're hammering redis aggressively, it barely registers CPU. The new addition of SCAN operators avoids one of the few remaining "killer operations" (KEYS). So what if to do? If you want more CPU usage, use more nodes (each kinda-single threaded), possibly also spreading read operations over slaves.

Marc

--

[Matt Palmer]

On Fri, Jan 31, 2014 at 07:10:37AM -0800, KARTHICK VIJAYAYAKUMAR wrote:
> If we have concurrency ( more than one thread ), redis will respond more
> faster.

As the wikipedians say, "[Citation Needed]". The locking associated with
threads has been shown time and again to *decrease* throughput and increase
response latency, and the additional code complexity, memory consumption,
and CPU cycles of lockless data structures and algorithms are unlikely to
offset any request latency benefits, especially given that Redis is pretty
smokin' fast already.

- Matt

--
If only more employers realized that people join companies, but leave
bosses. A boss should be an insulator, not a conductor or an amplifier.
-- Geoff Kinnel, in the Monastery