Akka camel http rest concurrency without workers
331 views
Skip to first unread message
Antony Stubbs
May 23, 2012, 1:10:54 AM5/23/12
to akka...@googlegroups.com, Tanya.M...@functionxinc.com
Have read HttpConcurrencyTestStress, done some searching and have been thinking about this, is it not possible to have an actor created dynamically for every incoming request, from the camel engine side of things? We have the same issue with JMS consumers, but that case is a little different. We know we only need to be able to handle 2 or 3 concurrent messages, and for that it's simple to just create 3-5 JMS consumers, but for incoming HTTP it's a little different.
Doing it through a single akka-camel endpoint actor seems like a bottle neck (i.e. 8 jetty threads or whatever ending up putting messages onto 1 actor mailbox)
Doing it with a single actor, dispatching to working actors, seems like you need an upper bound on the worker actors. (unless i'm missing a router that doesn't have an upper bound on actors and will create them on demand for every message? Our consumer end point creates new worker actors for every request)
Am I missing something here, or is not the part of the point to be able to have actor to serve every inbound connection? (instead of a single actor bottleneck and an upper bound on worker actors, or on demand workers).
We currently create a new actor for every request, without using router, but this still all goes through a single end point actor (however fast that may be). I thought maybe you can create multiple end point consumer actors for the same url (maybe, haven't tried, not sure if the camel/akka stuff can dynamically distribute if there are multiple matching consumers), but then you're still guessing on a quantity and setting an upper bound.
Is there some config I'm missing that tells the akka/camel system to create as many actors as need to service incoming request, without going through a single actor router?
Cheers.
Björn Antonsson
May 24, 2012, 3:11:05 AM5/24/12
to akka...@googlegroups.com, Tanya.M...@functionxinc.com
Hi Antony,
I'm not sure that the single actor creating an actor for each request is a bottleneck. Have you got any figures proving this?
If you want to have multiple actors servicing the incoming requests, you could use a RoundRobinRouter with the number of instances set to for example the number of Jetty threads. You could then let each of these actors create a worker for each request, and let that worker handle the request.
A short explanation about routers:
The router is not an actor in itself, it is just a grouping of actors.
The routing decision code will be executed concurrently by incoming message sends.
A router does not create actors on demand at message sends but resizes itself at certain intervals based on the Resizer.
Hope this helps.
B/
Cheers.--
You received this message because you are subscribed to the Google Groups "Akka User List" group.
To view this discussion on the web visit https://groups.google.com/d/msg/akka-user/-/jdJPpy7EBRYJ.
To post to this group, send email to akka...@googlegroups.com.
To unsubscribe from this group, send email to akka-user+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.
Antony Stubbs
Jun 21, 2012, 3:43:47 PM6/21/12
to akka...@googlegroups.com, Tanya Mamedalin, Chris Soyars
Thanks for the response! Sorry for the late reply..
On 24/05/2012, at 3:11 AM, Björn Antonsson wrote:
> Hi Antony,
>
> On Wednesday, 23 May 2012 at 07:10, Antony Stubbs wrote:
>> Have read HttpConcurrencyTestStress, done some searching and have been thinking about this, is it not possible to have an actor created dynamically for every incoming request, from the camel engine side of things? We have the same issue with JMS consumers, but that case is a little different. We know we only need to be able to handle 2 or 3 concurrent messages, and for that it's simple to just create 3-5 JMS consumers, but for incoming HTTP it's a little different.
>>
>> Doing it through a single akka-camel endpoint actor seems like a bottle neck (i.e. 8 jetty threads or whatever ending up putting messages onto 1 actor mailbox)
>>
>> Doing it with a single actor, dispatching to working actors, seems like you need an upper bound on the worker actors. (unless i'm missing a router that doesn't have an upper bound on actors and will create them on demand for every message? Our consumer end point creates new worker actors for every request)
>>
>> Am I missing something here, or is not the part of the point to be able to have actor to serve every inbound connection? (instead of a single actor bottleneck and an upper bound on worker actors, or on demand workers).
>>
>> We currently create a new actor for every request, without using router, but this still all goes through a single end point actor (however fast that may be). I thought maybe you can create multiple end point consumer actors for the same url (maybe, haven't tried, not sure if the camel/akka stuff can dynamically distribute if there are multiple matching consumers), but then you're still guessing on a quantity and setting an upper bound.
>>
>> Is there some config I'm missing that tells the akka/camel system to create as many actors as need to service incoming request, without going through a single actor router?
>
> I'm not sure that the single actor creating an actor for each request is a bottleneck. Have you got any figures proving this?
Not at all. Just the concept of 8 threads, talking to 1 thread, which then distributes out to n threads again. Seems like the 8 to 1 step could be avoidable.
> If you want to have multiple actors servicing the incoming requests, you could use a RoundRobinRouter with the number of instances set to for example the number of Jetty threads. You could then let each of these actors create a worker for each request, and let that worker handle the request.
Right, but isn't there still a step where there's one thread processing all incoming requests in order to distribute to the RRR?
> A short explanation about routers:
>
> The router is not an actor in itself, it is just a grouping of actors.
>
> The routing decision code will be executed concurrently by incoming message sends.
Ah - this may be the key bit of explanation I'm missing. Is this discussed in the documentation for Routers, and I missed it?
> A router does not create actors on demand at message sends but resizes itself at certain intervals based on the Resizer.
Is there a Resizer that has no upper limit? I suppose a very large upper limit would be more sensible instead..
On 24/05/2012, at 3:11 AM, Björn Antonsson wrote:
> Hi Antony,
>
> On Wednesday, 23 May 2012 at 07:10, Antony Stubbs wrote:
>> Have read HttpConcurrencyTestStress, done some searching and have been thinking about this, is it not possible to have an actor created dynamically for every incoming request, from the camel engine side of things? We have the same issue with JMS consumers, but that case is a little different. We know we only need to be able to handle 2 or 3 concurrent messages, and for that it's simple to just create 3-5 JMS consumers, but for incoming HTTP it's a little different.
>>
>> Doing it through a single akka-camel endpoint actor seems like a bottle neck (i.e. 8 jetty threads or whatever ending up putting messages onto 1 actor mailbox)
>>
>> Doing it with a single actor, dispatching to working actors, seems like you need an upper bound on the worker actors. (unless i'm missing a router that doesn't have an upper bound on actors and will create them on demand for every message? Our consumer end point creates new worker actors for every request)
>>
>> Am I missing something here, or is not the part of the point to be able to have actor to serve every inbound connection? (instead of a single actor bottleneck and an upper bound on worker actors, or on demand workers).
>>
>> We currently create a new actor for every request, without using router, but this still all goes through a single end point actor (however fast that may be). I thought maybe you can create multiple end point consumer actors for the same url (maybe, haven't tried, not sure if the camel/akka stuff can dynamically distribute if there are multiple matching consumers), but then you're still guessing on a quantity and setting an upper bound.
>>
>> Is there some config I'm missing that tells the akka/camel system to create as many actors as need to service incoming request, without going through a single actor router?
>
> I'm not sure that the single actor creating an actor for each request is a bottleneck. Have you got any figures proving this?
> If you want to have multiple actors servicing the incoming requests, you could use a RoundRobinRouter with the number of instances set to for example the number of Jetty threads. You could then let each of these actors create a worker for each request, and let that worker handle the request.
> A short explanation about routers:
>
> The router is not an actor in itself, it is just a grouping of actors.
>
> The routing decision code will be executed concurrently by incoming message sends.
> A router does not create actors on demand at message sends but resizes itself at certain intervals based on the Resizer.
Björn Antonsson
Jun 22, 2012, 1:37:47 AM6/22/12
to akka...@googlegroups.com, Tanya Mamedalin, Chris Soyars
Hi Antony,
On Thursday, 21 June 2012 at 21:43, Antony Stubbs wrote:
Thanks for the response! Sorry for the late reply..On 24/05/2012, at 3:11 AM, Björn Antonsson wrote:Hi Antony,On Wednesday, 23 May 2012 at 07:10, Antony Stubbs wrote:Have read HttpConcurrencyTestStress, done some searching and have been thinking about this, is it not possible to have an actor created dynamically for every incoming request, from the camel engine side of things? We have the same issue with JMS consumers, but that case is a little different. We know we only need to be able to handle 2 or 3 concurrent messages, and for that it's simple to just create 3-5 JMS consumers, but for incoming HTTP it's a little different.Doing it through a single akka-camel endpoint actor seems like a bottle neck (i.e. 8 jetty threads or whatever ending up putting messages onto 1 actor mailbox)Doing it with a single actor, dispatching to working actors, seems like you need an upper bound on the worker actors. (unless i'm missing a router that doesn't have an upper bound on actors and will create them on demand for every message? Our consumer end point creates new worker actors for every request)Am I missing something here, or is not the part of the point to be able to have actor to serve every inbound connection? (instead of a single actor bottleneck and an upper bound on worker actors, or on demand workers).We currently create a new actor for every request, without using router, but this still all goes through a single end point actor (however fast that may be). I thought maybe you can create multiple end point consumer actors for the same url (maybe, haven't tried, not sure if the camel/akka stuff can dynamically distribute if there are multiple matching consumers), but then you're still guessing on a quantity and setting an upper bound.Is there some config I'm missing that tells the akka/camel system to create as many actors as need to service incoming request, without going through a single actor router?I'm not sure that the single actor creating an actor for each request is a bottleneck. Have you got any figures proving this?Not at all. Just the concept of 8 threads, talking to 1 thread, which then distributes out to n threads again. Seems like the 8 to 1 step could be avoidable.
If that really is a concern then have 8 actors behind a round robin router that create an actor per request. This doesn't need to be faster depending on your usage patterns, and it's really not fair to think of actors as threads (since they're not).
If you want to have multiple actors servicing the incoming requests, you could use a RoundRobinRouter with the number of instances set to for example the number of Jetty threads. You could then let each of these actors create a worker for each request, and let that worker handle the request.Right, but isn't there still a step where there's one thread processing all incoming requests in order to distribute to the RRR?
No, there is only a function from message and sender to routees.
A short explanation about routers:The router is not an actor in itself, it is just a grouping of actors.The routing decision code will be executed concurrently by incoming message sends.Ah - this may be the key bit of explanation I'm missing. Is this discussed in the documentation for Routers, and I missed it?
It's in the first paragraph of How Routing is Designed within Akka at http://doc.akka.io/docs/akka/2.0/scala/routing.html ;)
A router does not create actors on demand at message sends but resizes itself at certain intervals based on the Resizer.Is there a Resizer that has no upper limit? I suppose a very large upper limit would be more sensible instead..
If you're looking for a resizer without an upper limit, then I think that you're better of creating and disposing of actors on demand, i.e. per request.
B/
delasoul
Jun 22, 2012, 4:45:05 AM6/22/12
to akka...@googlegroups.com, Tanya Mamedalin, Chris Soyars
a single actor should be able to handle 3-4 million messages/second. You might consider a PinnedDispatcher for your camel endpoint actor
michael
michael
Hope this helps.B/
To unsubscribe from this group, send email to akka-user+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.
--Björn AntonssonTypesafe - The software stack for applications that scale--You received this message because you are subscribed to the Google Groups "Akka User List" group.To post to this group, send email to akka...@googlegroups.com.
To unsubscribe from this group, send email to akka-user+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.
--You received this message because you are subscribed to the Google Groups "Akka User List" group.To post to this group, send email to akka...@googlegroups.com.
To unsubscribe from this group, send email to akka-user+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.
Antony Stubbs
Oct 16, 2012, 2:44:56 PM10/16/12
to akka...@googlegroups.com, Tanya Mamedalin, Chris Soyars
Follow up post here, a few months later when we started getting load under this setup:
Hope this helps.B/
To unsubscribe from this group, send email to akka-user+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.
--Björn AntonssonTypesafe - The software stack for applications that scale--You received this message because you are subscribed to the Google Groups "Akka User List" group.To post to this group, send email to akka...@googlegroups.com.
To unsubscribe from this group, send email to akka-user+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.
--You received this message because you are subscribed to the Google Groups "Akka User List" group.To post to this group, send email to akka...@googlegroups.com.
To unsubscribe from this group, send email to akka-user+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.
Antony Stubbs
Oct 16, 2012, 2:48:25 PM10/16/12
to akka...@googlegroups.com, Tanya Mamedalin, Chris Soyars
Wrote a follow up post (camel+jetty+akka and time outs to memory read ws’s under load: https://groups.google.com/forum/?fromgroups=#!topic/akka-user/r7Sj4_2rvTg), but it's overdue i actually replied to this one.
Responses inline..
>>> A short explanation about routers:
>>>
>>> The router is not an actor in itself, it is just a grouping of actors.
>>>
>>> The routing decision code will be executed concurrently by incoming message sends.
>>
>> Ah - this may be the key bit of explanation I'm missing. Is this discussed in the documentation for Routers, and I missed it?
>
> It's in the first paragraph of How Routing is Designed within Akka at http://doc.akka.io/docs/akka/2.0/scala/routing.html ;)
Ah, that first paragraph says:
"A Router is an actor". So you can see how the confusion comes about..
>>> A router does not create actors on demand at message sends but resizes itself at certain intervals based on the Resizer.
>>
>> Is there a Resizer that has no upper limit? I suppose a very large upper limit would be more sensible instead..
>
> If you're looking for a resizer without an upper limit, then I think that you're better of creating and disposing of actors on demand, i.e. per request.
That's actually what I ended up doing, described in the post I linked to above, except without the disposing part...
Thanks for the response, and sorry for the tardy reply!
Responses inline..
>>> A short explanation about routers:
>>>
>>> The router is not an actor in itself, it is just a grouping of actors.
>>>
>>> The routing decision code will be executed concurrently by incoming message sends.
>>
>> Ah - this may be the key bit of explanation I'm missing. Is this discussed in the documentation for Routers, and I missed it?
>
> It's in the first paragraph of How Routing is Designed within Akka at http://doc.akka.io/docs/akka/2.0/scala/routing.html ;)
"A Router is an actor". So you can see how the confusion comes about..
>>> A router does not create actors on demand at message sends but resizes itself at certain intervals based on the Resizer.
>>
>> Is there a Resizer that has no upper limit? I suppose a very large upper limit would be more sensible instead..
>
> If you're looking for a resizer without an upper limit, then I think that you're better of creating and disposing of actors on demand, i.e. per request.
Thanks for the response, and sorry for the tardy reply!
Viktor Klang
Oct 17, 2012, 8:49:01 AM10/17/12
to akka...@googlegroups.com, Tanya Mamedalin, Chris Soyars
Actors _must_ be stopped when they are not needed anymore.
> --
>>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>>> Check the FAQ: http://akka.io/faq/
>>>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
> ---
>
>
>>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>>> Check the FAQ: http://akka.io/faq/
>>>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups "Akka User List" group.
> To post to this group, send email to akka...@googlegroups.com.
> To unsubscribe from this group, send email to akka-user+...@googlegroups.com.
> Visit this group at http://groups.google.com/group/akka-user?hl=en.
> To post to this group, send email to akka...@googlegroups.com.
> To unsubscribe from this group, send email to akka-user+...@googlegroups.com.
>
>
Reply all
Reply to author
Forward
0 new messages