openwhisk-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matt Rutkowski (Confluence)" <conflue...@apache.org>
Subject [CONF] OpenWhisk > 2017-07-13 Zoom meeting notes on UI driven use cases
Date Thu, 13 Jul 2017 17:20:07 GMT
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> 
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0">

<base href="https://cwiki.apache.org/confluence"> 
<title>Message Title</title>  
<style type="text/css">@media only screen and (max-device-width: 480px) {.mobile-only
{
    width: auto !important;
    height: auto !important;
    overflow: visible !important;
    line-height: normal !important;
    font-size: inherit !important;
    mso-hide: all;
}

.desktop-only {
    display: none !important;
}

/* iPhone 3GS fix for unwanted 20px right margin */
body {
    min-width: 100% !important;
    padding: 0;
    margin: 0;
}

#center-content-table {
    max-width: none;
!important;
}

#header-pattern-container {
    padding: 10px 10px 10px 10px !important;
    line-height: 20px !important;
}

#header-avatar-image-container {
    padding-right: 8px !important;
}

#email-content-container {
    padding: 0 !important;
}

.mobile-expand {
    border-radius: 0 !important;
    border-left: 0 !important;
    border-right: 0 !important;
    padding-left: 26px !important;
}

.mobile-resize-text {
    font-size: 16px !important;
    line-height: 22px !important;
}

#page-title-pattern-header {
    font-size: 20px !important;
    line-height: 28px !important;
}

#page-title-pattern-icon-image-container-cell {
    padding-top: 7px !important;
}

#inline-user-pattern {
    display: block !important;
}

#inline-user-pattern-avatar {
    padding-top: 3px !important;
}

.contextual-area-pattern {
    border-bottom: 1px solid #ccc !important;
    padding: 15px 10px 0 10px !important;
}

.users-involved-pattern-column-table {
    width: 100% !important;
}

.users-involved-pattern-avatar-table-cell {
    padding: 3px 5px 5px 0 !important;
}

.users-involved-pattern-column-container {
    padding-right: 0 !important;
}

.contextual-excerpt-pattern, #users-involved-pattern {
    border: 0 !important;
}

/** Aui Typography upsized for mobile **/
#content-excerpt-pattern-container, #contextual-excerpt-pattern-text-container {
    font-size: 16px !important;
    line-height: 22px !important;
}

#content-excerpt-pattern-container h1, #contextual-excerpt-pattern-text-container h1 {
    font-size: 24px !important;
    line-height: 28px !important;
}

#content-excerpt-pattern-container h2, #contextual-excerpt-pattern-text-container h2 {
    font-size: 20px !important;
    line-height: 28px !important;
}

#content-excerpt-pattern-container h3, #contextual-excerpt-pattern-text-container h3 {
    font-size: 18px !important;
    line-height: 24px !important;
}

#content-excerpt-pattern-container h4, #contextual-excerpt-pattern-text-container h4 {
    font-size: 16px !important;
    line-height: 22px !important;
}

#content-excerpt-pattern-container h5, #contextual-excerpt-pattern-text-container h5 {
    font-size: 14px !important;
    line-height: 20px !important;
}

#content-excerpt-pattern-container h6, #contextual-excerpt-pattern-text-container h6 {
    font-size: 14px !important;
    line-height: 20px !important;
}

.user-mention {
    line-height: 18px !important;
}

/** Aui Typography end **/

/* Show appropriate footer logo on mobile, display links vertically */
#footer-pattern {
    padding: 15px 10px !important;
}

#footer-pattern-logo-desktop-container {
    padding: 0 !important;
}

#footer-pattern-logo-desktop {
    width: 0 !important;
    height: 0 !important;
}

#footer-pattern-logo-mobile {
    padding-top: 10px !important;
    width: 30px !important;
    height: 27px !important;
    display: inline !important;
}

#footer-pattern-text {
    display: block !important;
}

#footer-pattern-links-container {
    line-height: 0 !important;
}

.footer-pattern-links.mobile-resize-text,
.footer-pattern-links.mobile-resize-text,
#footer-pattern-text.mobile-resize-text,
#footer-pattern-links-container.no-footer-links {
    font-size: 14px !important;
    line-height: 20px !important;
}

.footer-link {
    display: block !important;
}

#footer-pattern-links-container table {
    display: inline-block !important;
    float: none !important;
}

#footer-pattern-links-container, #footer-pattern-text {
    text-align: center !important;
}

#footer-pattern-links {
    padding-bottom: 5px !important;
}

/** Team Calendar overrides, these should be removed when notifications are updated in Team
Calendars. For now CSS
    overrides are being used because the structure of the content can't change without rereleasing
the plugin */
.mail-calendar-container .day-header + table tr td:first-child {
    vertical-align: top !important;
    padding-top: 5px !important;
}}
@media (min-width: 900px) {#center-content-table { width: 900px; }}
@media all {#outlook a {
    padding: 0;
}

/* Force Outlook to provide a "view in browser" menu link. */
/* Prevent Webkit and Windows Mobile platforms from changing default font sizes.*/
body {
    -webkit-text-size-adjust: 100%;
    -ms-text-size-adjust: 100%;
}

.ExternalClass {
    width: 100%;
}

/* Force Hotmail to display emails at full width */
#background-table {
    margin: 0;
    padding: 0;
    width: 100% !important;
}

/* Needed to override highlighting on date and time links in iOS */
.grey a {
    color: #707070;
    text-decoration: none;
}/* These styles are appended to the head element of a notification in order to prevent Apple
Mail and similar
   clients from underlining the due dates with a blue hyperlink */
