Large views and concurrent access

[mangvlad <ma...@yahoo.com>]

I have a view that returns about 14,000 rows (about 1.5 MB in size).
Getting it back (GET request) takes abou 1 sec.

If I try to have 2 users (2 separate requests) accessing it at the same time, 
the time to complete the request becomes 2 second. 
(3 seconds for 3 users, 4 for 4, etc.).

The same happens, 
when 2 users are trying to access two different views of similar sizes: 
getting view 1 takes 1 sec, getting view 2 takes 1 seconds 
but trying to get results from both in parallel takes 2 seconds....

More Info:

1. If/when I try to use limit=100 or other small numbers, 
concurrency is not an issue, 
but I need to have the full view for my app.

2. Using reduce is not an option, since I need to do dynamic filtering 
(so I am using node.js to do the reduce, but it needs the complete view...)

I hope may be there is a config parameter to allow for this use case... 

(maybe increase some buffers or memory? 
1.5 MB is not even that large of a result...)

Thanks,
Vlad

Re: Large views and concurrent access

[Dave Cottlehuber <dc...@jsonified.com>]

On 14 June 2013 22:38, mangvlad <ma...@yahoo.com> wrote:
> Stanley,
>
> I have tried to use lists, but its performance was 10x times worse,
> than doing it in node.js.
>
> Thanks,
> Vlad
>

Hey Vlad,

If you are able to share some code (for both solutions) this would be
interesting to understand where the hit is taken.

You might also see what happens to your list functions when you swap
in http://github.com/iriscouch/couchjs instead.

A+
Dave

Re: Large views and concurrent access

[mangvlad <ma...@yahoo.com>]

Stanley,

I have tried to use lists, but its performance was 10x times worse,
than doing it in node.js.

Thanks,
Vlad

Re: Large views and concurrent access

[Stanley Iriele <si...@breaktimestudios.com>]

just out of curiosity ...why aren't you using a list function after the
view?...its certainly not the best way for filtering but it gives you the
HTTP request.


On Fri, Jun 14, 2013 at 12:09 PM, mangvlad <ma...@yahoo.com> wrote:

> Thanks Filippo.
>
> I guess I can introduce some caching in my node.js layer, but ideally,
> I would like to "exhaust" my couchdb options first...
>
> I also have tried using lists feature, but its performance is many times
> slower
> than doing it using node's V8.
>
> Again, my original problem is in the fact that I am not allowed to use
> multiple keys filtering and group=false together,
> otherwise I can reduce my views inside couchdb and probably avoid
> this concurrency issue all together...
>
> Thanks,
> Vlad
>
>

Re: Large views and concurrent access

[mangvlad <ma...@yahoo.com>]

The data in my db are read only.
Even to get 304 back takes twice as long when I have 2 requests.

I am using JMeter to do my test and getting the same results...
I also have tried several hosted couchdbs to make sure that it is not my 
local setup...

Re: Large views and concurrent access

[Adam Kocoloski <ko...@apache.org>]

The file descriptor process for the .view file is shared by all clients querying the view.  I suppose you might be at the limit of what it can deliver from disk, but it's hard to say for certain.  The Fd does not do any caching or deduplication of pread requests.

I can't think of anything other shared resource that might degrade in this fashion with a large view respoonse.

Adam

On Jun 15, 2013, at 9:00 AM, mangvlad <ma...@yahoo.com> wrote:

> I think my problem is not with the size or seep of parsing.
> When I am making a single request, getting the response in 1 sec is ok.
> Improving this speed would be a bonus...
> 
> My problem is that when I get more than one user, the time is rapidly increasing
> with every new concurrent request...
> 
> Breaking views into smaller multiple views will be pretty difficult...
> What is it that is shared between requests inside couchdb that is causing this?
> 

Re: Large views and concurrent access

[mangvlad <ma...@yahoo.com>]

I think my problem is not with the size or seep of parsing.
When I am making a single request, getting the response in 1 sec is ok.
Improving this speed would be a bonus...

My problem is that when I get more than one user, the time is rapidly increasing
with every new concurrent request...

Breaking views into smaller multiple views will be pretty difficult...
What is it that is shared between requests inside couchdb that is causing this?

Re: Large views and concurrent access

[Stanley Iriele <si...@breaktimestudios.com>]

I agree caching is always going to be faster when done correctly...if it
were pulling across the wire I would try compressing it because its the
transfer of 1.5 MB that's getting you.

But I guess without knowing the extent of dynamism your require with your
query ..is it possible to split your large view into smaller views that you
could query in clever ways?... Also is that is there a high write to read
ratio?.. It could be fixing the index during this
On Jun 14, 2013 1:52 PM, "Jens Alfke" <je...@couchbase.com> wrote:

>
> On Jun 14, 2013, at 12:09 PM, mangvlad <ma...@yahoo.com> wrote:
>
> > I guess I can introduce some caching in my node.js layer, but ideally,
> > I would like to "exhaust" my couchdb options first...
>
> It’s always going to be much faster to cache local objects than to
> download and parse 1.5MB of JSON, no matter how fast the CouchDB server
> gets.
> Consider using conditional GETs, so you’ll get the updated view results if
> they’ve changed, and a simple 304 response if they haven’t.
>
> —Jens

Re: Large views and concurrent access

[Jens Alfke <je...@couchbase.com>]

On Jun 14, 2013, at 12:09 PM, mangvlad <ma...@yahoo.com> wrote:

> I guess I can introduce some caching in my node.js layer, but ideally, 
> I would like to "exhaust" my couchdb options first...

It’s always going to be much faster to cache local objects than to download and parse 1.5MB of JSON, no matter how fast the CouchDB server gets.
Consider using conditional GETs, so you’ll get the updated view results if they’ve changed, and a simple 304 response if they haven’t.

—Jens

Re: Large views and concurrent access

[mangvlad <ma...@yahoo.com>]

Thanks Filippo.

I guess I can introduce some caching in my node.js layer, but ideally, 
I would like to "exhaust" my couchdb options first...

I also have tried using lists feature, but its performance is many times slower 
than doing it using node's V8.

Again, my original problem is in the fact that I am not allowed to use 
multiple keys filtering and group=false together, 
otherwise I can reduce my views inside couchdb and probably avoid
this concurrency issue all together...

Thanks,
Vlad

Re: Large views and concurrent access

[Filippo Fadda <fi...@programmazione.it>]

Maybe you should caching the result.

-Filippo

On Jun 14, 2013, at 6:58 PM, mangvlad wrote:

> 
> I have a view that returns about 14,000 rows (about 1.5 MB in size).
> Getting it back (GET request) takes abou 1 sec.
> 
> If I try to have 2 users (2 separate requests) accessing it at the same time, 
> the time to complete the request becomes 2 second. 
> (3 seconds for 3 users, 4 for 4, etc.).
> 
> The same happens, 
> when 2 users are trying to access two different views of similar sizes: 
> getting view 1 takes 1 sec, getting view 2 takes 1 seconds 
> but trying to get results from both in parallel takes 2 seconds....
> 
> More Info:
> 
> 1. If/when I try to use limit=100 or other small numbers, 
> concurrency is not an issue, 
> but I need to have the full view for my app.
> 
> 2. Using reduce is not an option, since I need to do dynamic filtering 
> (so I am using node.js to do the reduce, but it needs the complete view...)
> 
> I hope may be there is a config parameter to allow for this use case... 
> 
> (maybe increase some buffers or memory? 
> 1.5 MB is not even that large of a result...)
> 
> Thanks,
> Vlad
>