Avoiding a bottleneck (nitrogen+yaws, app logic, couchbeam+couchdb)

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Avoiding a bottleneck (nitrogen+yaws, app logic, couchbeam+couchdb)

Jeremy Raymond
Hello,

I'm building a web application using nitrogen+yaws as the front end and
using couchbeam+couchdb as the back end. In the middle will by my
application logic. I plan to have a module to be the data access API in
front of couchbeam+couchdb. From the looks of things yaws and couchdb will
scale for what I need, but I'm looking for some advice on how to structure
my data access module. If I make this a typical gen_server then won't I be
bottlenecked with my data module will be running on a single thread? Does it
make more sense to not  use gen_server in this case and use a
straight functional module instead so that the data access module code runs
on the calling thread (yaws)? Any general ideas on a high level design for
the data access module would be appreciated.


Thanks,

Jeremy
Reply | Threaded
Open this post in threaded view
|

Re: Avoiding a bottleneck (nitrogen+yaws, app logic, couchbeam+couchdb)

Vasily Savin
Greetings,

I can tell you about the solution we used in similar situation. It does not
mean it is optimal, but it was the best we came up with.

Each gen_server call to db interface will generate a separate handler thread
that will work with couchDB directly. You will need to pass both PID and
NodeID though. Then your client will have to wait for message from that
server thread using standard messaging or if it is gen_server itself - using
handle_info.

This way interface between DB and frontend hopefully will not be bottleneck,
or at least should scale as each request will be handled by separate thread.

I would like to ask others to give opinion on this solution.

Regards,
Vasilij Savin
Reply | Threaded
Open this post in threaded view
|

Re: Avoiding a bottleneck (nitrogen+yaws, app logic, couchbeam+couchdb)

Jeremy Raymond
Hi,

Thanks I didn't think of this, but it seems reasonable. In your db interface
did you return the PID of the worker back to the calling interface so it
would know who to expect the response back from or just accept any response
back of the correct type?


Thanks,

Jeremy

On Sun, Dec 13, 2009 at 7:24 PM, Vasilij Savin <[hidden email]>wrote:

> Greetings,
>
> I can tell you about the solution we used in similar situation. It does not
> mean it is optimal, but it was the best we came up with.
>
> Each gen_server call to db interface will generate a separate handler
> thread that will work with couchDB directly. You will need to pass both PID
> and NodeID though. Then your client will have to wait for message from that
> server thread using standard messaging or if it is gen_server itself - using
> handle_info.
>
> This way interface between DB and frontend hopefully will not be
> bottleneck, or at least should scale as each request will be handled by
> separate thread.
>
> I would like to ask others to give opinion on this solution.
>
> Regards,
> Vasilij Savin
>
Reply | Threaded
Open this post in threaded view
|

Re: Avoiding a bottleneck (nitrogen+yaws, app logic, couchbeam+couchdb)

Vasily Savin
Greetings,

We expect proper response and do not return PID back. Command looks like
this
RequesterPID ! {response, ResponseData}

where ResponseData is record sent.

Regards,
Vasilij Savin


On Mon, Dec 14, 2009 at 8:13 PM, Jeremy Raymond <[hidden email]> wrote:

> Hi,
>
> Thanks I didn't think of this, but it seems reasonable. In your db
> interface did you return the PID of the worker back to the calling interface
> so it would know who to expect the response back from or just accept any
> response back of the correct type?
>
>
> Thanks,
>
> Jeremy
>
>
> On Sun, Dec 13, 2009 at 7:24 PM, Vasilij Savin <[hidden email]>wrote:
>
>> Greetings,
>>
>> I can tell you about the solution we used in similar situation. It does
>> not mean it is optimal, but it was the best we came up with.
>>
>> Each gen_server call to db interface will generate a separate handler
>> thread that will work with couchDB directly. You will need to pass both PID
>> and NodeID though. Then your client will have to wait for message from that
>> server thread using standard messaging or if it is gen_server itself - using
>> handle_info.
>>
>> This way interface between DB and frontend hopefully will not be
>> bottleneck, or at least should scale as each request will be handled by
>> separate thread.
>>
>> I would like to ask others to give opinion on this solution.
>>
>> Regards,
>> Vasilij Savin
>>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Avoiding a bottleneck (nitrogen+yaws, app logic, couchbeam+couchdb)

Jeremy Raymond
Hello,

In your design of the requester, does the requester timeout
while waiting for the db if it doesn't receive a timely response or do you
handle db errors another way?


Thanks,

Jeremy


On Mon, Dec 14, 2009 at 2:21 PM, Vasilij Savin <[hidden email]>wrote:

> Greetings,
>
> We expect proper response and do not return PID back. Command looks like
> this
> RequesterPID ! {response, ResponseData}
>
> where ResponseData is record sent.
>
> Regards,
> Vasilij Savin
>
>
>
> On Mon, Dec 14, 2009 at 8:13 PM, Jeremy Raymond <[hidden email]>wrote:
>
>> Hi,
>>
>> Thanks I didn't think of this, but it seems reasonable. In your db
>> interface did you return the PID of the worker back to the calling interface
>> so it would know who to expect the response back from or just accept any
>> response back of the correct type?
>>
>>
>> Thanks,
>>
>> Jeremy
>>
>>
>> On Sun, Dec 13, 2009 at 7:24 PM, Vasilij Savin <[hidden email]>wrote:
>>
>>> Greetings,
>>>
>>> I can tell you about the solution we used in similar situation. It does
>>> not mean it is optimal, but it was the best we came up with.
>>>
>>> Each gen_server call to db interface will generate a separate handler
>>> thread that will work with couchDB directly. You will need to pass both PID
>>> and NodeID though. Then your client will have to wait for message from that
>>> server thread using standard messaging or if it is gen_server itself - using
>>> handle_info.
>>>
>>> This way interface between DB and frontend hopefully will not be
>>> bottleneck, or at least should scale as each request will be handled by
>>> separate thread.
>>>
>>> I would like to ask others to give opinion on this solution.
>>>
>>> Regards,
>>> Vasilij Savin
>>>
>>
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: Avoiding a bottleneck (nitrogen+yaws, app logic, couchbeam+couchdb)

Vasily Savin
There is a set timeout. Because, if there is no data to send, we let client
to timeout and ask again.

Errors are just logged locally and not propagated to client.

Regards,
Vasilij Savin
Reply | Threaded
Open this post in threaded view
|

Re: Avoiding a bottleneck (nitrogen+yaws, app logic, couchbeam+couchdb)

Jeremy Raymond
Ok, thanks again. This strategy seems sound, I'll give it a try.

Jeremy

On Tue, Dec 15, 2009 at 4:38 AM, Vasilij Savin <[hidden email]>wrote:

> There is a set timeout. Because, if there is no data to send, we let client
> to timeout and ask again.
>
> Errors are just logged locally and not propagated to client.
>
> Regards,
> Vasilij Savin
>