HN Explorer

Tell HN: We've built a high-performance persistent cache engine

14 points by shin_lao ↗ HN
Hello hners!

I'm pleased to inform you that we're releasing into the wild a high-performance cache engine.

It's called wrpme and it's got a nice logo!

http://www.wrpme.com/

We've been working on the beast for a while now and it's been used with success on very demanding applications (hint: it's high frequency and it's commonly regarded as the root of all evil).

Key features:

- fast

- scalable

- persistent

- low-maintenance

- multi-platforms (FreeBSD, Linux & Windows)

- low fat, low sugar!

We're keen on having your feedback, whether you think it's totally useless or the greatest software ever written.

19 comments

[ 3.8 ms ] story [ 47.2 ms ] thread
akanet
Can you tell us a bit more about what products wrpme is similar to and why it is better, and how it works?
shin_lao
wrpme is similar to memcachedb.

We believe it's better because it's faster. It's also using a binary protocol for reduced bandwidth usage. Many caches uses text or xml to transmit data.

The design is highly asynchronous and designed to work on a 64-bit multiprocessor computer.

wrpme is actually a collection of mini daemons (we call them nanodaemons) that execute simple tasks and communicate via messages. It's been inspired by microkernel operating systems.

http://en.wikipedia.org/wiki/Vanguard_%28microkernel%29#V_me...

scorpioxy
Interesting.

What also would be interesting is what made you release this as a commercial solution when so many similar free and open source solutions exist?

shin_lao
A genuine question!

- We're faster than memcached and redis (benchmark coming soon). When I say faster I mean really faster not "10 % faster".

- We work on Windows out of the box - a real plus in a commercial context

- We offer support for our software (yeah, seriously!)

- We scale well on multi-processor machines. AFAIK that's not the case of open source solutions (it's even by design in the case of redis).

There's still much to do to improve our offer and we're working on it.

bmelton
It looks good, and solid. Ignoring the salesy-ness of your posts, it sounds like you've got a feature-set worth charging for.

That said, if you have trouble getting initial traction, you might consider giving it away and charging for support / services. This will allow customers to try it out freely, get used to it, and if they like it, become hooked. This tactic has worked for 10gen and crack dealers everywhere.

You can always charge for the software later, of course; but I think the general opinion of memcache is that it's "good enough", so supplanting it may prove non-trivial.

Oh, and your logo really is quite nice indeed.

sagacity
> if you have trouble getting initial traction, you might consider giving it away and charging for support / services.

This is a very sound piece of advice. You should give it a serious thought.

shin_lao
Thanks for your comments!

You already can try and evaluate it for free.

Getting traction is difficult, whatever software you're making. We'll probably have to do a free version, you're right.

petervandijck
Could you compare with memcached etc, and describe some usecases where your solution would be much superior?
shin_lao
Basically wrpme is currently like memcachedb. We don't have some features such as atomic increments and the like at the moment (and we may never have them).

We're much faster than memcached on a multi-processor machine but we're working on a meaningful benchmark. It would be easy to produce a benchmark where we're 10 x faster and that would demonstrate nothing.

We aim at being faster in all usecases. Show us when we are slower and we will fix it.

petervandijck
In what ways are you better than memcachedb? Since they're free and you're not?
shin_lao
Objective reasons:

- faster (especially on 64-bit multiprocessor machines)

- works on Windows out of the box

- scalable on multi-processor machines

- support

Download a version and see for yourself!

eengstrom
Is this technology being used anywhere commercially or with intent for commercial use? Can you also quantify how long/roughly how many thousands of hours of effort this has been in development?
shin_lao
Yes, it's currently used by two of our customers for grid computing applications.

Development started in late 2009 but there was a couple of "let's redo this part" and "ho, wait, it's never going to work!".

eengstrom
Have you had a chance to measure operational throughput vs hardware utilization yet? I'd be very interested in loose metrics and stats instead of a general "faster than" statement.
shin_lao
We manage to saturate the memory bandwidth. We can do 3,000,000 get / sec on a Core i7 machine with entries of roughly 1 kib in size.

Having benchmarks is our #1 priority

eengstrom
Sorry for my slow response; how does the process handle scaling above 1kb? Traditionally there's a predictable curve of expected performance as the scale of request size increases.

Happy to take this conversation private; spent the last 10 years in performance and scalability as a indie consultant for Fortune companies. I know a lot of people looking for replacement mechanisms for high volume, variable sized transaction enterprise buses.

Also interested to understand the data access methods you've tested and what works best with your code. eengstrom >at< gmail.