jmeter-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From fschumac...@apache.org
Subject svn commit: r1723156 - /jmeter/trunk/xdocs/devguide-dashboard.xml
Date Tue, 05 Jan 2016 20:39:14 GMT
Author: fschumacher
Date: Tue Jan  5 20:39:13 2016
New Revision: 1723156

URL: http://svn.apache.org/viewvc?rev=1723156&view=rev
Log:
Use spaces instead of tabs.

Modified:
    jmeter/trunk/xdocs/devguide-dashboard.xml

Modified: jmeter/trunk/xdocs/devguide-dashboard.xml
URL: http://svn.apache.org/viewvc/jmeter/trunk/xdocs/devguide-dashboard.xml?rev=1723156&r1=1723155&r2=1723156&view=diff
==============================================================================
--- jmeter/trunk/xdocs/devguide-dashboard.xml (original)
+++ jmeter/trunk/xdocs/devguide-dashboard.xml Tue Jan  5 20:39:13 2016
@@ -1,14 +1,14 @@
 <?xml version="1.0"?>
 <!-- Licensed to the Apache Software Foundation (ASF) under one or more contributor 
-	license agreements. See the NOTICE file distributed with this work for additional 
-	information regarding copyright ownership. The ASF licenses this file to 
-	You under the Apache License, Version 2.0 (the "License"); you may not use 
-	this file except in compliance with the License. You may obtain a copy of 
-	the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required 
-	by applicable law or agreed to in writing, software distributed under the 
-	License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS 
-	OF ANY KIND, either express or implied. See the License for the specific 
-	language governing permissions and limitations under the License. -->
+  license agreements. See the NOTICE file distributed with this work for additional 
+  information regarding copyright ownership. The ASF licenses this file to 
+  You under the Apache License, Version 2.0 (the "License"); you may not use 
+  this file except in compliance with the License. You may obtain a copy of 
+  the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required 
+  by applicable law or agreed to in writing, software distributed under the 
+  License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS 
+  OF ANY KIND, either express or implied. See the License for the specific 
+  language governing permissions and limitations under the License. -->
 
 <!DOCTYPE document[
 <!ENTITY hellip   "&#x02026;" >
@@ -16,208 +16,208 @@
 
 <document id="$Id$">
 
-	<properties>
-		<title>Developer's guide: Dashboard generator</title>
-	</properties>
-
-	<body>
-
-		<section name="Dashboard generator">
-			<p>
-				This document describes the architecture and operation of the
-				dashboard
-				generation engine.
-			</p>
-			<subsection name="1 Overview" anchor="overview">
-				<subsection name="1.1 Architecture" anchor="overview_architecture">
-					<p>
-						The dashboard generation engine is a modular feature based on
-						samples operation processus.
-						<br />
-						The processus can be represented by
-						the following diagram :
-					</p>
-					<figure image="dashboard.png">Figure 1 - Dashboard generation overview</figure>
-					<p>
-						In this view, you can see :
-						<ul>
-							<li>
-								A source from where samples are produced (E.g: CSV file).
-							</li>
-							<li>
-								A chain of items, named consumers, that do operations
-								from
-								samples that go through the chain.
-								(E.g: Filtering, sorting,
-								calculation, ...)
-							</li>
-							<li>
-								An execution context, named sample context, where the results
-								of
-								consumers calculations are stored.
-							</li>
-							<li>
-								A set of items, named exporters, that use the content of the
-								sample context to generate a final result to the user (E.g. :
-								Html page generation).
-							</li>
-						</ul>
-					</p>
-				</subsection>
-				<subsection name="1.2 Operation" anchor="overview_operation">
-					<p>
-						Before producing samples, the source is associated with a sample
-						context that will be used to store the consumers results.
-					</p>
-					<p>
-						Then a
-						chain of consumers is built using JMeter properties
-						(prefixed by
-						<code>jmeter.reportgenerator</code>
-						) in order to enable the user to customize it.
-					</p>
-					<p>
-						When the source
-						emits a sample, it sends it to the first consumer
-						of
-						the chain.
-						<br />
-						The consumer can have different behaviors :
-						<ul>
-							<li>It can process the sample and sends it to the next
-								consumers.</li>
-							<li>It cannot process the sample, so it stores it and
-								continues to
-								receive other samples. When it can process the
-								stored samples, it
-								does and sends the whole to the next
-								consumers (E.g: sorting).</li>
-							<li>It can choose to discard the sample (E.g:
-								filtering).</li>
-						</ul>
-						When the source stops samples producing, consumers can publish a
-						result in the sample context.
-						<br />
-						The latter is send to the set of
-						exporters in order to create
-						results used by final user.
-					</p>
-				</subsection>
-			</subsection>
-
-			<subsection name="2 Consumers chain details" anchor="consumers_chain">
-				<p>
-
-				</p>
-				<figure image="chain.png">Figure 2 - Consumers chain</figure>
-				<p>
-					The chain begins with a normalizer consumer in charge of
-					standardizing the timestamp of each sample because JMeter allows
-					different timestamp formats (See :
-					<code>jmeter.save.saveservice.timestamp_format</code>
-					).
-				</p>
-				<p>
-					Then two consumers have to define the start time and end time of
-					the load tests.
-				</p>
-				<p>
-					At the same level a filter consumer keeps or
-					discards samples
-					depending on the
-					<code>jmeter.reportgenerator.sample_filter</code>
-					property.
-				</p>
-				<p> Another filter is plugged after to discard controller
-					samples.
-				</p>
-				<p>
-					Depending on the property
-					<code>jmeter.reportgenerator.graph.&lt;graph_id&gt;.exclude_controllers</code>
-					, the graph consumer matching the graph_id identifier will be
-					set at
-					position A or B.
-				</p>
-			</subsection>
-
-			<subsection name="3 Limitations and Outlooks" anchor="outlooks">
-				<ul>
-					<li>
-						<p>Till now, there is only one sample source implementation which
-							is strongly coupled with the CSV file format, we should allow
-							other kinds of source by using a sample source interface.</p>
-					</li>
-					<li>
-						<p>To add customized graph, users must extend the
-							AbstractGraphConsumer or use one of the implementations provided
-							in
-							the package “org.apache.jmeter.report.processor.graph.impl”.
-							This
-							could be enhanced by making concrete the base class and give
-							public
-							access to additional properties (like selectors). But first
-							we have
-							to resolve the issue of shared properties (E.g : over time
-							graphs
-							must dispatch the same granularity property to the keys
-							selector
-							and time rate aggregator).</p>
-					</li>
-					<li>
-						<p>
-							The chain building is dispatched between the
-							org.apache.jmeter.report.dashboard.ReporGenerator.generate method
-							and the implementation of the consumers. So the code in charge of
-							the building is splitted and furthermore some consumers can be
-							redundants and harm the performance of report generation, not
-							load testing.
-						</p>
-						<p>
-							E.g: Each LatencyVSRequestGraphConsumer and
-							ResponseTimeVSRequestGraphConsumer instances use an embedded
-							consumer that could be shared depending on granularity and
-							exclude_controllers properties.
-						</p>
-						<p>
-							So we should enable the consumers to define the chain they
-							require
-							and provide a single chain builder that processes these
-							chain
-							requirements to instantiate needed consumers on demand. I.e,
-							for
-							the same chain requirement declaration, the same consumer
-							instances
-							are used. Otherwise if the declaration differs a new
-							branch of
-							consumers is created.
-						</p>
-					</li>
-					<li>
-						<p>
-							The graphs (DOM elements) in the generated html page should be
-							dynamicaly build in order to match the graphs defined in jmeter
-							properties.
-						</p>
-					</li>
-					<li>
-						<p>
-							Some improvements can be done on the generated html pages :
-							<ul>
-								<li>Using a single page, and hide graphs depending on the
-									navigation menu selection.</li>
-								<li>Adding a loading animation when graphs are build or
-									refreshed.</li>
-								<li>Let the user determine if a graph is zoomable using a jmeter
-									property.</li>
-								<li>Using the jquery.plot.setData() method to handle series
-									activation/deactivation rather than rebuild the graph.</li>
-							</ul>
-						</p>
-					</li>
-				</ul>
-			</subsection>
-		</section>
+  <properties>
+    <title>Developer's guide: Dashboard generator</title>
+  </properties>
+
+  <body>
+
+    <section name="Dashboard generator">
+      <p>
+        This document describes the architecture and operation of the
+        dashboard
+        generation engine.
+      </p>
+      <subsection name="1 Overview" anchor="overview">
+        <subsection name="1.1 Architecture" anchor="overview_architecture">
+          <p>
+            The dashboard generation engine is a modular feature based on
+            samples operation processus.
+            <br />
+            The processus can be represented by
+            the following diagram :
+          </p>
+          <figure image="dashboard.png">Figure 1 - Dashboard generation overview</figure>
+          <p>
+            In this view, you can see :
+            <ul>
+              <li>
+                A source from where samples are produced (E.g: CSV file).
+              </li>
+              <li>
+                A chain of items, named consumers, that do operations
+                from
+                samples that go through the chain.
+                (E.g: Filtering, sorting,
+                calculation, ...)
+              </li>
+              <li>
+                An execution context, named sample context, where the results
+                of
+                consumers calculations are stored.
+              </li>
+              <li>
+                A set of items, named exporters, that use the content of the
+                sample context to generate a final result to the user (E.g. :
+                Html page generation).
+              </li>
+            </ul>
+          </p>
+        </subsection>
+        <subsection name="1.2 Operation" anchor="overview_operation">
+          <p>
+            Before producing samples, the source is associated with a sample
+            context that will be used to store the consumers results.
+          </p>
+          <p>
+            Then a
+            chain of consumers is built using JMeter properties
+            (prefixed by
+            <code>jmeter.reportgenerator</code>
+            ) in order to enable the user to customize it.
+          </p>
+          <p>
+            When the source
+            emits a sample, it sends it to the first consumer
+            of
+            the chain.
+            <br />
+            The consumer can have different behaviors :
+            <ul>
+              <li>It can process the sample and sends it to the next
+                consumers.</li>
+              <li>It cannot process the sample, so it stores it and
+                continues to
+                receive other samples. When it can process the
+                stored samples, it
+                does and sends the whole to the next
+                consumers (E.g: sorting).</li>
+              <li>It can choose to discard the sample (E.g:
+                filtering).</li>
+            </ul>
+            When the source stops samples producing, consumers can publish a
+            result in the sample context.
+            <br />
+            The latter is send to the set of
+            exporters in order to create
+            results used by final user.
+          </p>
+        </subsection>
+      </subsection>
+
+      <subsection name="2 Consumers chain details" anchor="consumers_chain">
+        <p>
+
+        </p>
+        <figure image="chain.png">Figure 2 - Consumers chain</figure>
+        <p>
+          The chain begins with a normalizer consumer in charge of
+          standardizing the timestamp of each sample because JMeter allows
+          different timestamp formats (See :
+          <code>jmeter.save.saveservice.timestamp_format</code>
+          ).
+        </p>
+        <p>
+          Then two consumers have to define the start time and end time of
+          the load tests.
+        </p>
+        <p>
+          At the same level a filter consumer keeps or
+          discards samples
+          depending on the
+          <code>jmeter.reportgenerator.sample_filter</code>
+          property.
+        </p>
+        <p> Another filter is plugged after to discard controller
+          samples.
+        </p>
+        <p>
+          Depending on the property
+          <code>jmeter.reportgenerator.graph.&lt;graph_id&gt;.exclude_controllers</code>
+          , the graph consumer matching the graph_id identifier will be
+          set at
+          position A or B.
+        </p>
+      </subsection>
+
+      <subsection name="3 Limitations and Outlooks" anchor="outlooks">
+        <ul>
+          <li>
+            <p>Till now, there is only one sample source implementation which
+              is strongly coupled with the CSV file format, we should allow
+              other kinds of source by using a sample source interface.</p>
+          </li>
+          <li>
+            <p>To add customized graph, users must extend the
+              AbstractGraphConsumer or use one of the implementations provided
+              in
+              the package “org.apache.jmeter.report.processor.graph.impl”.
+              This
+              could be enhanced by making concrete the base class and give
+              public
+              access to additional properties (like selectors). But first
+              we have
+              to resolve the issue of shared properties (E.g : over time
+              graphs
+              must dispatch the same granularity property to the keys
+              selector
+              and time rate aggregator).</p>
+          </li>
+          <li>
+            <p>
+              The chain building is dispatched between the
+              org.apache.jmeter.report.dashboard.ReporGenerator.generate method
+              and the implementation of the consumers. So the code in charge of
+              the building is splitted and furthermore some consumers can be
+              redundants and harm the performance of report generation, not
+              load testing.
+            </p>
+            <p>
+              E.g: Each LatencyVSRequestGraphConsumer and
+              ResponseTimeVSRequestGraphConsumer instances use an embedded
+              consumer that could be shared depending on granularity and
+              exclude_controllers properties.
+            </p>
+            <p>
+              So we should enable the consumers to define the chain they
+              require
+              and provide a single chain builder that processes these
+              chain
+              requirements to instantiate needed consumers on demand. I.e,
+              for
+              the same chain requirement declaration, the same consumer
+              instances
+              are used. Otherwise if the declaration differs a new
+              branch of
+              consumers is created.
+            </p>
+          </li>
+          <li>
+            <p>
+              The graphs (DOM elements) in the generated html page should be
+              dynamicaly build in order to match the graphs defined in jmeter
+              properties.
+            </p>
+          </li>
+          <li>
+            <p>
+              Some improvements can be done on the generated html pages :
+              <ul>
+                <li>Using a single page, and hide graphs depending on the
+                  navigation menu selection.</li>
+                <li>Adding a loading animation when graphs are build or
+                  refreshed.</li>
+                <li>Let the user determine if a graph is zoomable using a jmeter
+                  property.</li>
+                <li>Using the jquery.plot.setData() method to handle series
+                  activation/deactivation rather than rebuild the graph.</li>
+              </ul>
+            </p>
+          </li>
+        </ul>
+      </subsection>
+    </section>
 
-	</body>
+  </body>
 </document>
 



Mime
View raw message