Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of andrey.kouprianov@gmail.com
 designates 209.85.212.50 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CACLy94Uq9eafd_Q-LXV8b3aCipnHgMnaWdn2C1LjnvuMQ-csiA@mail.gmail.com>
References: 
 <CAPNuaCjQ3wgAd1BMyNUtip0rztK6n3Ex3rnq-hc=NXwL4Wt+pg@mail.gmail.com>
 <CAG+HO1ysanHLAYTh5XXuN=WO3RMsjxsY9c5nXjGiHy1n_m74mA@mail.gmail.com>
 <CAPNuaCjTS1+GAqx=WG0qjiP+3Rc06bXbSFDc9jdvHOOZwWY+3g@mail.gmail.com>
 <CAG+HO1x+L2rKTXaVcuu2_n0FQW_5CWZ7Jk5qo96-8OK-sRU7XA@mail.gmail.com>
 <CAPNuaCh5qK2YxS0txBicvrc4fnQCgrj5pVz=_M0xqXaKfQyYjg@mail.gmail.com>
 <CAG+HO1w+N_TxeroFpKwY+U=G2iC6eEU2QMDbV9aGgueDsZ5Bcg@mail.gmail.com>
 <CACLy94Uq9eafd_Q-LXV8b3aCipnHgMnaWdn2C1LjnvuMQ-csiA@mail.gmail.com>
From: Andrey Kuprianov <andrey.kouprianov@gmail.com>
Date: Thu, 15 Aug 2013 11:18:45 +0700
Message-ID: 
 <CAG+HO1zySzJyQMnSj9hfeHVR-XNB2Hpqr97A5ugabvo-wGKdXg@mail.gmail.com>
Subject: Re: Erlang vs JavaScript
To: user@couchdb.apache.org
Content-Type: multipart/alternative; boundary=089e0149ca3a4b6e1e04e3f4c606

--089e0149ca3a4b6e1e04e3f4c606
Content-Type: text/plain; charset=ISO-8859-1

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

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?


On Thu, Aug 15, 2013 at 10:52 AM, Jason Smith <jhs@apache.org> wrote:

> The time complexity of Erlang vs. JavaScript views is the same, O(n) where
> n is the document count.
>
> View building time feels important during development but it is irrelevant
> during operation. Production servers never hold up requests to build views,
> so the performance is secondary. For very important views, I prefer
> JavaScript because I can unit test them with Node.js. I don't care how long
> the view takes if I am not confident about correctness.
>
> In practice, to use views in production, I use the "PPP trick" (Push, Prep,
> Promote).
>
> ## Push
>
> 1. Use Node.js to require() my code and run some unit tests on map() and
> reduce()
> 2. Push the new design document to the server with a new, temporary ID,
> e.g. _design/foo-staging
>
> ## Prep
>
> 1. Query the view and wait for it to build
> 2. (Prep) Confirm the view output, manual or automated. I use more Node.js
> tests here
>
> ## Promote
>
> 1. curl -I <new_id> ; curl -I <old_id> # Upper-case India
> 2. Note the new etag and old etag (they are the documents' _rev values)
> 3. curl --fail -XCOPY <new_id>?rev=<new_rev>
> -HDestination:<old_id>?rev=<old_rev> \
>     && curl -XDELETE <new_id>?rev=<new_rev> # Promote
>
> Note that the final step is an atomic operation. From the perspective of
> CouchDB clients, you perform an (a) instantaneous upgrade, which is (b)
> known to be bug-free, with (c) zero downtime.
>
> Obviously you can automate this procedure as needed. I do not update design
> documents much anymore, so I still use curl in a Bash script. YMMV.
>
>
> On Thu, Aug 15, 2013 at 10:25 AM, Andrey Kuprianov <
> andrey.kouprianov@gmail.com> wrote:
>
> > Yups, also true.
> >
> > In any case, we'll also be moving towards using Erlang-based design docs
> > now. Javascript is great for starters, but once you hit several dozen
> > design docs and a few hundred thousand documents, you definitely need
> > something faster.
> >
> >
> > On Thu, Aug 15, 2013 at 10:14 AM, Stanley Iriele <siriele2x3@gmail.com
> > >wrote:
> >
> > > True... But the only way for that to happen is for them to bypass
> several
> > > other layers of security... In which case I'd have much bigger problems
> > to
> > > worry about
> > > On Aug 14, 2013 8:08 PM, "Andrey Kuprianov" <
> andrey.kouprianov@gmail.com
> > >
> > > wrote:
> > >
> > > > So far it seems very promising. :) However, what they say can happen
> is
> > > > that since Erlang code has no sandbox, anything could be done to the
> > > system
> > > > through design views, if your database is compromised.
> > > >
> > > >
> > > > On Thu, Aug 15, 2013 at 9:58 AM, Stanley Iriele <
> siriele2x3@gmail.com
> > > > >wrote:
> > > >
> > > > > 5-6 times eh?...that would give me an honest reason for picking up
> > > Erlang
> > > > > again....I'm going to try converting all of my views to Erlang and
> > see
> > > > what
> > > > > happens..what's the worst that can happen? :-)
> > > > > On Aug 14, 2013 7:55 PM, "Andrey Kuprianov" <
> > > andrey.kouprianov@gmail.com
> > > > >
> > > > > wrote:
> > > > >
> > > > > > I had a 5-6 times speed boost yesterday, after converting one of
> my
> > > > > design
> > > > > > docs to Erlang. Like a breath of fresh air, if you ask me.
> > > > > >
> > > > > >   Andrey
> > > > > >
> > > > > >
> > > > > > On Wed, Aug 14, 2013 at 11:54 PM, Stanley Iriele <
> > > siriele2x3@gmail.com
> > > > > > >wrote:
> > > > > >
> > > > > > > I'm curious... What exactly is the performance gain from
> writing
> > > > > > > views/shows/ etc in Erlang vs JavaScript... From what I've seen
> > the
> > > > > > > JavaScript view server is sufficiently fast and feature
> complete.
> > > > > > >
> > > > > > > So my question is this.... Is the Erlang view server that much
> > > > > faster?...
> > > > > > > Is there another gain that I'm missing?..and is it as feature
> > > > complete
> > > > > as
> > > > > > > the JavaScript equivalent?
> > > > > > >
> > > > > > > Regards,
> > > > > > >
> > > > > > > Stanley
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

--089e0149ca3a4b6e1e04e3f4c606--