<br><br><div class="gmail_quote">On Wed, Jan 23, 2013 at 5:47 AM, Maxim Dounin <<a href="mailto:mdounin@mdounin.ru">mdounin@mdounin.ru</a>> wrote:<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

I don't think that it will fit as a cache store for nginx.  In<br>
particular, with quick look through sources I don't see any<br>
interface to store data with size not known in advance, which<br>
happens often in HTTP world. </blockquote><div><br></div><div>Yes, ybc doesn't allow storing data with size not known in advance due to performance and architectural reasons. There are several workarounds for this problem:</div>
<div>- objects with unknown sizes may be streamed into a temporary location before storing them into ybc.</div><div>- objects with unknown sizes may be cached in ybc using fixed-sized chunks, except for the last chunk, which may have smaller size. Here is a pseudo-code:</div>
<div>store_stream_to_ybc(stream, key, chunk_size) {</div><div>  for (n = 0; ; n++) {</div><div>    key_for_chunk = get_key_for_chunk(key, n);</div><div>    chunk_txn = start_ybc_set_txn(key_for_chunk, chunk_size);</div><div>
    bytes_copied = copy_stream_to_set_txn(stream, chunk_txn);</div><div>    if (bytes_copied == -1) {</div><div>      // error occurred when copying data to chunk_txn.</div><div>      rollback_set_txn(chunk_txn);</div><div>
      return ERROR;</div><div>    }</div><div>    if (bytes_copied < chunk_size) {</div><div>      // the last chunk reached. Copy it again, since we know its' size now.</div><div>      last_chunk_txn = start_ybc_set_txn(key_for_chunk, bytes_copied);</div>
<div>      copy_data(last_chunk_txn, cunk_txn, bytes_copied);</div><div>      rollback_set_txn(chunk_txn);</div><div>      commit_set_txn(last_chunk_txn);</div><div>      return SUCCESS;</div><div>    }</div><div><br></div>
<div>    // there is other data in the stream.</div><div>    commit_set_txn(chunk_txn);</div><div>}</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Additionally, it looks like it<br>
doesn't provide async disk IO support.<br></blockquote><div><br></div><div>Ybc works with memory mapped files. It doesn't use disk I/O directly. Disk I/O may be triggered if the given memory page is missing in RAM. It's possible to determine whether the given virtual memory location is cached in RAM or not - OSes provide special syscalls designed for this case - for example, mincore(2) in linux. But I think it's better relying on caching mechanisms provided by OS for memory mapped files than using such syscalls directly. Ybc may block nginx worker when reading swapped out memory pages, but this should be rare event if frequently accessed cached objects fit RAM.</div>
<div> </div><div>Also as I understood from the <a href="http://www.aosabook.org/en/nginx.html">http://www.aosabook.org/en/nginx.html</a> , nginx currently may block on disk I/O too:</div><div><br></div>> One major problem that the developers of nginx will be solving in upcoming versions is</div>
<div class="gmail_quote">> how to avoid most of the blocking on disk I/O. At the moment, if there's not enough</div><div class="gmail_quote">> storage performance to serve disk operations generated by a particular worker, that</div>
<div class="gmail_quote">> worker may still block on reading/writing from disk.</div><div class="gmail_quote"><br></div><div class="gmail_quote">-- </div>Best Regards,<br><br>Aliaksandr