<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
<br>
<br>
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
On 09/07/2010 02:37 PM, Russell Bryant wrote:
<blockquote cite="mid:1283884654.30774.5433.camel@milo.digium.internal"
type="cite">
<pre wrap="">On Mon, 2010-09-06 at 09:10 -0400, Mark Murawski wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Spawn an astdb put worker thread. (Same goes for using any database
backend) Writers will dump their changes to a linked list and return
immediately. The writer will write whenever it gets a chance. if there
are big or small slowdowns in fsync it wont affect any running threads.
And if you lose power, well... you would have lost the unwritten data
anyway because you would have been waiting on it anyway.
</pre>
</blockquote>
<pre wrap="">That would work if the vast majority of operations were writes.
However, there are probably more of an even number of reads and writes
to astdb. Even if you queue up the writes, the readers are going to
have to wait until all of the writes that came before are done before
the read operation can be executed, resulting in an even worse slowdown
on reads, even though the writes are (probably) faster.
</pre>
</blockquote>
<font size="+1"><br>
<br>
What about my suggestion before? You can queue up the writes for as
long as you need to... but when the readers go and get a key from
astdb, you traverse the write queue first.<br>
<br>
</font>
</body>
</html>