/* a lozenge outside an inline task should always be #333, lozenges inside an inline task
should be
   colored according to their upcoming due dates, a completed task date lozenge or deleted
task date
   lozenge should always be #707070 */
.date-time-lozenge a {color: #333333; text-decoration: none; }
.inline-task-text-container .date-time-lozenge.date-upcoming a {color: #DF6F00; text-decoration:
none; }
.inline-task-text-container .date-time-lozenge.date-past a {color: #D04437; text-decoration:
none; }
.inline-task-text-container.content-deleted-color .date-time-lozenge a,
.inline-task-text-container.checked .date-time-lozenge a {
    color: #707070; text-decoration: none;
}}
</style> 
</head>
<body>
<table id="background-table" cellpadding="0" cellspacing="0" width="100%" style="border-collapse:
collapse; mso-table-lspace: 0pt; mso-table-rspace: 0pt; color: #333; background-color: #f5f5f5">

<tbody> 
<tr> 
<td id="header-pattern-container" style="padding: 0px; border-collapse: collapse; padding:
10px 20px"> 
<table id="header-pattern" cellspacing="0" cellpadding="0" border="0" style="border-collapse:
collapse; mso-table-lspace: 0pt; mso-table-rspace: 0pt; color: #333"> 
<tbody> 
<tr> 
<td id="header-avatar-image-container" valign="top" style="padding: 0px; border-collapse:
collapse; vertical-align: top; width: 32px; padding-right: 9px"><a href="https://cwiki.apache.org/confluence/display/~mrutkows?src=mail&amp;src.mail.timestamp=1499966406951&amp;src.mail.notification=com.atlassian.confluence.plugins.confluence-content-notifications-plugin%3Apage-edited-notification&amp;src.mail.recipient=8aa980875bf24635015c9267bc8e02f6"
style="color: #3b73af; text-decoration: none"><img id="header-avatar-image" class="image_fix"
src="cid:avatar_1c1ec99848547cb9f4e49b30ec5da36b" height="32" width="32" border="0" style="border-radius:
3px; vertical-align: top"></a></td>
<td id="header-text-container" valign="middle" style="padding: 0px; border-collapse: collapse;
vertical-align: middle; font-family: Arial, sans-serif; font-size: 14px; line-height: 20px;
mso-line-height-rule: exactly; mso-text-raise: 1px">Matt Rutkowski <strong>edited</strong>
a page</td> 
</tr> 
</tbody> 
</table> </td> 
</tr> 
<!-- End Header pattern --> 
<tr> 
<td id="email-content-container" style="padding: 0px; border-collapse: collapse; padding:
0 20px"> 
<table id="email-content-table" cellspacing="0" cellpadding="0" border="0" width="100%"
style="border-collapse: collapse; mso-table-lspace: 0pt; mso-table-rspace: 0pt; color: #333;
border-spacing: 0; border-collapse: separate"> 
<tbody> 
<tr> 
<td class="email-content-rounded-top mobile-expand" style="padding: 0px; border-collapse:
collapse; color: #fff; padding: 0 15px 0 16px; height: 15px; background-color: #fff; border-left:
1px solid #ccc; border-top: 1px solid #ccc; border-right: 1px solid #ccc; border-bottom: 0;
border-top-right-radius: 5px; border-top-left-radius: 5px">&nbsp;</td> 
</tr> 
<tr> 
<td class="email-content-main mobile-expand" style="padding: 0px; border-collapse: collapse;
border-left: 1px solid #ccc; border-right: 1px solid #ccc; border-top: 0; border-bottom: 0;
padding: 0 15px 15px 16px; background-color: #fff"> 
<table id="page-title-pattern" cellspacing="0" cellpadding="0" border="0" width="100%"
style="border-collapse: collapse; mso-table-lspace: 0pt; mso-table-rspace: 0pt; color: #333">

<tbody> 
<tr> 
<td id="page-title-pattern-icon-image-container" valign="top" style="padding: 0px; border-collapse:
collapse; width: 16px; vertical-align: top"> 
<table cellspacing="0" cellpadding="0" border="0" style="border-collapse: collapse; mso-table-lspace:
0pt; mso-table-rspace: 0pt; color: #333"> 
<tbody> 
<tr> 
<td id="page-title-pattern-icon-image-container-cell" style="padding: 0px; border-collapse:
collapse; width: 16px; padding: 9px 8px 0px 0px; mso-text-raise: 5px; mso-line-height-rule:
exactly"><a href="https://cwiki.apache.org/confluence/display/OPENWHISK/2017-07-13+Zoom+meeting+notes+on+UI+driven+use+cases?src=mail&amp;src.mail.timestamp=1499966406951&amp;src.mail.notification=com.atlassian.confluence.plugins.confluence-content-notifications-plugin%3Apage-edited-notification&amp;src.mail.recipient=8aa980875bf24635015c9267bc8e02f6&amp;src.mail.action=view"
title="page icon" style="vertical-align: top;; color: #3b73af; text-decoration: none"><img
style="vertical-align: top; display: block;" src="cid:page-icon" alt="page icon" title="page
icon" height="16" width="16" border="0"></a></td> 
</tr> 
</tbody> 
</table> </td>
<td style="vertical-align: top;; padding: 0px; border-collapse: collapse; padding-right:
5px; font-size: 20px; line-height: 30px; mso-line-height-rule: exactly" id="page-title-pattern-header-container"><span
id="page-title-pattern-header" style="font-family: Arial, sans-serif; padding: 0; font-size:
20px; line-height: 30px; mso-text-raise: 2px; mso-line-height-rule: exactly; vertical-align:
middle"><a href="https://cwiki.apache.org/confluence/display/OPENWHISK/2017-07-13+Zoom+meeting+notes+on+UI+driven+use+cases?src=mail&amp;src.mail.timestamp=1499966406951&amp;src.mail.notification=com.atlassian.confluence.plugins.confluence-content-notifications-plugin%3Apage-edited-notification&amp;src.mail.recipient=8aa980875bf24635015c9267bc8e02f6&amp;src.mail.action=view"
title="2017-07-13 Zoom meeting notes on UI driven use cases" style="color: #3b73af; text-decoration:
none">2017-07-13 Zoom meeting notes on UI driven use cases</a></span></td>

