Tell HN: We've built a high-performance persistent cache engine
5 comments
Could you compare with memcached etc, and describe some usecases where your solution would be much superior?
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.
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.
In what ways are you better than memcachedb? Since they're free and you're not?
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!
- 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!
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?
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?
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.
- 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.
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.
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.
> 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.
This is a very sound piece of advice. You should give it a serious thought.
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.
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.
Can you tell us a bit more about what products wrpme is similar to and why it is better, and how it works?
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...
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...
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?
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!".
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!".
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.
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
Having benchmarks is our #1 priority
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.
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.
An URL on which you can click:
http://www.wrpme.com/
http://www.wrpme.com/
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.