Hi, On Thu, Nov 12, 2015 at 10:37 PM, Giovanni Lenzi <g.le...@smileupps.com> wrote: >>> * .info object generation steals 1-2ms even on very powerful machines > > the only attribute we used so far was the db_name. Is db_name generation > slow too?
No, slow is gathering all the stats. Especially in cluster. The db_name you can get from req.userCtx without problem. > This said, if db_name generation isn't too heavy, I'm inclined to say: > remove every attributes, but leave db_name It's hard to say who uses this property, but it certainly wouldn't be simple to just remove it. I like the idea to make it lazy one: this will preserve BC, but will make life better for those who really uses it. >>> As for .form object, it seems more reasonable to parse .body right inside > Spidermonkey. Moreover, it could be done in lazy manner – using getter > proxy. It means .form property in .req object should be defined as a getter > function, that parses .body only when .form is accessed. > > Totally agree. If it has performance impact, .form reconstruction should be > left to app developer who exactly knows when he needs it > Agree here. However, again for BC lazy property is a solution. req.form is potentially more popular than req.info, so it'll be need to be careful with. > Also I was wondering how heavy could be to include some kind of machine > identifier(hostname or ip address of machine running couchdb) inside of the > request object? What is use case for this? Technically, req.headers['Host'] points on the requested CouchDB. > Or if you want to make it even more flexible: how heavy could be to include > a configuration parameter inside of the request object? > > That could be of great help in some N-nodes master-master redunded database > configurations, to let one node only(the write node) handle some specific > background action. Can you describe this problem a little bit more? How this configuration parameter could be used and what it will be? -- ,,,^..^,,,