</tr> 
</tbody> 
</table> </td> 
</tr> 
<tr> 
<td class="email-content-main mobile-expand" style="padding: 0px; border-collapse: collapse;
border-left: 1px solid #ccc; border-right: 1px solid #ccc; border-top: 0; border-bottom: 0;
padding: 0 15px 15px 16px; background-color: #fff"> 
<table class="content-excerpt-pattern" cellspacing="0" cellpadding="0" border="0" width="100%"
style="border-collapse: collapse; mso-table-lspace: 0pt; mso-table-rspace: 0pt; color: #333;
font-family: Arial, sans-serif; font-size: 14px; line-height: 20px; mso-line-height-rule:
exactly; mso-text-raise: 1px"> 
<tbody> 
<tr> 
<td class="content-excerpt-pattern-container mobile-resize-text " style="padding: 0px;
border-collapse: collapse; padding: 0 0 0 24px"> <p class="diff-context-placeholder"
style="margin: 10px 0 0 0; margin-top: 0">...</p> 
<ul class="diff-block-target" style="margin: 10px 0 0 0"> 
<li>Tyson: topic: Put a Wiki page on CWIKI for describing both background on use case
we are trying to support and approach.</li> 
<li> <br> 
<ul style="margin: 10px 0 0 0"> 
<li>How to increase throughput within OW, given current state of behavior of invoker</li>

<li>tp. becomes limited due to number of users/actions in system against avail. containers
(invokers)</li> 
<li>Share screen with WIKI:&nbsp;<a href="https://cwiki.apache.org/confluence/display/OPENWHISK/UI+Driven+Use+Cases"
rel="nofollow" style="color: #3b73af; text-decoration: none">https://cwiki.apache.org/confluence/display/OPENWHISK/UI+Driven+Use+Cases</a>
</li> 
</ul> </li> 
<li>Jeremias: just share general ida and the core of proposal</li> 
<li>Tyson: ext. mech. for API-drive apps.<br> 
<ul style="margin: 10px 0 0 0"> 
<li>some simple examples on WIki, it becomes more appealing for devs. to use an intermediary
system to provide a wrapper around APIs (vs. changing client or server)</li> 
<li>Many of the case the APIs are being used in a browser; interested in throughput
changes that happen when OW comes under load with large # concurrent users</li> 
<li>The diagram captures the flow as of today</li> 
<li>Controller/invokers rout actions to avail containers based upon avail., never mult.
actions running in same container</li> 
<li># of containers in system affects concurrency; its ok for the most part, but also
affected by # of actions in system at a given time</li> 
<li># of containers starts to affect current users with latency going up dramatically</li>

<li>Here we try to describe</li> 
</ul> </li> 
<li>Rodric: can u give an idea of what scale of users? &nbsp;1000s? 100k’s?</li>

<li>Tyson: low end 1000s, high end 10,000s of users</li> 
<li>Rodric: 30, 000 req. per sec?</li> 
<li>Tyson: # re. per second depends on what they are doing…</li> 
<li> <br> 
<ul style="margin: 10px 0 0 0"> 
<li>there is not a fixed target. Our intention is to service APIs as if they are being
routed directly, but instead service them via OW without impact on user</li> 
<li>User API may have APIs that take 10 secs to respond, others are faster</li>

<li>latency incurred from routing through OW should not be noticeable</li> 
</ul> </li> 
<li>Rodric: make sense. what is scale of deployment? 100 VMs, 50 VMs?</li> 
<li>Tyson: we do not have anything in production yet. &nbsp;Scale is currently “up
in ir” not yet ready for production, because we cannot yet run small loads. Have ways to
go before we goto production server allocation.</li> 
<li> <br> 
<ul style="margin: 10px 0 0 0"> 
<li>Goal to increase density BEFORE we plan for prod.</li> 
</ul> </li> 
<li>Jeremias: Increase of latency is this due to queueing in system? (in your tests)</li>

<li>Tyson: yes. if for example, you run (have you seem Markus perf. repo. with his throughput
tests?) using those tests it is easy to see the effects of the queueing when # conc. users
goes over # of avail. containers (for that action) in the systems. The latency increase dramatically</li>

<li>Markus: that would be expected. you can even see this with moderate load due to
queueing (to handle conc. load)</li> 
<li>Jeremias: with no overload the latency using Kafka is not that high. It is not the
Kafka service it is simply the queueing waiting for container.</li> 
<li>Tyson. Agree. Latency looks good when Kafka. Again #users &gt; #containers avail.</li>

