Page History

...

• src/main/java
  
  • o.a.k.g.p.t.PerformanceTestRunner - this is the entry point of the tool. This class comes with a main method that reads the given configuration file and executes all enabled use-case runners
  • o.a.k.g.p.t.ResponseTimeCache - this class acts as a holder of response times and shared between the worker threads (which write into the cache) and the report generation threads (reading data from it)
  • o.a.k.g.p.t.reporting.GatewayMetricsReporter - this class generates the human-readable reports in JSON and YAML format in a fixed schedule marked by perf.test.report.generation.periodInSecs 
  • o.a.k.g.p.t.knoxtoken.KnoxTokenUseCaseRunner - this class is responsible for
    • start N worker threads that are acquiring Knox DTs parallel (marked by perf.test.usecase.knoxtoken.numOfThreads)
    • and 2 more threads to
      • renew an already acquired Knox DT
      • do an HDFS ls command using an already acquired Knox DT

  • o.a.k.g.p.t.knoxtoken.KnoxTokenWorkerThread - this represents the job which actually acquires/renews/uses Knox DTs

  • o.a.k.g.p.t.knoxtoken.KnoxTokenCache - stores the already acquired Knox DTs (if the number of DTs reaches 500 the cache is cleaned automatically)
• src/test/resources
  • performance.test.configuration.properties - contains the above-described configuration file
  • performanceTest-log4j.properties - the Log4j configuration of the tool. By default, it prints log messages on the STDOUT as well as writes them into target/logs/performanceTest.log

...

    <property>
        <name>gateway.metrics.enabled</name>
        <value>true</value>
    </property>
    <property>
        <name>gateway.jmx.metrics.reporting.enabled</name>
        <value>true</value>
    </property>

Once you opened the necessary JMX port, you also need to make sure you have at least one topology with the KNOXTOKEN service. During my tests, I extended the sandbox topology with the following service configuration:

   <service>
      <role>KNOXTOKEN</role>
      <param>
         <name>knox.token.ttl</name>
         <value>36000000</value>
      </param>
      <param>
         <name>knox.token.audiences</name>
         <value>tokenbased</value>
      </param>
      <param>
         <name>knox.token.target.url</name>
         <value>https://localhost:8443/gateway/tokenbased</value>
      </param>
      <param>
         <name>knox.token.exp.server-managed</name>
         <value>true</value>
      </param>
      <param>
         <name>knox.token.renewer.whitelist</name>
         <value>guest</value>
      </param>
   </service>

If you plan to create a new topology for this purpose, please change the perf.test.usecase.knoxtoken.topology.gateway configuration accordingly.

As you can see, the newly added service references another topology called tokenbased. As its name suggests, that particular topology uses JWT authentication and is configured as follows:

<?xml version="1.0" encoding="UTF-8"?>
<topology>
   <name>tokenbased</name>
   <gateway>
      <provider>
         <role>federation</role>
         <name>JWTProvider</name>
         <enabled>true</enabled>
         <param>
            <name>knox.token.audiences</name>
            <value>tokenbased</value>
         </param>
      </provider>
   </gateway>
   <service>
      <role>WEBHDFS</role>
      <url>http://YOUR_HDFS_SERVICE_HOST:20101/webhdfs</url>
   </service>
</topology>

Since the KnoxToken Use Case tries to use an already acquired Knox DT to run an action I chose to do this as simple as possible: using KnoxShell's HDFS

How to run

Running the performance tool is as simple as running the following Maven command in the project root:

...