<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 1/28/12 4:18 PM, Matthew Evans wrote:
<blockquote cite="mid:SNT125-W453262C5564166AA7FA8549C8F0@phx.gbl"
type="cite">
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
<div dir="ltr">
<br>
<div>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. </div>
<br>
</div>
</blockquote>
This would be my first idea. Create an ETS table being protected.
Writes to the table goes through the gen_server,<br>
<br>
-export([write/1, read/1]).<br>
<br>
write(Obj) -><br>
call({write, Obj}).<br>
<br>
call(M) -><br>
gen_server:call(?SERVER, M, infinity).<br>
<br>
but reads happen in the calling process of the API and does not go
through the gen_server at all,<br>
<br>
read(Key) -><br>
case ets:lookup(?TAB, Key) of<br>
[] -> not_found;<br>
[_|_] = Objects -> {ok, Objects}<br>
end.<br>
<br>
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.<br>
<pre class="moz-signature" cols="72">--
Jesper Louis Andersen
Erlang Solutions Ltd., Copenhagen, DK</pre>
</body>
</html>