<li>Typson: in general, user activity that exceeds what we would want to support &gt;
10,000 users in the system. it becomes cost prohibitive to spin up 10,000 containers in the
system.</li> 
<li> <br> 
<ul style="margin: 10px 0 0 0"> 
<li>There is a reason (cost) that we want to avoid 1 user per container model to keep
cost down</li> 
</ul> </li> 
<li>MB: is it fair to say the “core” of problem you want to go from single thread
processes to multi-threaded processes?</li> 
<li>Tyson: core of problem is throughput, our proposal would allow (as one option) is
having concurrent processing as you have described.</li> 
<li>Dragos: 18 users, 16 gig of ram on a server… question in OW how close do we want
to get to the point where we can allow a single VM to take more users.</li> 
<li> <br> 
<ul style="margin: 10px 0 0 0"> 
<li>if we give 1 CPU to 1 container… density is 8, if we allow.8 CPU then we get higher
density</li> 
</ul> </li> 
<li>Rodric: not enough to talk about that. you have CPU share options; spin up container
MB to container with it shared (part of Serverless contract). proposal changes CPU “share”
model</li> 
<li> <br> 
<ul style="margin: 10px 0 0 0"> 
<li>If you allow 1/16 a slice of a CPU, you could spin up a 1000 containers on that
VM</li> 
<li>would like to understand standing up 10,000 containers is a problem. &nbsp;It
is doable.</li> 
<li>What is CPU share you want to get to?</li> 
<li>Intra/Inter container is an impl. detail</li> 
<li>what share does each activation take of CPU?</li> 
</ul> </li> 
<li>Dragos: ? (unclear of comment here)&nbsp;</li> 
<li>Markus: limiting this via CPU share is not viable. Proposal on table should be effective
under load.</li> 
<li>Tyson: yes</li> 
<li>Rodric: that goes to the resource model. u are paying per GB second, if you change
that equation … what does it mean to be charged this way? What is the limit mean for memory/time?
&nbsp;It comes back to what amount of resources you plan to allocate to any given action/activation</li>

<li>Markus: makes sense</li> 
<li>Tyson: what you are describing is a billing issue? not a resource issue?</li>

<li>Rodric: still exploring boundaries, fund. you bounded by container density, can
reduce that in invoker activations based upon CPU share. some things are CPU bound some are
memory bound. should not conflate the 2. &nbsp;You are slicing the resource. Some things
need more compute some more memory.</li> 
<li>Dragos:makes sense, but what is not clear the Docker sharing &nbsp;model of
CPU (even if u allocate 1/16 of cpu) you are not guaranteed that resource, its unclear how
Docker handles this.</li> 
<li>Rodric: true. that is why memory is the limiting factor. how you impl. this increasing
compute density, will affect view of how you look at resource sharing. &nbsp;Trying to
elucidate what we are talking about</li> 
<li>MB: have u thought about expose to end user. if you specify memory as resource constraint?</li>

<li>Tyson: my view is its the same. meaning… when you pick a # for ur action today
(and suggest amount of CPU or RAM per container); whatever rules you are using still apply
for single activation or not.</li> 
<li> <br> 
<ul style="margin: 10px 0 0 0"> 
<li>The methodology u take must change based upon # of conc. users in system. you are
always just “picking a number”</li> 
</ul> </li> 
<li>MB: 256 MB of memory today..</li> 
<li>Tyson: how did we come to 256? why not 28 MB?</li> 
<li>MB: I picked because it felt correct. &nbsp;I assume when I run action that
I have this amount. in a more dense model, if I pick less, what is the user guarantee</li>

<li>Tyson: you will not get the guarantee in the same way of course. What I am saying
if there is a reason to pick this #, then the issue is problematic for you because you have
a particular workload in mind (that may not suit the use case of many conc. users)</li>

<li>Rodric: # of conc. users should not be an issue. Still comes to CPU share, orthogonal
to # of users</li> 
<li>Tyson: may or may not be</li> 
<li>Dragos: kind of action you are writing affects this (based upon what resource it
uses).</li> 
<li>Tyson: yes. if just making network calls (no memory) no reason we need to allocate</li>

<li>Tyson: of course if CPU intensive (or memory intensive) u of course need more resources
for thes things</li> 
<li>Markus: if NodeJS and other # of resource per activation</li> 
<li>Rodric: what are we guar. the suers in term of resources?</li> 
<li>Markus: we have a finite pool of resources that&nbsp;</li> 
<li>Dragos: only thing we guar. is memory, rest is shared.</li> 
<li>MB: assume we allow multi-threading (for an thought exercise).</li> 
<li> <br> 
<ul style="margin: 10px 0 0 0"> 
<li>amount of resources per-action cannot be arbitrary.&nbsp;</li> 
<li>Do you have&nbsp;</li> 
</ul> </li> 
<li>Tyson: not following question. It is possible to say that when we enable conc. actions
to same container to limit that concurrency (by my tests) this action can only support 1000
conc. users with mem. footprint of 128 megs therefore I cap. my conc. users to some # (2000
users) and assure load across containers matches need of actions</li> 
<li>MB: would have to think this through. For us, as an org. that has a commercial offering,
is the billing model.</li> 
<li> <br> 
<ul style="margin: 10px 0 0 0"> 
<li>there is some capacity we give users (with a contract) that we give users.</li>

</ul> </li> 
<li>Tyson: The time from 1st to last request, that time span for billing could be used
instead of single activation charging</li> 
<li>Rodric: the billing model could be a measure of GB seconds, but an issue that arises,
in the container that hosts that action only lives for the action, then is reclaimed</li>

