[
https://issues.apache.org/jira/browse/MESOS-1330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14148257#comment-14148257
]
Joris Van Remoortere commented on MESOS-1330:
---------------------------------------------
[~vinodkone]: I added a benchmark test which exercises libprocess in a many-1
fashion. It forks in order to ensure there is no short-circuiting of the
process-manager dispatch.
The benchmark test can be easily changed by the "num_iter", "num_threads", and
"queue_depth" variables at the top.
I ran it on the current apache mesos master, as well as on my prototype. The
result differences are within the variance of the test itself:
https://github.com/mesosphere/mesos/commits/abstract-event-manager
Master / Prototype (RPCs / second; 120K sample)
[42172] / [43116]
[42890] / [42812]
[43126] / [42950]
[42861] / [42829]
avg:
[42762] / [42926]
The key take-away is that currently both implementations are bottle-necked by
contention rather than CPU. This is something I hope to address as a separate
performance issue.
> Introduce connection/transport abstraction to stout
> ---------------------------------------------------
>
> Key: MESOS-1330
> URL: https://issues.apache.org/jira/browse/MESOS-1330
> Project: Mesos
> Issue Type: Improvement
> Components: general, libprocess
> Reporter: Niklas Quarfot Nielsen
> Labels: libprocess, network
>
> I think it makes sense to think in terms of different low or middle layer
> transports (which can accommodate channels like SSL). We could capture
> connection life-cycles and network send/receive primitives in a much explicit
> manner than currently in libprocess.
> I have a proof of concept transport / connection abstraction ready and which
> we can use to iterate a design.
> Notably, there are opportunities to change the current SocketManager/Socket
> abstractions to explicit ConnectionManager/Connection, which allow several
> and composeable communication layers.
> I am proposing to own this ticket and am looking for a shepherd to
> (thoroughly) go over design considerations before jumping into an actual
> implementation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
