> All dummy requests can be blocked before getRow call No. Map function call costs. Serialization costs. Deserialization costs. Parsing request costs.
Giovanni, let me tell you my story in short – you are so passionate in advocating couchapps as I was 4 years ago ) When I discovered CouchDB, I was fascinated how simple and clean the idea is. First feeling was "Why the heck LAMP is still alive?". Second – "Why Mongo is still here?". But when I made measurements I understood, why. Unique features of CouchDB are: 1. Replication that can fly smoothly for years (I have several) 2. Cached map indexes and reduce optimizations 3. Attachments and their versioning (need it badly in Pouch) 4. HTTP availability 5. Flexible list functions, that can transform map results – you even can send code in your request 6. Changes feed CouchDB weak sides are: 1. HTTP stack is very expensive and limits throughput 2. Log does not rotate (very serious vulnerability) 3. Ineffective map>>list mechanism 4. No fulltext search or equivalent (some kind of Bloom filter maybe) 5. No per-doc read ACL CouchDB shows its full power when you employ its strength and cover weakness. There exist simple and robust ways to cover weakness – they all are external. And there exist complex, brittle and slow ways – they all are about ‘Lets use CouchDB for everything’. You have chosen latter – ok, you made best couchapp environment I‘ve ever seen, and your docs are very nice. But you can not jump over your head. This architecture spends CPU in vain and is somehow vulnerable. And even these results take enormous effort and precise configuration. Couchapp is not a silver bullet. Just face it – as I did. Use it in friendly environment for small systems of low capacity – it fits more or less well. For more complex systems put middleware in front of CouchDB – save your time and money. And no need to be sly telling security by obscurity is industry standard )) ermouth