Ilya Grigorik

JNI allows one to write C code that bridges the gap between the Java VM and existing C libraries. That C code must be compiled, and must follow some rather tedious patterns (regarding method signatures and other little details). It’s a bit of a pain to write and compile, if all you want to do is quickly call some function from an existing C library.

Also, because symbol resolution is done at compile-time, this is a non starter for something like JRuby, wherein one would want to write plain Ruby code to call a C function — rather than writing Ruby, Java and JNI flavored C code. Ruby is an interpreted language, so calling into or out of C requires dynamic symbol resolution, and for the C->Ruby callback case, a closure must be created on the fly (that is, a C ABI function must be JIT compiled for that method or proc). This isn’t particular to Ruby — any interpreted language will run into this issue on the JVM (picture Python and its ctypes and/or cffi libraries).

You can see some of the hoops that JRuby had to jump through to support this use case, in order to provide a JRuby implementation of the ‘ffi’ gem interface:

https://javadoc.io/doc/org.jruby/jruby-core/9.2.13.0/org/jruby/ext/ffi/FFI.html

https://www.igvita.com/2009/01/15/bridging-mri-jruby-rubinius-with-ffi/

It’s been a minute, so my recollection may be wrong, but IIRC JRuby uses Java and JNI to call into a C shim that then calls into libffi to handle things like creating C ABI conforming closures and such on the…

Sorry for the delay, I just now saw that somebody had replied. Regarding links to the systems- the only one that was ever publicly accessible was for a Facebook app that I wrote some years back that was let researchers post links to their publications on their profiles, and also featured a recommendation system to find other users of the app that had "similar" publications. It's unfortunately fallen into a pretty sorry state of disrepair, as I haven't had any time to devote to maintenance in more than two years and Facebook's APIs have changed quite a bit since then. I described the underlying system a little bit in a conference paper: http://view.ncbi.nlm.nih.gov/pubmed/18999247

The other systems I've used the approach for have all been along either bibliometric/bibliographic lines, or have been relating to content-based image retrieval. It's a pretty robust approach, but can take a little bit of tuning to get just right- coming up with a good evaluation strategy is important to getting the most out of it, I've found.

As far as references that were useful:

Ilya Grigorik has a very accessible getting-your-feet-wet tutorial on his site: http://www.igvita.com/2007/01/15/svd-recommendation-system-in-ruby/

It might be a little dated w.r.t. specific libraries or APIs, but the basic technique is there. For a more comprehensive look at the SVD-IR approach, take a look at:

Berry et al. Using Linear Algebra for Intelligent Information Retrieval. SIAM Review (1995) vol. 37 (4)…

> Unless you control the TLS terminators

Nope, this is all about trusting vendors. Unless you're building your own computer chips and laying your own fiber, you're just blaming a vendor for what seems like personal issues.

> problem is generally not in the network latency

Again years of research has shown this is one of the biggest issues on the web. Read https://www.igvita.com/ for some good info.

> Yes, both technically use reverse proxying technology in their stack, but in the end they are completely different approaches.

Nope, this clearly shows you don't have any understanding. CF is a CDN. That's it. Instead of like other CDNs that offer a CNAME that you point your DNS to, they just offer a free DNS service that automates the CNAME entry into a single button.

All CDNs today are reverse proxies that will either return a cached response or proxy the request to the origin if the cache is empty. You can also use every CDN to proxy dynamic requests and many do. And yes, there are a few that offer a push model where you upload assets explicitly but this is the exception, not the standard.

You're talking about CF as if they're something unique when they do exactly the same thing as everyone else. Use them on a subdomain if you want and leave the main domain unproxied, use them only for static files or for dynamic requests, use them to proxy everything or cache everything including HTML. It's all just configuration. Why is this such a problem for you?

Antirez mentions that a limited set of on-disk data structures could work well but that it will take one or two years to even reach the drawing board. Fair enough -- Redis is first and foremost an in-memory database.

If there was the time though, I'd love to see LevelDB[1] merge the gap between in-memory and on-disk. Inspired by Google's BigTable, all keys are kept sorted on disk (see: SSTable[2]). Keys, lists, sets, sorted sets and hashtables could be encoded in sorted key-value form and would be reasonably (though not tremendously) efficient to retrieve, especially if the query can be converted to a range query (i.e. list retrieval or set intersection). Keep hot data in memory, the rest ends up securely on disk.

Yes, Cassandra is based on the same lineage but it's not simple or clean to operate. Redis is a pain free setup, features a simple API but has no transparent way to overflow to disk for cold data. LevelDB is an optional backend for Riak but I must admit I've not explored Riak heavily... Have I missed a contender from another database crowd?

[1]: http://code.google.com/p/leveldb/
[2]: http://www.igvita.com/2012/02/06/sstable-and-log-structured-storage-leveldb/

On the other hand, what's the problem in using TLS for cases you don't think it useful ? I can see a few reasons here, but I don't see any of them being enough not to use TLS everywhere:

- TLS is expensive: my gut says it's wrong, but I'd love to see some numbers. Ilya Grigorik [0] has done some experiments here, and I don't see TLS as really bad

- TLS is complicated: true, and we have to rely on tried and tested implementations. I'd say you'd need to do it whatever security we use (and we want security, right?)

- TLS requires certificates from the flawed CA infrastructure we have: wrong, public-key authentication isn't even the only authentication scheme possible with TLS, it's just the first one we think about (and also the most tested one).

Do you have other counter-arguments ?

[0] https://www.igvita.com/2013/12/16/optimizing-nginx-tls-time-to-first-byte

this has been a great set of blog posts.

since your covering all the bases. you should look at the bloom filters.

something like this could work and be created on the server.

http://dren.ch/js-bloom-filter/

(not the newest post has a compatible perl and ruby impl)

Ilya Grigorik has a couple of relevant posts

http://www.igvita.com/2008/12/27/scalable-datasets-bloom-filters-in-ruby/

and

a ruby + redis backend.

https://github.com/igrigorik/bloomfilter

here are some of the memory footprints that Ilya got

* 1.0% error rate for 1M items, 10 bits/item: 2.5 mb
* 1.0% error rate for 150M items, 10 bits per item: 358.52 mb
* 0.1% error rate for 150M items, 15 bits per item: 537.33 mb