[erlang-questions] Slow when using chained gen_server:call's, redesign or optimize?

[Jesper Louis Andersen]

On 1/28/12 4:18 PM, Matthew Evans wrote:
>
> The obvious, and maybe non-OTP, answer is to hold some of this state 
> information in a public or protected named ETS table that your clients 
> read from directly. A single gen_server can still own and write to 
> that ETS table.
>
This would be my first idea. Create an ETS table being protected. Writes 
to the table goes through the gen_server,

-export([write/1, read/1]).

write(Obj) ->
   call({write, Obj}).

call(M) ->
   gen_server:call(?SERVER, M, infinity).

but reads happen in the calling process of the API and does not go 
through the gen_server at all,

read(Key) ->
   case ets:lookup(?TAB, Key) of
     [] -> not_found;
     [_|_] = Objects -> {ok, Objects}
   end.

Creating the table with {read_concurrency, true} as the option will 
probably speed up reads by quite a bit as well. It is probably going to 
be a lot faster than having all caching reads going through that single 
point of contention. Chances are that just breaking parts of the chain 
is enough to improve the performance of the system.

-- 
Jesper Louis Andersen
   Erlang Solutions Ltd., Copenhagen, DK

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120128/e4aa3381/attachment.htm>