<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>Hi everyone,</p>
<p>I agree that we need to consider scalability in our designs,
because it will be hard to retrofit it after the fact (for
example, thinking about how to partition our workload). However,
let's not forget that for our self-hosting goal, we're looking at
hundreds of users with limited functionality (no Che, for
example). If we can't serve this load with a single instance, I
think we're hosed anyway. <br>
</p>
<p>What I'm trying to say is that while we need to design for
scalability, we will not need the implementation of that
scalability (as in machines, scripts, measurements infrastructure)
for a while, so we should not treat that as a priority right now
IMHO.</p>
<p>/Thomas<br>
</p>
<br>
<div class="moz-cite-prefix">On 10/13/2016 09:19 PM, Leonard
Dimaggio wrote:<br>
</div>
<blockquote
cite="mid:CA+qK+9n4B8mJbrqTwjjvUkLVfK3pyNQH2spgWP4UVMkV75PWDA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>Comment in line:<br>
<br>
Agreed, this is an important topic. I'm happy to respond, as
my answers generally cause all sorts of interesting turmoil.<br>
</div>
<b>------>That is always the best type of turmoil. ;-)<br>
</b>
<div>
<div><br>
</div>
<div>How Many Users?</div>
<div><br>
</div>
<div>As many as possible. I know that's a flip answer, but
it's true. So let me rephrase the question ever so slightly
differently -- what user capacity can we handle per
'deployment unit'. I'm just making words up here, but the
basic gist is this: take a sampling of, say, EC2 machine
sizes (t2.large, c4.4xlarge, r3.2xlarge, etc.) and determine
how many simultaneous users we can comfortably accommodate
on them. We'll also need to guesstimate storage per user
(probably based upon 3 user types: low usage, average usage
and high usage). With all of that, we can start to model out
how much we need to purchase in order to support X users per
month, for any value of X.<br>
</div>
<div><b>------> Great suggestion to test with different
type of users, distinguished by frequency of use, and
level of data storage required - we will want to have a
mix of users. </b><br>
</div>
<div><br>
</div>
<div>Separately we'll model out values for X over time, and
thereby we'll be able to create a cloud budget. (e.g. "we
anticipate hosting costs of $120,000 in August to support a
predicted 750,000 users.")</div>
<div><br>
</div>
<div>But, in case it's not abundantly clear, we need to be
able to scale to tens of millions of users, with some
reasonable percentage of the population active at any point
in time (say, 10%).</div>
<div><b>------> We will have to think about the scale of
users and data and traffic per deployment unit - for an
installation of NNN users, how many deployments will we
recommend. Will we have to write a "sizing guide?"</b><br>
<br>
</div>
<div>How Many Work Items?</div>
<div><br>
</div>
<div>If you want to bucket as Small, Medium and Large
projects, that may be too coarse, but it works out to
something like 5,000; 100,000; 3,000,000. Here, again, it
may make more sense to model # of work items per user (with
low, average and high usage users), and then we can make a
model of total # of work items over time (as we'll already
have a prediction for # of users).<br>
</div>
<div><b>------> We will also have to plan for the overall
number of workitems only increasing over time unless
project teams have a way to archive closed work items.
Over time a project team may build up a huge database of
historical (and closed) workitems.</b><br>
</div>
<div><br>
</div>
<div>Required Query Performance?</div>
<div><br>
</div>
<div>This is a really hard one to answer, Most user
interactions will be via the web user interface, and here we
can employ all sorts of tricks to load the data on demand
(e.g., when you scroll down in Twitter). Really the only
metric that matters here is that the site is responsive, and
there is plenty of research out there that correlates
response time to user abandonment. (e.g. 100ms is good.
2,000ms is very bad.) In instances where there is a need to
process, say, 100,000 WIs all at once, that's generally
related to reporting and we've got more flexibility in those
cases.</div>
<div><br>
</div>
It's less important to answer "how long does it take to
process a query which returns 5,000" and more important to ask
"what do we have to do to draw a Kanban board with the 30
relevant work items from a database of 10,000,000 work items.<br>
</div>
<div><b>------> What we will want to do is to construct query
tests based on the complexity of the query and the number of
work items returned. Hmmm. I'm suddenly thinking that not
all work items will be equal in size and ease of retrieval.
A work item with many (many, many) comments and links may
require more resources to perform a query. So - we'll have
to look at work item size and complexity too.</b><br>
</div>
<div><br>
</div>
<div>Thanks again!<br>
</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, Oct 12, 2016 at 2:35 PM, Todd
Mancini <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:tmancini@redhat.com" target="_blank">tmancini@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Agreed, this is an important topic. I'm happy
to respond, as my answers generally cause all sorts of
interesting turmoil.
<div><br>
</div>
<div>How Many Users?</div>
<div><br>
</div>
<div>As many as possible. I know that's a flip answer, but
it's true. So let me rephrase the question ever so
slightly differently -- what user capacity can we handle
per 'deployment unit'. I'm just making words up here,
but the basic gist is this: take a sampling of, say, EC2
machine sizes (t2.large, c4.4xlarge, r3.2xlarge, etc.)
and determine how many simultaneous users we can
comfortably accommodate on them. We'll also need to
guesstimate storage per user (probably based upon 3 user
types: low usage, average usage and high usage). With
all of that, we can start to model out how much we need
to purchase in order to support X users per month, for
any value of X.</div>
<div><br>
</div>
<div>Separately we'll model out values for X over time,
and thereby we'll be able to create a cloud budget.
(e.g. "we anticipate hosting costs of $120,000 in August
to support a predicted 750,000 users.")</div>
<div><br>
</div>
<div>But, in case it's not abundantly clear, we need to be
able to scale to tens of millions of users, with some
reasonable percentage of the population active at any
point in time (say, 10%).</div>
<div><br>
</div>
<div>How Many Work Items?</div>
<div><br>
</div>
<div>If you want to bucket as Small, Medium and Large
projects, that may be too coarse, but it works out to
something like 5,000; 100,000; 3,000,000. Here, again,
it may make more sense to model # of work items per user
(with low, average and high usage users), and then we
can make a model of total # of work items over time (as
we'll already have a prediction for # of users).</div>
<div><br>
</div>
<div>Required Query Performance?</div>
<div><br>
</div>
<div>This is a really hard one to answer, Most user
interactions will be via the web user interface, and
here we can employ all sorts of tricks to load the data
on demand (e.g., when you scroll down in Twitter).
Really the only metric that matters here is that the
site is responsive, and there is plenty of research out
there that correlates response time to user abandonment.
(e.g. 100ms is good. 2,000ms is very bad.) In instances
where there is a need to process, say, 100,000 WIs all
at once, that's generally related to reporting and we've
got more flexibility in those cases.</div>
<div><br>
</div>
<div>It's less important to answer "how long does it take
to process a query which returns 5,000" and more
important to ask "what do we have to do to draw a Kanban
board with the 30 relevant work items from a database of
10,000,000 work items."</div>
<span class="HOEnZb"><font color="#888888">
<div><br>
</div>
<div> -Todd</div>
</font></span></div>
<div class="HOEnZb">
<div class="h5">
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, Oct 12, 2016 at 1:47
PM, Michael Kleinhenz <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:kleinhenz@redhat.com"
target="_blank">kleinhenz@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Thanks for bringing this topic up.
I think it is really important to set goals here
as soon as possible and continuously challenge
the system architecture with them. Scaling is
possibly a nasty neckbreaker when not considered
from the start. The PDD does not contain real
numbers here. </div>
<div class="gmail_extra"><br>
<div class="gmail_quote">
<div>
<div class="m_-5518398035920888817h5">On
Wed, Oct 12, 2016 at 7:15 PM, Leonard
Dimaggio <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:ldimaggi@redhat.com"
target="_blank">ldimaggi@redhat.com</a>></span>
wrote:<br>
</div>
</div>
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px
#ccc solid;padding-left:1ex">
<div>
<div class="m_-5518398035920888817h5">
<div dir="ltr">
<div>
<div>'Afternoon everyone,<br>
<br>
</div>
I wanted to start a discussion about
a topic that we'll have to consider
soon - system capacity, scalability,
responsiveness - and how we
create/run automated performance
tests. It's obviously premature to
run stress tests today, but we want
to avoid a situation where we don't
build for high performance and
scalability in the future.<br>
<br>
</div>
Some topics we should discuss: <br>
<div>
<div>
<div>
<ul>
<li>For our hosted and
on-premise service, how many
concurrent users do we want
to support?<br>
</li>
<li>For a project, how many
work items will constitute a
"small," "medium," or
"large" project?</li>
<li>What response times do we
want to support for queries
that return 10 workitems,
100 workitems, 10000
workitems<br>
</li>
<li>etc</li>
</ul>
<p>We will want to build
automated tests to verify the
performance/throughput,
reliability, etc. - Ideally
we'll start with a basic
framework for tests that can
be run directly against the
core and through the UI - and
we'll want to start building
the framework and tests early
so that they can be improved
incrementally in the sprints.</p>
Does anyone have opinions,
suggestions, requests, etc?<br>
<br>
<br>
</div>
<div>Thanks!,<br>
</div>
<div>Len D.<span
class="m_-5518398035920888817m_3067700840835586238HOEnZb"><font
color="#888888"><br>
<br>
<br clear="all">
</font></span></div>
<span
class="m_-5518398035920888817m_3067700840835586238HOEnZb"><font
color="#888888">
<div><br>
-- <br>
<div
class="m_-5518398035920888817m_3067700840835586238m_8283823066276565633gmail_signature"
data-smartmail="gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">Len
DiMaggio (<a
moz-do-not-send="true"
href="mailto:ldimaggi@redhat.com" target="_blank">ldimaggi@redhat.com</a>)<br>
JBoss by Red Hat<br>
314 Littleton Road<br>
Westford, MA 01886
USA<br>
tel: <a
moz-do-not-send="true"
href="tel:978.392.3179" value="+19783923179" target="_blank">978.392.3179</a><br>
cell: <a
moz-do-not-send="true"
href="tel:781.472.9912" value="+17814729912" target="_blank">781.472.9912</a><br>
<a
moz-do-not-send="true"
href="http://www.redhat.com" target="_blank">http://www.redhat.com</a><br>
<a
moz-do-not-send="true"
href="http://community.jboss.org/people/ldimaggio" target="_blank">http://community.jboss.org/peo<wbr>ple/ldimaggio</a><br>
<br>
<img
moz-do-not-send="true"
src="http://www.redhat.com/g/logos/RedHat_JBoss_logo.png"><br>
</div>
</div>
</div>
</div>
</div>
</font></span></div>
</div>
</div>
<br>
</div>
</div>
______________________________<wbr>_________________<br>
almighty-public mailing list<br>
<a moz-do-not-send="true"
href="mailto:almighty-public@redhat.com"
target="_blank">almighty-public@redhat.com</a><br>
<a moz-do-not-send="true"
href="https://www.redhat.com/mailman/listinfo/almighty-public"
rel="noreferrer" target="_blank">https://www.redhat.com/mailman<wbr>/listinfo/almighty-public</a><br>
<br>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<div
class="m_-5518398035920888817m_3067700840835586238gmail_signature"
data-smartmail="gmail_signature">Michael
Kleinhenz<br>
Principal Software Engineer<br>
<br>
Red Hat Deutschland GmbH<br>
Werner-von-Siemens-Ring 14<br>
85630 Grasbrunn<br>
Germany<br>
<br>
RED HAT | TRIED. TESTED. TRUSTED.<br>
Red Hat GmbH, <a moz-do-not-send="true"
href="http://www.de.redhat.com"
target="_blank">www.de.redhat.com</a>, <br>
Registered seat: Grasbrunn, Commercial
register: Amtsgericht München, HRB 153243,<br>
Managing Directors: Paul Argiry, Charles
Cachera, Michael Cunningham, Michael O'Neill</div>
</div>
<br>
______________________________<wbr>_________________<br>
almighty-public mailing list<br>
<a moz-do-not-send="true"
href="mailto:almighty-public@redhat.com"
target="_blank">almighty-public@redhat.com</a><br>
<a moz-do-not-send="true"
href="https://www.redhat.com/mailman/listinfo/almighty-public"
rel="noreferrer" target="_blank">https://www.redhat.com/mailman<wbr>/listinfo/almighty-public</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
<div class="gmail_signature" data-smartmail="gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">Len DiMaggio (<a moz-do-not-send="true"
href="mailto:ldimaggi@redhat.com" target="_blank">ldimaggi@redhat.com</a>)<br>
JBoss by Red Hat<br>
314 Littleton Road<br>
Westford, MA 01886 USA<br>
tel: 978.392.3179<br>
cell: 781.472.9912<br>
<a moz-do-not-send="true" href="http://www.redhat.com"
target="_blank">http://www.redhat.com</a><br>
<a moz-do-not-send="true"
href="http://community.jboss.org/people/ldimaggio"
target="_blank">http://community.jboss.org/people/ldimaggio</a><br>
<br>
<img moz-do-not-send="true"
src="http://www.redhat.com/g/logos/RedHat_JBoss_logo.png"><br>
</div>
</div>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
almighty-public mailing list
<a class="moz-txt-link-abbreviated" href="mailto:almighty-public@redhat.com">almighty-public@redhat.com</a>
<a class="moz-txt-link-freetext" href="https://www.redhat.com/mailman/listinfo/almighty-public">https://www.redhat.com/mailman/listinfo/almighty-public</a>
</pre>
</blockquote>
<br>
</body>
</html>