Github user janl commented on the pull request:
https://github.com/apache/couchdb-couch/pull/57#issuecomment-114069858
> Suggestion: let's not rush now with optimizations. Let's first make solid
reproduceable benchmark suite that covers at least all the basic CouchDB
Weâve been wanting this for years. We canât block optimisations because
we donât have it. I agree we should have it, and anyone working on this is
more than welcome to, but blocking major (imho > 1%) is not a good idea.
> > I don't see many people working on a new log format and given that the
tickets are around 4 years old
> Because they didn't have such opportunity for all these 4 years, because
they all being waited for better logging system that supports this feature?
Iâm with @robertkowalski here, letâs not block this. These issues have
never had much interest. IIRC, I just filed this, because I had one person in a
workshop asking for this. It has never been a substantial problem.
> Shouldn't we propose fix for lager instead?
There are multiple types of ways to address issues. @robertkowalski is
proposing a short-term fix. @kxepal suggest a long-term fix. That is, if we get
lager to speed up, that would be desirable. In the meantime, if we can get a 4%
speed increase by being smarter with logging, thatâs a win in my book.
> It has no effect on public :5984 port since there chttpd is being
requested, not couch_httpd
There are plenty of APIs where chttpd calls through to couch_httpd.
Although I donât know how that affects logging, we certainly donât get two
entries. We should check if this optimisation applies.
Generally, the observation about `5984` vs. `5986` is a good one, though.
We should look at optimising the former, not the latter.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