<li> <br> 
<ul style="margin: 10px 0 0 0"> 
<li>for conc. reqs. does that lifespan/lifecycle mgmt. change? &nbsp;It may end
up being another “container pool” as Steve suggested (with diff. lifetime, etc.)</li>

</ul> </li> 
<li>Tyson: that is an interesting option, but not a pre-req for doing tings with conc.
activations.</li> 
<li> <br> 
<ul style="margin: 10px 0 0 0"> 
<li>The notion of the container becoming inactive for some time, then GC'ed, holds true.
What changes is the # of request being services by the container (and still affected by how
long last request left).</li> 
</ul> </li> 
<li>Rodric: measured when last request “left” the container. &nbsp;Still further
slicing granularity (splicing resource)</li> 
<li> <br> 
<ul style="margin: 10px 0 0 0"> 
<li>Inter-concurrency model / scheduling decisions become part of a diff. lifecycle
mgmt. model</li> 
</ul> </li> 
<li>Tyson: YES, absolutely there has to be a sep. pool of containers to accommodate
this new paradigm.</li> 
<li> <br> 
<ul style="margin: 10px 0 0 0"> 
<li>aside from logic when a container becomes eligible for cleanup, everything else
can behave the SAME way.</li> 
<li>a container is launched if there is a request, and cleaned up&nbsp;</li>

