couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Smith <>
Subject Re: Erlang vs JavaScript
Date Thu, 15 Aug 2013 06:08:38 GMT
On Thursday, August 15, 2013, Andrey Kuprianov wrote:

> Doesnt server performance downgrade, while views are being rebuilt? So the
> faster they are rebuilt, the better for you.

If my view build would degrade total performance to cross an unacceptable
threshold, then I am really riding the line! What about an unplanned
compaction? What if one day the clients have a bug and load increases? What
if an unplanned disaster happens and a backup must be performed urgently?

I would evaluate view performance in the larger context of the entire
application life cycle.

Men seem to want to date beautiful women. It is a very high priority at the
pub or whatever. But long-married men do not even think about their wife's
attractiveness because that is a small, superficial part of a much larger

> Besides, looks like it's possible to do the same 3 steps with design doc
> views created in Erlang? Or is it just about using require() in Node.js?

Actually, yes that is a fine point. I myself prefer Node.js but anyone can
choose the best fit for them.

And speaking more broadly, CouchDB is a very flexible platform so it is
quite likely that my own policies do not apply to every use case. In fact
if I'm honest I use native views myself, usually for unplanned
troubleshooting, I want to find conflicts so I use manage_couchdb:

My main point is, anybody time somebody says "performance" ask yourself if
it is really a "performance siren." Earlier in this thread, Jens raises
some examples of plausible true performance requirements, not just siren

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message