<div dir="ltr"><div><div><div>Looks good - will try it.<br><br></div>There's also this tool - <a href="https://www.perfcake.org/">https://www.perfcake.org/</a> - developers are Red Hatters.<br><br><br></div>Thx!,<br></div>Len<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 13, 2016 at 1:49 AM, Konrad Kleine <span dir="ltr"><<a href="mailto:kkleine@redhat.com" target="_blank">kkleine@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">Hi,<div><br></div><div>to test concurrent requests to the core to measure scaling, we could use ab - Apache HTTP server benchmarking tool (<a href="https://httpd.apache.org/docs/2.4/programs/ab.html" target="_blank">https://httpd.apache.org/<wbr>docs/2.4/programs/ab.html</a>). It is a standalone binary program that's easy to use.</div><div><br></div><div>I'm sure most of you know it but just in case, here's an explanation from StackOverflow:</div><div><br></div><div>ab -k -c 350 -n 20000 <a href="http://example.com/" target="_blank">example.com/</a> </div><div><br></div><div>By issuing the command above, you will be hitting <a href="http://example.com/" target="_blank">http://example.com/</a> with 350 simultaneous connections until 20 thousand requests are met. It will be done using the keep alive header. After the process finishes the 20 thousand requests, you will receive feedback on stats. This will tell you how well the site performed under the stress you put it when using the parameters above.<br></div><div><br></div><div>I don't know any other "frameworks" for doing such kind of tests. </div><div><br></div><div>Regards,</div><div>Konrad</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 12, 2016 at 8:35 PM, Todd Mancini <span dir="ltr"><<a 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="m_4019941052119285472HOEnZb"><font color="#888888"><div><br></div><div>   -Todd</div></font></span></div><div class="m_4019941052119285472HOEnZb"><div class="m_4019941052119285472h5"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 12, 2016 at 1:47 PM, Michael Kleinhenz <span dir="ltr"><<a 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_4019941052119285472m_-8244854798427615121h5">On Wed, Oct 12, 2016 at 7:15 PM, Leonard Dimaggio <span dir="ltr"><<a 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_4019941052119285472m_-8244854798427615121h5"><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_4019941052119285472m_-8244854798427615121m_3067700840835586238HOEnZb"><font color="#888888"><br><br><br clear="all"></font></span></div><span class="m_4019941052119285472m_-8244854798427615121m_3067700840835586238HOEnZb"><font color="#888888"><div><br>-- <br><div class="m_4019941052119285472m_-8244854798427615121m_3067700840835586238m_8283823066276565633gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr">Len DiMaggio (<a 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 href="tel:978.392.3179" value="+19783923179" target="_blank">978.392.3179</a><br>cell: <a href="tel:781.472.9912" value="+17814729912" target="_blank">781.472.9912</a><br><a href="http://www.redhat.com" target="_blank">http://www.redhat.com</a><br><a href="http://community.jboss.org/people/ldimaggio" target="_blank">http://community.jboss.org/peo<wbr>ple/ldimaggio</a><br><br><img 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 href="mailto:almighty-public@redhat.com" target="_blank">almighty-public@redhat.com</a><br>
<a 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_4019941052119285472m_-8244854798427615121m_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 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 href="mailto:almighty-public@redhat.com" target="_blank">almighty-public@redhat.com</a><br>
<a 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><br>______________________________<wbr>_________________<br>
almighty-public mailing list<br>
<a href="mailto:almighty-public@redhat.com" target="_blank">almighty-public@redhat.com</a><br>
<a 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><br>______________________________<wbr>_________________<br>
almighty-public mailing list<br>
<a href="mailto:almighty-public@redhat.com">almighty-public@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/almighty-public" rel="noreferrer" target="_blank">https://www.redhat.com/<wbr>mailman/listinfo/almighty-<wbr>public</a><br>
<br></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 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 href="http://www.redhat.com" target="_blank">http://www.redhat.com</a><br><a href="http://community.jboss.org/people/ldimaggio" target="_blank">http://community.jboss.org/people/ldimaggio</a><br><br><img src="http://www.redhat.com/g/logos/RedHat_JBoss_logo.png"><br></div></div></div></div>
</div>