

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

Hello hners!<p>I'm pleased to inform you that we're releasing into the wild a high-performance cache engine.<p>It's called wrpme and it's got a nice logo!<p>http://www.wrpme.com/<p>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).<p>Key features:<p>- fast<p>- scalable<p>- persistent<p>- low-maintenance<p>- multi-platforms (FreeBSD, Linux &#38; Windows)<p>- low fat, low sugar!<p>We're keen on having your feedback, whether you think it's totally useless or the greatest software ever written.
======
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!

~~~
petervandijck
How does it compare to membase?

~~~
shin_lao
membase is based on memcache afaik

------
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.

------
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...](http://en.wikipedia.org/wiki/Vanguard_%28microkernel%29#V_messaging_semantics)

------
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.

------
shin_lao
An URL on which you can click:

<http://www.wrpme.com/>