<li>same for single or conc. activation model. The thresholds for calc. container inactivity
would be very different.</li> 
</ul> </li> 
<li>MB: perhaps should augment proposal with this information, that is what criteria
system has for pasuign, deleting (GC'ed), etc.</li> 
<li>Tyson: sure. A working prototype would be useful, but had not gotten there yet</li>

<li>Rodric: was an early PR?</li> 
<li>Tyson: yes, it roughly showed this, but other issues seen. Earlier proposed integrating
at “invoker level” which turns out to be problematic. Really this would have to be integrated
at the Load balancer level. That fits into notion of a new&nbsp;</li> 
<li>Rodric: at LB level, treat these actions as new “kinds” and need upon this type
use different type of (pool) or some key assoc. with action to determine pool allocation as
per Steve’s examples.</li> 
<li>Rodric: since system mons. each action, it could become more intelligent on how
it handles these diff kinds of actions</li> 
<li>Tyson: yes, one way to look at is using a diff. action container (like NodeJS),
which enforces this single action proc. workflow. &nbsp;There would have to be another
container that enables that (or some config that can turn on off conc. activations)</li>

<li>Tyson: do not see that behavior at first glance in any other container?</li>

<li>Markus: it is historical. &nbsp;Early prototypes, diff. layers tried to prevent
“bad” stuff from happening, could likely safely remove those “gates”</li> 
<li>Rodric: NodeJS just happened to be first runtime we built. &nbsp;Invoker enforces
this invariance (activations) but could look at removing at container level.</li> 
<li> <br> 
<ul style="margin: 10px 0 0 0"> 
<li>Rodric could complex reasoning about applications, but Markus point is true it was
historical</li> 
</ul> </li> 
<li>Markus: this type of action invocation, needs 100% reuse? At LB level, we need to
impl. there as well as split diff workloads, but it is spec. to concurrency?</li> 
<li>Tyson” repeat?</li> 
<li>Markus: you were thinking of hooking in at the invoker leve (orig.) but u realized
u need to move to an LB?</li> 
<li>Tyson: yes. what Dragos and i discussed, there is queueing enforced at various levels,
bw. controller and activation is received at container. Kafka queueing… may or not be a
problem, but ultimately if talking about conc. processing, Kafka could become a bottleneck.
At some point iw will become a problem</li> 
<li> <br> 
<ul style="margin: 10px 0 0 0"> 
<li>Once activation reaches invoker, ther eis a sinel container pool (actor). For container
pool, ther eis a single message queue that is another plae whe</li> 
<li>Container proxy is a singleton actor, anotehr place of probelms</li> 
<li>Issues are complex, in addition to the LB level.&nbsp;</li> 
<li>Starting point is Load Balancer, but these other places we would need to look at
as well</li> 
</ul> </li> 
<li>Markus: each action is handled in fraction of an msec.</li> 
<li>Tyson: in best case milliseconds. in worst case we have exponential growth once
container pool gets used by # of conc. users</li> 
<li>Markus: that is buffering in Kafka. today invoker takes X number of activations
from bus. &nbsp;If we were to handle concurrent like 1000, we would take 100+ CPU share
from the bus… what I'm saying, the bottlenecks with singleton container is most pressing
one (and can look at)</li> 
<li> <br> 
<ul style="margin: 10px 0 0 0"> 
<li>removing Kafka is more problematic. should do this at an invoker level to start</li>

</ul> </li> 
<li>Tyson: container pool and proxy are still singletons</li> 
<li>Markus: in ur proposal (only enforcement is at container proxy)</li> 
<li>Jeremias: In queueing scenario, if queueing starts (today) how would LB behave?</li>

<li>Tyson: when container resources are exh. then nothing can be done. &nbsp;BUT
point of exhaustion changes i u allow conc. requests.</li> 
<li>Jeremias: not what i mean. &nbsp;New model proposed would still use Kafka…
once passes queueing and able to use new pool then we can look at other issues?</li>

<li>Tyson: not quite following. &nbsp;If containers are maxing out, of course there
will be queueing. what changing is # of conc. requests is &gt; than 1</li> 
<li> <br> 
<ul style="margin: 10px 0 0 0"> 
<li>so threshold at which conc. users experience latency increases</li> 
</ul> </li> 
<li>Jeremias: ok, i follow. First enforce problems on invoker/container level (before
exploring other issues) as Steve said using pools, but not attempt (now) to change the overall
flow (using Kafka etc.). If containers have a density model implemented then we could see
similar behaviors regardless of pool type.</li> 
<li>Tyson: changing the behavior of activation when it enters system</li> 
<li> <br> 
<ul style="margin: 10px 0 0 0"> 
<li>in UI app. which is delegating to API calls, it is useless to process a response
“later” because someone is listening (queueing is useless)</li> 
<li>exiting impl supposes that if there is a timeout that the client will want the response
at some point in the future, which is NOT true</li> 
<li>proposal needs diff. response handling when coming rom browser. A 200 will not be
helpful unless client knows it is using OW and starts polling for a response and has already
exceeded a latency expected for an acceptable user response.</li> 
<li>Propose we have a resp. that returns on a timeout period or returns an error, but
assumes NO FURTHER processing (queued)</li> 
</ul> </li> 
<li>Rodric: sees benefits of cancelling blocking requests (mark as cancelable)</li>

<li>MB: yes, could we leverage the timeout parm we have today?</li> 
<li>Rodric: it is conflated, based upon awareness of client (depending in client able
to poll)</li> 
<li> <br> 
<ul style="margin: 10px 0 0 0"> 
<li>should sep. this topic in a new thread of thought</li> 
</ul> </li> 
<li>Jeremias: can we solve problem without changing the request path we have today.</li>

<li>Rodric: one thought, if you consider using OW to spin up container hat is long running
and handle all requests to that one container (and OW just spins up/down) then OW may be fronting
a PaaS</li> 
<li> <br> 
<ul style="margin: 10px 0 0 0"> 
<li>If we start changing these things does OW still look like Serverless (and not some
PaaS)</li> 
</ul> </li> 
<li>MB: in my mind, what is crit. is min. the “spin up time” (also when u scale
out). Looking at Serverless OW is most advanced. &nbsp;Out sourcing to Kubernetes</li>

<li>Rodric: Fission has pre-warm pods (of containers0 where they hide latency of spin
up. Latency is issue here</li> 
<li>Markus: are we “off track” now?</li> 
<li> <br> 
<ul style="margin: 10px 0 0 0"> 
<li>Jeremias summed it up well. &nbsp;We discussed conc. thing. &nbsp;will have
logging billing and other issues. What Tyson said we need proto. that actually works without
touching the load balancer and implementing Invokers and containers to test what we can and
cannot do?</li> 
</ul> </li> 
<li>Tyson: I’ve done some experiments. Doing ti at the invoker is problematic for
reasons I described. That work not in a branch that could exhibit the issues</li> 
<li>Markus: its a pref. issue… Kafka, invoker. &nbsp;Should be impl. just in invoker?</li>

<li>Tyson: disagreeing with, but not sure how to prove it to you</li> 
<li>Markus: discuss more on Slack?</li> 
<li>Jeremias: discuss and think about and have a discussion on this point. to find out
details to test feasibility (at inv. level) and have a call if we reach that point. Reduce
the moving parts.of system today as much as possible.</li> 
<li>Tyson: interested in using Mesos to launch containers. &nbsp;Either invoker
can delegate container launching to Mesos. or Mesos would plug in at LB level…</li>

<li> <br> 
<ul style="margin: 10px 0 0 0"> 
<li>Fully appreciate it is a sep. discussion s well</li> 
</ul> </li> 
<li>Markus: all you said about LB, delegate to Mesos, or skipping “pool parts” and
going right to containers could be beneficial (remove scheduling in multiple places) in invoker
and other places</li> 
<li> <br> 
<ul style="margin: 10px 0 0 0"> 
<li>Fund. the issue is clearer than just speaking about conc. activations</li>

</ul> </li> 
<li>Dragos: ?</li> 
<li>Markus: should be able to go a long way without changing whole system,</li>

<li>Dragos: first step invoker? can we try these other paths (agreement)? &nbsp;Is
is worth having a separate conversation for HTTP?</li> 
<li>Markus: say its a sep. discussion</li> 
<li>Rodric: need to break down into smaller issues we can work on.</li> 
<li>Tyson: Next steps?</li> 
<li>Jeremias: have a few minutes</li> 
<li>Tyson: will add more detail to proposal on container lifecycle</li> 
<li> <br> 
<ul style="margin: 10px 0 0 0"> 
<li>using diff kind of container or actions that support concurrency (what to do)? jsut
mention?</li> 
<li>As Rodric said, describe cancellation option (response handling) so action developer
or client could describe their activations cancelable.</li> 
<li>in terms of changing invoker apart from LB can u provide feedback to see if that
is possible</li> 
</ul> </li> 
<li>Jeremias: also look at Steve’s proposal</li> 
<li>Tyson: not sure how to start unraveling</li> 
<li>Jeremias: do a big bang, or stepwise?</li> 
<li>Tyson: Looking at SPI &nbsp;support</li> 
<li> <br> 
<ul style="margin: 10px 0 0 0"> 
<li>would like to have a plug in approach first to help with some of these things</li>

<li>On Monday want to address current comments (apart from Markus) and get that PR accepted.</li>

<li>want a mech. to retrofit things more pluggable and allow switching out impls of
parts of system</li> 
<li>should help us test some of these exotic</li> 
</ul> </li> 
<li>Rodric: small drips, not large changes please</li> 
<li> <br> 
<ul style="margin: 10px 0 0 0"> 
<li>See us able, if comments addressed</li> 
</ul> </li> 
<li>Jeremias/: happy to try out some of this as well personally (after talking to Markus).</li>

<li>Adjourn: 11:08am US CDT</li> 
</ul> <p class="diff-context-placeholder" style="margin: 10px 0 0 0; margin-top:
0">...</p> </td> 
</tr> 
</tbody> 
</table> </td> 
</tr> 
<tr> 
<td class="email-content-main mobile-expand action-padding last-row-padding" style="padding:
0px; border-collapse: collapse; border-left: 1px solid #ccc; border-right: 1px solid #ccc;
border-top: 0; border-bottom: 0; padding: 0 15px 15px 16px; background-color: #fff; padding-bottom:
10px; padding-bottom: 10px"> 
<table id="actions-pattern" cellspacing="0" cellpadding="0" border="0" width="100%" style="border-collapse:
collapse; mso-table-lspace: 0pt; mso-table-rspace: 0pt; color: #333; font-family: Arial, sans-serif;
font-size: 14px; line-height: 20px; mso-line-height-rule: exactly; mso-text-raise: 1px">

<tbody> 
<tr> 
<td id="actions-pattern-container" valign="middle" style="padding: 0px; border-collapse:
collapse; padding: 15px 0 0 24px; vertical-align: middle"> 
<table align="left" style="border-collapse: collapse; mso-table-lspace: 0pt; mso-table-rspace:
0pt; color: #333"> 
<tbody> 
<tr> 
<td class="actions-pattern-action-icon-container" style="padding: 0px; border-collapse:
collapse; font-family: Arial, sans-serif; font-size: 14px; line-height: 20px; mso-line-height-rule:
exactly; mso-text-raise: 0px; vertical-align: middle"><a href="https://cwiki.apache.org/confluence/display/OPENWHISK/2017-07-13+Zoom+meeting+notes+on+UI+driven+use+cases?src=mail&amp;src.mail.timestamp=1499966406951&amp;src.mail.notification=com.atlassian.confluence.plugins.confluence-content-notifications-plugin%3Apage-edited-notification&amp;src.mail.recipient=8aa980875bf24635015c9267bc8e02f6&amp;src.mail.action=view"
title="View page Icon" style="color: #3b73af; text-decoration: none"><img class="actions-pattern-action-icon-image"
height="16" width="16" border="0" title="View page Icon" src="cid:com.atlassian.confluence.plugins.confluence-email-resources_view-page-email-adg-footer-item_icon"
alt="View page Icon" style="vertical-align: middle"></a></td>
<td class="actions-pattern-action-text-container" style="padding: 0px; border-collapse:
collapse; font-family: Arial, sans-serif; font-size: 14px; line-height: 20px; mso-line-height-rule:
exactly; mso-text-raise: 4px; padding-left: 5px; white-space: nowrap"><a href="https://cwiki.apache.org/confluence/display/OPENWHISK/2017-07-13+Zoom+meeting+notes+on+UI+driven+use+cases?src=mail&amp;src.mail.timestamp=1499966406951&amp;src.mail.notification=com.atlassian.confluence.plugins.confluence-content-notifications-plugin%3Apage-edited-notification&amp;src.mail.recipient=8aa980875bf24635015c9267bc8e02f6&amp;src.mail.action=view"
title="View page" style="color: #3b73af; text-decoration: none">View page</a></td>
<td class="actions-pattern-action-bull" style="padding: 0px; border-collapse: collapse;
font-family: Arial, sans-serif; font-size: 14px; line-height: 20px; mso-line-height-rule:
exactly; mso-text-raise: 4px; color: #999; padding: 0 5px">•</td> 
</tr> 
</tbody> 
</table> 
<table style="border-collapse: collapse; mso-table-lspace: 0pt; mso-table-rspace: 0pt;
color: #333"> 
<tbody> 
<tr> 
<td class="actions-pattern-action-icon-container" style="padding: 0px; border-collapse:
collapse; font-family: Arial, sans-serif; font-size: 14px; line-height: 20px; mso-line-height-rule:
exactly; mso-text-raise: 0px; vertical-align: middle"><a href="https://cwiki.apache.org/confluence/plugins/likes/like.action?contentId=73629807&amp;src=mail&amp;src.mail.timestamp=1499966406951&amp;src.mail.notification=com.atlassian.confluence.plugins.confluence-content-notifications-plugin%3Apage-edited-notification&amp;src.mail.recipient=8aa980875bf24635015c9267bc8e02f6&amp;src.mail.action=like"
title="Like Icon" style="color: #3b73af; text-decoration: none"><img class="actions-pattern-action-icon-image"
height="16" width="16" border="0" title="Like Icon" src="cid:com.atlassian.confluence.plugins.confluence-like_view-email-adg-content-item_icon"
alt="Like Icon" style="vertical-align: middle"></a></td>
<td class="actions-pattern-action-text-container" style="padding: 0px; border-collapse:
collapse; font-family: Arial, sans-serif; font-size: 14px; line-height: 20px; mso-line-height-rule:
exactly; mso-text-raise: 4px; padding-left: 5px; white-space: nowrap"><a href="https://cwiki.apache.org/confluence/plugins/likes/like.action?contentId=73629807&amp;src=mail&amp;src.mail.timestamp=1499966406951&amp;src.mail.notification=com.atlassian.confluence.plugins.confluence-content-notifications-plugin%3Apage-edited-notification&amp;src.mail.recipient=8aa980875bf24635015c9267bc8e02f6&amp;src.mail.action=like"
title="Like" style="color: #3b73af; text-decoration: none">Like</a></td> 
</tr> 
</tbody> 
</table> </td> 
</tr> 
</tbody> 
</table> </td> 
</tr> 
<tr> 
<td class="email-content-rounded-bottom mobile-expand" style="padding: 0px; border-collapse:
collapse; color: #fff; height: 5px; line-height: 5px; padding: 0 15px 0 16px; background-color:
#fff; border-bottom-right-radius: 5px; border-bottom-left-radius: 5px; border-top: 0; border-left:
1px solid #ccc; border-bottom: 1px solid #ccc; border-right: 1px solid #ccc; mso-line-height-rule:
exactly">&nbsp;</td> 
</tr> 
</tbody> 
</table> </td> 
</tr> 
<tr> 
<td id="footer-pattern" style="padding: 0px; border-collapse: collapse; padding: 12px 20px">

<table id="footer-pattern-container" cellspacing="0" cellpadding="0" border="0" width="100%"
style="border-collapse: collapse; mso-table-lspace: 0pt; mso-table-rspace: 0pt; color: #333">

<tbody> 
<tr> 
<td id="footer-pattern-links-container" width="100%" style="padding: 0px; border-collapse:
collapse; color: #999; font-size: 12px; line-height: 18px; font-family: Arial, sans-serif;
mso-line-height-rule: exactly; mso-text-raise: 2px"> 
<table align="left" style="border-collapse: collapse; mso-table-lspace: 0pt; mso-table-rspace:
0pt; color: #333; font-size: 12px; line-height: 18px; font-family: Arial, sans-serif; mso-line-height-rule:
exactly; mso-text-raise: 2px"> 
<tbody> 
<tr> 
<td class="footer-pattern-links mobile-resize-text" style="padding: 0px; border-collapse:
collapse"><a href="https://cwiki.apache.org/confluence/users/removespacenotification.action?spaceKey=OPENWHISK&amp;src=mail&amp;src.mail.timestamp=1499966406951&amp;src.mail.notification=com.atlassian.confluence.plugins.confluence-content-notifications-plugin%3Apage-edited-notification&amp;src.mail.recipient=8aa980875bf24635015c9267bc8e02f6&amp;src.mail.action=stop-watching"
title="" style="color: #3b73af; text-decoration: none">Stop watching space</a></td>
<td class="footer-pattern-links-bull" style="padding: 0px; border-collapse: collapse; padding:
0 5px; color: #999">•</td> 
</tr> 
</tbody> 
</table> 
<table style="border-collapse: collapse; mso-table-lspace: 0pt; mso-table-rspace: 0pt;
color: #333; font-size: 12px; line-height: 18px; font-family: Arial, sans-serif; mso-line-height-rule:
exactly; mso-text-raise: 2px"> 
<tbody> 
<tr> 
<td class="footer-pattern-links mobile-resize-text" style="padding: 0px; border-collapse:
collapse"><a href="https://cwiki.apache.org/confluence/users/editmyemailsettings.action?src=mail&amp;src.mail.timestamp=1499966406951&amp;src.mail.notification=com.atlassian.confluence.plugins.confluence-content-notifications-plugin%3Apage-edited-notification&amp;src.mail.recipient=8aa980875bf24635015c9267bc8e02f6&amp;src.mail.action=manage"
title="" style="color: #3b73af; text-decoration: none">Manage notifications</a></td>

</tr> 
</tbody> 
</table> </td>
<td id="footer-pattern-logo-desktop-container" rowspan="2" valign="top" style="padding:
0px; border-collapse: collapse; padding-left: 20px; vertical-align: top"> 
<table style="border-collapse: collapse; mso-table-lspace: 0pt; mso-table-rspace: 0pt;
color: #333"> 
<tbody> 
<tr> 
<td id="footer-pattern-logo-desktop-padding" style="padding: 0px; border-collapse: collapse;
padding-top: 3px"><img id="footer-pattern-logo-desktop" src="cid:footer-desktop-logo"
alt="Confluence logo big" title="Confluence logo big" width="132" height="20" class="image_fix"></td>

</tr> 
</tbody> 
</table> </td> 
</tr> 
<tr> 
<td id="footer-pattern-text" class="mobile-resize-text" width="100%" style="padding: 0px;
border-collapse: collapse; color: #999; font-size: 12px; line-height: 18px; font-family: Arial,
sans-serif; mso-line-height-rule: exactly; mso-text-raise: 2px; display: none">This message
was sent by Atlassian Confluence 5.8.17<br> <img id="footer-pattern-logo-mobile"
src="cid:footer-mobile-logo" alt="" title="" width="0" height="0" style="display: none; mso-hide:
all"></td> 
</tr> 
</tbody> 
</table> </td> 
</tr> 
</tbody> 
</table> 
<table id="sealed-section" border="0" cellpadding="0" cellspacing="0" width="0" style="border-collapse:
collapse; mso-table-lspace: 0pt; mso-table-rspace: 0pt; color: #333; display: none"> 
<tbody> 
<tr> 
<td style="padding: 0px; border-collapse: collapse; border: 0; font-size: 0px; line-height:
0; mso-line-height-rule: exactly"></td> 
</tr> 
</tbody> 
</table>
</body>
</html>
Mime
View raw message