4 ms·

Well, compared to all the products you named we're... - faster - designed for 64-bit from the ground up - scalable on multi core machines - portable - Windo

Well, compared to all the products you named we're... - faster - designed for 64-bit from the ground up - scalable on multi core machines - portable - Windows, Linux, FreeBSD - out of the box - persistent out of the box - very easy to install and deploy (ok memcached is very easy to install and deploy as well) - secure by default - come with support Redis, varnish and squid aren't really equivalent products. Memcacheddb is our closest equivalent. What do you think? Of course we're very keen on hearing more from you as we will offer a beta for download.

donw 17y ago
I'm going to be honest, and say that I've probably got no use for your product. Memcache is plenty fast enough (200k ops/sec without tuning) for our needs, is open-source, well-tested, free, and has bindings for a lot of different platforms. That said, you may want to look at the Windows market, as they don't have a native memcached, so that might give you some leverage. Windows shops are also more likely to spend money. I also read your FAQ, and it left me with a lot of questions: You claim to be faster than memcached, but don't provide any benchmarks to back those claims up. What evidence do you have to support your scalability claims? What language bindings do you offer? What do you mean by 'secure by default'?
- shin_lao 17y ago
  Thanks for your comments. memcached is a competitor, as is Oracle Coherence and Gigaspaces. memcached is a decent open source product, which appeals to a certain type of customers. We realize that there is a competition, but we think there is room for improvement. - no benchmark for now, we think it's too early, we'll do that during the beta. Our preliminary tests show we're at least twice faster and up to ten times faster. - we tested our cache's performance on a 12 cores machine, so we can only say "it scales up to 12 cores" - we offer out of the box a C language binding, PHP, Java, Ruby and Python - wrpme has been designed from the ground up with security in mind, the default install is secure, you need to manually activate the remote and administration features (if you need them)
  - donw 17y ago
    Fair enough; I can understand why you'd want to (a) tune, and (b) make sure your benchmarks are going to stand up to scrutiny. Regarding 'secure by default', though, your answer is very hand-wavy. Do you employ cryptography for your network protocol? On-disk crypto for persisted data? Authentication? How are credentials stored, assuming you do provide authentication? What steps have you taken to avoid buffer overflow attacks? These are all questions that customers will ask; be prepared to answer them.
    - shin_lao 17y ago
      Actually I was more referring to the hard work we do to avoid that kind of vulnerabilities by design: http://securitytracker.com/alerts/2010/Apr/1023839.html http://securitytracker.com/alerts/2010/Apr/1023839.html and http://securitytracker.com/alerts/2009/Apr/1022140.html http://securitytracker.com/alerts/2009/Apr/1022140.html Everything we do we consider security first and do threat modeling. All remote connections are done via TLS, we don't cipher the database on the disk but if there is a demand for it we'll add the feature. We've been extremely thorough to review the code an reduce the possibility for buffer overflows to occur. We use only safe API and validate input thoroughly. Buffers are encapsulated by a class in such a way that unsafe writing is difficult to do. I'm not claiming we'll never have an exploit, just saying we're doing the best we can to avoid it.
      - moe 17y ago
        I would say those are non-issues in most deployments. Application caches are normally deployed within an isolated, trusted environment. TCP connections from untrusted clients simply don't happen, so hardening is not needed at that level. I'm confused about what use-case you have in mind with this. Is your cache meant to be exposed to the general public, sort of like the things you can do with couchdb?
        shin_lao 17y ago
        We want indeed the software to be usable as a high-performance key/value storage system, which is why we think about security.
moe 17y ago
Well, what practical problem are you solving? All of them (except squid) are pretty trivial to deploy and have gone through years of optimization. It's a bit hard to believe you could beat them on performance by a margin large enough to make it worth paying money for. Have benchmarks?

donw 17y ago

I'm going to be honest, and say that I've probably got no use for your product. Memcache is plenty fast enough (200k ops/sec without tuning) for our needs, is open-source, well-tested, free, and has bindings for a lot of different platforms. That said, you may want to look at the Windows market, as they don't have a native memcached, so that might give you some leverage. Windows shops are also more likely to spend money. I also read your FAQ, and it left me with a lot of questions: You claim to be faster than memcached, but don't provide any benchmarks to back those claims up. What evidence do you have to support your scalability claims? What language bindings do you offer? What do you mean by 'secure by default'?

shin_lao 17y ago
Thanks for your comments. memcached is a competitor, as is Oracle Coherence and Gigaspaces. memcached is a decent open source product, which appeals to a certain type of customers. We realize that there is a competition, but we think there is room for improvement. - no benchmark for now, we think it's too early, we'll do that during the beta. Our preliminary tests show we're at least twice faster and up to ten times faster. - we tested our cache's performance on a 12 cores machine, so we can only say "it scales up to 12 cores" - we offer out of the box a C language binding, PHP, Java, Ruby and Python - wrpme has been designed from the ground up with security in mind, the default install is secure, you need to manually activate the remote and administration features (if you need them)
- donw 17y ago
  Fair enough; I can understand why you'd want to (a) tune, and (b) make sure your benchmarks are going to stand up to scrutiny. Regarding 'secure by default', though, your answer is very hand-wavy. Do you employ cryptography for your network protocol? On-disk crypto for persisted data? Authentication? How are credentials stored, assuming you do provide authentication? What steps have you taken to avoid buffer overflow attacks? These are all questions that customers will ask; be prepared to answer them.
  - shin_lao 17y ago
    Actually I was more referring to the hard work we do to avoid that kind of vulnerabilities by design: http://securitytracker.com/alerts/2010/Apr/1023839.html http://securitytracker.com/alerts/2010/Apr/1023839.html and http://securitytracker.com/alerts/2009/Apr/1022140.html http://securitytracker.com/alerts/2009/Apr/1022140.html Everything we do we consider security first and do threat modeling. All remote connections are done via TLS, we don't cipher the database on the disk but if there is a demand for it we'll add the feature. We've been extremely thorough to review the code an reduce the possibility for buffer overflows to occur. We use only safe API and validate input thoroughly. Buffers are encapsulated by a class in such a way that unsafe writing is difficult to do. I'm not claiming we'll never have an exploit, just saying we're doing the best we can to avoid it.
    - moe 17y ago
      I would say those are non-issues in most deployments. Application caches are normally deployed within an isolated, trusted environment. TCP connections from untrusted clients simply don't happen, so hardening is not needed at that level. I'm confused about what use-case you have in mind with this. Is your cache meant to be exposed to the general public, sort of like the things you can do with couchdb?
      - shin_lao 17y ago
        We want indeed the software to be usable as a high-performance key/value storage system, which is why we think about security.

moe 17y ago

Well, what practical problem are you solving? All of them (except squid) are pretty trivial to deploy and have gone through years of optimization. It's a bit hard to believe you could beat them on performance by a margin large enough to make it worth paying money for. Have benchmarks?