Skip to content

Commit c88d316

Browse files
committed
README
1 parent 7675048 commit c88d316

File tree

1 file changed

+240
-0
lines changed

1 file changed

+240
-0
lines changed

README.md

+240
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,240 @@
1+
# Least Recently Used
2+
Potent implementation of LRU algorithm with support of common counter up to once quadrillion hits.
3+
4+
5+
Reference Guide
6+
===============
7+
8+
## description
9+
This is implementation of LRU algorithm with support of common counter up to once quadrillion hits.
10+
11+
#### tasks:
12+
13+
* Algorithm accumulates any actions by keys in outside system.
14+
* Algorithm executes fetching keys for follow deletion from outside system.
15+
16+
#### more:
17+
18+
* https://en.wikipedia.org/wiki/Cache_replacement_policies#Least_recently_used_(LRU)
19+
20+
#### notes:
21+
##### note №1:
22+
Note that the implementation of algorithm support two interaction modes:
23+
24+
###### internal
25+
26+
like OTP application into your Erlang node
27+
28+
###### external
29+
30+
like daemon into your Unix-like OS
31+
32+
But actually nothing forbidens to interact in both modes at same time.
33+
34+
35+
##### note №2:
36+
Note that the implementation of algorithm stores keys in binary, that is, for set of keys from the first example bellow key will be stored as in second example:
37+
38+
###### example №1
39+
40+
<<"moscow">>
41+
["moscow"]
42+
"moscow"
43+
moscow
44+
45+
###### example №2
46+
47+
<<"moscow">>
48+
49+
50+
## launch options
51+
52+
[{lru,[
53+
{ets_dir,"priv"}, %% !!! must be string type !!!!!
54+
{ets_sync_reset,true}, %% !!! must be atom type !!!!!
55+
{ets_recovery,true}, %% !!! must be atom type !!!!!
56+
{tcp,on}, %% !!! must be atom type !!!!!
57+
{mode,inet}, %% !!! must be atom type !!!!!
58+
{port,7777}, %% !!! must be atom type !!!!!
59+
{ip,{127,0,0,1}}, %% !!! must be tuple type !!!!!
60+
{unix,"/var/run/lru/unix"}, %% !!! must by string type !!!!!
61+
{num_acceptors,100}, %% !!! must by integer type !!!!!
62+
{max_connections,1024}, %% !!! must by integer type !!!!!
63+
{max_key_size,72} %% !!! must be integer type !!!!!
64+
]}].
65+
66+
#### ets_dir
67+
path to directory storage ets-tables, relative to the root directory of application
68+
69+
#### ets_sync_reset
70+
it ensures that the content of the state is written to the disk
71+
72+
#### ets_recovery
73+
it ensures that lru launches with prev state
74+
75+
#### tcp
76+
on or off support of ranch interaction, by default is off
77+
78+
#### mode
79+
mode work: inet|unix
80+
by default is inet
81+
82+
#### port
83+
port, by default 7777
84+
85+
#### ip
86+
ip, by default 127.0.0.1
87+
88+
#### unix
89+
unix_socket, by default '/var/run/lru/unix'
90+
91+
#### num_acceptors
92+
excerpt from 'ranch' documentation:
93+
94+
By default Ranch will use 10 acceptor processes. Their role is to accept connections and spawn a connection process for every new connection.
95+
This number can be tweaked to improve performance. A good number is typically between 10 or 100 acceptors. You must measure to find the best value for your application.
96+
97+
#### max_connections
98+
excerpt from 'ranch' documentation:
99+
100+
The max_connections transport option allows you to limit the number of concurrent connections per connection supervisor (see below).
101+
It defaults to 1024. Its purpose is to prevent your system from being overloaded and ensuring all the connections are handled optimally.
102+
103+
You can disable this limit by setting its value to the atom infinity.
104+
105+
The maximum number of connections is a soft limit. In practice, it can reach max_connections + the number of acceptors.
106+
107+
When the maximum number of connections is reached, Ranch will stop accepting connections.
108+
This will not result in further connections being rejected, as the kernel option allows queueing incoming connections.
109+
The size of this queue is determined by the backlog option and defaults to 1024. Ranch does not know about the number of connections that are in the backlog.
110+
111+
#### max_key_size
112+
max key size
113+
114+
## quick start
115+
#### like OTP application into your Erlang node
116+
117+
erl -config lru.config
118+
application:start(lru)
119+
120+
#### like daemon into your Unix-like OS
121+
122+
mkdir release
123+
tar -xf priv/lru.tar.gz -C release/
124+
125+
cp priv/lru.tar.gz release/.
126+
cp priv/init release/.
127+
cp priv/stop release/.
128+
129+
cd release
130+
131+
mkdir bin
132+
mkdir log
133+
mkdir pipe
134+
135+
cp erts-11.1/bin/start.src bin/start
136+
cp erts-11.1/bin/start_erl.src bin/start_erl
137+
cp erts-11.1/bin/run_erl bin/.
138+
cp erts-11.1/bin/to_erl bin/.
139+
cp erts-11.1/bin/erl bin/.
140+
cp erts-11.1/bin/heart bin/.
141+
cp erts-11.1/bin/escript bin/.
142+
143+
perl -i -pe "s#%FINAL_ROOTDIR%#$PWD#" bin/start
144+
145+
sed -i 's/\/tmp/$ROOTDIR\/pipe/' bin/start
146+
sed -i 's/\(.*run_erl.*\)".*$/\1 -sname lru -init_debug +t 10485760\"/' bin/start
147+
148+
echo "11.1 1" > releases/start_erl.data
149+
150+
./init startd
151+
./init stop
152+
153+
154+
## client interface
155+
###### This section describes two types interfaces:
156+
157+
internal - erlang interface for inner interaction in Erlang node
158+
external - outside interface for interaction from the world outside
159+
160+
#### put key
161+
###### internal:
162+
163+
lru:point(K). ok
164+
165+
###### external:
166+
167+
POINT:key %% "OK"
168+
169+
#### get counter on key
170+
###### internal:
171+
172+
lru:count(K). %% counter
173+
174+
###### external:
175+
176+
COUNT:key %% "NUMBER"
177+
178+
#### get oldest counter, current counter and quantity of keys
179+
###### internal:
180+
181+
lru:state(). %% [oldest counter,current counter,quantity of keys]
182+
183+
###### external:
184+
185+
STATE %% JSON: "{O:NUMBER,C:NUMBER,Q:NUMBER}"
186+
187+
#### store algorithm state to disk
188+
###### Please, pay attention 'store' call executes asynchronously!
189+
###### internal:
190+
191+
lru:store(). %% ok
192+
193+
###### external:
194+
195+
STORE %% "OK"
196+
197+
#### get oldest key and its counter
198+
199+
lru:fetch(). %% {counter,[<<"key">>]}
200+
201+
###### external:
202+
203+
FETCH %% JSON: "{counter:[key]}"
204+
205+
#### get and delete oldest key and its counter
206+
#### without confirm
207+
###### internal:
208+
209+
lru:clean(). %% {counter,[<<"key">>]}
210+
or
211+
lru:clean(async). %% {counter,[<<"key">>]}
212+
213+
###### external:
214+
215+
CLEAN %% JSON: "{counter:[key]}"
216+
or
217+
CLEAN:ASYNC %% JSON: "{counter:[key]}"
218+
219+
#### get and delete oldest key and its counter
220+
#### with confirm
221+
###### Please, pay attention timeout exists to confirm, equal '90' seconds by default
222+
###### internal:
223+
224+
{K,R} = lru:clean(sync). %% {{counter,[<<"key">>]},ref()}
225+
lru:clean(R,K). %% ok
226+
227+
###### external:
228+
229+
CLEAN:SYNC %% JSON: "{[{counter:[key]}]:UNIQ_REF}"
230+
CLEAN:UNIQ_REF %% "OK"
231+
232+
#### put list keys with conters
233+
###### initialization of state, for example, transfer of state from other implementation 'lru'
234+
###### internal:
235+
236+
lru:cheat([{K1,C1},{K2,C2},{K3,C3}]). %% ok
237+
238+
###### external:
239+
240+
CHEAT:key1,counter1;key2,counter2;key3,counter3 %% OK

0 commit comments

Comments
 (0)