CouchDB slow List-Function - couchdb

Question

In general I know what the problem is, but i have no idea how to solve it.
I have a simple map-function:
function(doc) {
if(doc.Type === 'Mission'){
for(var i in doc.Sections){
emit(doc._id, {_id:doc.Sections[i].id});
}
}
}
Based on the result of the map-function, I use a list-function to do some formatting:
function(head,req){
var result=[];
var row;
topo = require('lib/topojson');
while(row=getRow()){
if (row !== null) {
if(row.value._id){
row.doc.Geometry.properties.IDs.Section_ID = row.value._id;
}else{
row.doc.Geometry.properties.IDs.Section_ID = row.value;
}
geojson = {
type: "Feature",
geometry: row.doc.Geometry.geometry,
properties: row.doc.Geometry.properties
};
result.push(geojson);
}else{
send(JSON.stringify({
status_code: 404
}));
}
}
send(JSON.stringify(result));
}
The more documents are matching the map-function the longer does it take to do the processing with the list-function. The limiting factor is the couchjs view server. First the result from the map-function has to be serialized, after that the list-function can do the work.
As I wrote, for a small amount of documents the processing time isn't dramatical but as the amount of documents increase the time to do the processing by the list function increase as well.
Has someone an idea to improve my way to format the result?
Is it better to let the client do the work?

Answer 1

There exist several tricks to speed up _list functions.
Make your list and map functions live in two different design docs, to ensure they run in different SpiderMonkey instances.
Send response in large chunks, tens or even hundreds of kilobytes. Find out optimal chunk size: too large chunks are bad in terms of TTFB and memory consumption, small chunks produce IO overhead between SM and Erlang.
Minimize overhead of Storage->Erlang->JS serialize/deserialize. Make your map function emit strings that are serialized JSON and parse each row‘s JSON inside your list fn from a plain string. The more simple structure you pass to Erlang, the less time is spent at Erlang side to process it and pass to SM.
You can also use cache approach, but you must clearly understand what you‘re doing. Read more details here.

Answer 2

A list function is executed at runtime, that means the processing time is proportional to the number of documents the view returns. You can use a list function to display the last 20 posts of a blog, but you can't use it to elaborate 100.000 documents. That's something must be done inside a map function. In your place I would modify the map function to perform the operations you are doing inside the list function, or, even better, I would perform them before to save the document.