LRU queue or heap data structure implementation?
Thu Nov 24 06:15:00 CET 2005
Richard Cameron wrote:
> ... so this sounds like a purely in-memory database where each "row"
> of data is actually a process, with a mind of its own. I'm sure if
> you took that to its logical conclusions you could build a
> particularly wacky variant of a relational database (where foreign
> keys between "rows" are paths you can send messages over).
Hmm, a little further than I was thinking. I forgot to put the
assumptions I thought I read from your post and a browse of your website:
1) Most accesses are read accesses only
2) You want to retrieve data from database and wrap it in HTML for delivery
3) You would like to lighten the load on your server
4) Updates could be more costly to the user
1-3 can be gotten by one retrieval from the DB starting a process which
prepares the HTML. Subsequent request just return the same HTML (or a
slight variant) directly from the running process without visiting the
4 requires killing the HTML process, updating the database as now and
respawning the process as a new request.
Timeouts just free memory occupied by previously spawned and wrapped
HTML tidbits from the database. If no one has requested them recently,
you can safely throw them away. The timeout time should be relative to
the construction time, CPU effort and frequency of user requests, with
an eye towards the amount of memory consumed. Frequently visited pages
that don't change often (e.g., FAQ page) can be "pinned" to the cache so
they aren't killed unless the data is stale.
More information about the erlang-questions