First of all, from your questions shall I assume the response time should
not differ that much comparing to lock-based impls? We really need some
best practices for Akka REST service actors, or
at least some vision.
JMeter was running on the same machine. For JVM, in all experiments we used
default maven-t7-plugin settings + CMS garbage collector. Below is an Akka
configuration that gives one of the best performances till now.
default-dispatcher {
fork-join-executor {
parallelism-max = 100
}
throughput = 100
}
learning-core-dispatcher {
type = Dispatcher
executor = "fork-join-executor"
fork-join-executor {
parallelism-min = 8
parallelism-factor = 3.0
parallelism-max = 40
}
throughput = 100
}
default-mailbox {
mailbox-type = "akka.dispatch.SingleConsumerOnlyUnboundedMailbox"
}
Regards,
Cagri
On Tuesday, June 24, 2014 11:33:10 AM UTC+2, √ wrote:
>
> Also, what JVM parameters did you use?
>
>
> On Tue, Jun 24, 2014 at 11:32 AM, √iktor Ҡlang <[email protected]
> <javascript:>> wrote:
>
>> What is your bottleneck, what config did you use and did you run JMeter
>> on the same machine or on a different machine?
>>
>>
>> On Tue, Jun 24, 2014 at 11:30 AM, Cagri Yalcin <[email protected]
>> <javascript:>> wrote:
>>
>>> Hi All,
>>>
>>> We've implemented an online learning/recommendation system adopting 2
>>> approaches:
>>> 1) Sync REST and learning components shielded with
>>> ReentrantReadWriteLock's
>>> 2) Sync REST and learning components deployed in Akka actors
>>>
>>> Throughout our stress tests using JMeter and several above 500K real
>>> data, we analysed a huge set of configurations for Akka from
>>> connector impl(component between akka actors and REST service), actor
>>> architecture, dispatcher and mailbox settings perspectives.
>>> Till now, best performance obtained via harnessing dedicated distinct
>>> dispatchers with some (sub)optimized parameters for connector (fully
>>> future-based and/or router+actor+future/based)
>>> and core learning actors. In addition to this,
>>> using SingleConsumerOnlyUnboundedMailbox as default mailbox type brings
>>> some improvements.
>>>
>>> After extensive trials, comparing to ReentrantReadWriteLock-based
>>> approach, what we observe is recommendation service response time is always
>>> around 2 times
>>> more in Akka-based impls, although Akka-based impls might give slightly
>>> better throughput in some cases.
>>>
>>> My questions:
>>>
>>> 1) Considering response time, is Akka latency is inevitable comparing to
>>> classical lock-based impls on top of a REST service? Any general
>>> suggestion/guideline to improve
>>> response time in Akka REST service actors?
>>>
>>> 2) Shall we "really" expect a better throughput if we use Async REST?
>>>
>>> Thanks a lot.
>>>
>>> Regards,
>>>
>>> Cagri Yalcin
>>>
>>> --
>>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>>> >>>>>>>>>> Check the FAQ:
>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>> >>>>>>>>>> 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 unsubscribe from this group and stop receiving emails from it, send
>>> an email to [email protected] <javascript:>.
>>> To post to this group, send email to [email protected]
>>> <javascript:>.
>>> Visit this group at http://groups.google.com/group/akka-user.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Cheers,
>> √
>>
>
>
>
> --
> Cheers,
> √
>
--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ:
>>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>> 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 unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
