Intro

During API development it’s very interesting/required to test the application in terms of response time for different loads. I’m using gatling for some tests here and it’s quite neat.

Apache JMeter

JMeter I’ll do a post about it later – which is not a browser, btw. I don’t know why they highlight this on the web site.

Loadrunner

Loadrunner, which Thread-based architecture, is actually from a company called Micro Focus – not opensource in fact!.

Gatling

It’s a tool to test loads since it’s based on messages, tests based on Scala – yup, not java or javascript. It overwrites the JVM limitations, therefore, so we can make much more accesses.

It uses to test http basically and the records the GUI.

Executing a performance test straight from the console.

It does not monitor back-end monitoring, as resources monitoring, like htop on the server.

 

 Class HttpSimulation1 extends Simulation {

  /* Place for arbitrary Scala code that is to be executed before the simulation begins. */

  before {

      println(“***** My simulation is about to begin! *****”)

  }

  /* Place for arbitrary Scala code that is to be executed after the simulation has ended. */

  after {

      println(“***** My simulation has ended! ******”)

  } 

  /*

   * A HTTP protocol builder is used to specify common properties of request(s) to be sent,

   * for instance the base URL, HTTP headers that are to be enclosed with all requests etc.

   */

  val theHttpProtocolBuilder = http

      .baseURL(“http://computer-database.gatling.io”)

   /*

   * A scenario consists of one or more requests. For instance logging into a e-commerce

   * website, placing an order and then logging out.

   * One simulation can contain many scenarios.

   */

  /* Scenario1 is a name that describes the scenario. */

  val theScenarioBuilder = scenario(“Scenario1”)

      .exec(

          /* myRequest1 is a name that describes the request. */

          http(“myRequest1”)

              .get(“/”)

       )

  /*

   * Define the load simulation.

   * Here we can specify how many users we want to simulate, if the number of users is to increase

   * gradually or if all the simulated users are to start sending requests at once etc.

   * We also specify the HTTP protocol builder to be used by the load simulation

   */

  setUp(

      theScenarioBuilder.inject(atOnceUsers(1))

  ).protocols(theHttpProtocolBuilder)

}

Code from Krizsan, found here

REFs

 

Intro

It’s quite nice to work and develop some tools, but the basis should be learned first, and here there is a small but good/required list of courses to do.

Free Courses

Django

Kubernetes

Red Hat free courses

Intro

Ok, quick stuff, just reading about Undertow, I didn’t know it was so flexible actually.

Undertow two way to do it:

Way 1

There is basically two way to use undertow, and in fact,  I already made a post about the first way here, the idea is simple: use the Builder API after we create the handler we want as in here. The listener on the example is created for the port 8080, i.e. bind to localhost.

The builder will default values for performance-related stuff, as a number of threads and buffers.

public class HelloWorldServer {

    public static void main(final String[] args) {
        Undertow server = Undertow.builder()                                                    //Undertow builder
                .addHttpListener(8080, "localhost")                                             //Listener binding
                .setHandler(new HttpHandler() {                                                 //Default Handler
                    @Override
                    public void handleRequest(final HttpServerExchange exchange) throws Exception {
                        exchange.getResponseHeaders().put(Headers.CONTENT_TYPE, "text/plain");  //Response Headers
                        exchange.getResponseSender().send("Hello World");                       //Response Sender
                    }
                }).build();
        server.start();
    }

}

Way 2

Otherwise, the second way to do stuff is by manually assembling stuff to create a server.

The main steps are described here:

1. Create an XNIO Worker. This worker manages both the IO and Worker threads for the server.
2. Create an XNIO SSL instance (optional, only required if HTTPS is in use)
3. Create an instance of the relevant Undertow listener class
4. Open a server socket using XNIO and set its accept listener

 

 

REFs

http://undertow.io/

 

Intro

From a variety of reasons, we plan to move from WebSphere to Jboss, but just following the guide here that we will be able to do it.  There will be things that will need to be adapted – keep in my the following:

Migrating Websphere to JBoss

As rule, we have to follow the basic steps

1) port over the server side resources.

2) create JBoss deployment descriptors.

3) install the application

4) resolve anything that does not conform to or violates the JEE spec.

REFs

[1] https://docs.jboss.org/author/display/AS72/How+do+I+migrate+my+application+from+WebSphere+to+AS+7

 

Practical Java performance tuning

Learning from Benjamin Evans and James Gough, on java was really good, the video is not open I guess, but can be accessed on O’Reilly platform.

They highlight the fact that performance is never alone, you always learning together. Starting with cache misses, and other basic issues they build upon that.

REFs

[1]https://www.oreilly.com/learning/practical-java-performance-tuning

 

 

Intro

Today I’ll describe two tools for GC: GCViwer and JMeter.

In Eclipse you just need to do:

-Xloggc:/whatever/Downloads/LOG.log -verbose:gc

> in the server configuration as shown here Garbagecat

GCViewer

This is a tool for quite look up on GC files. Just download the source and run mvn clean install and it’s all done.

Here below is one of my experiments with a gc.log file in the GC viewer. Just used [viewer] [log.file] and it will pop up:

JMeter

JVM tuning is not a magic trick. So JMeter is a way to stop the gambling and magic and do some metrics based on load simulations, so then we can tune the JVM options for the optional.

Unified JVM logger

Well, the JEPS 158, Java 9, introduces a unified logger mechanism.

REFs

The source or GCViwer.

The JMeter can be found here

Intro

“Formal semantics can avoid stupid errors, for example, programs that give different results for different for different compilers version.” – Prof Grigore Rosu.

K-framework

K-framework, from the Runtime Verification team, and by the group of Prof Grigore Rosu at University Urbana Campaign.

A Meta-language

K-framework is a language to describe other languages.

Smart-contract utilization

His main idea is to use the k-framework to verify smart contracts.

REFs

Youtube interview with Prof Grigore Rosu

 

On JBoss the Broker was HornetQ and for JBoss 7 the Broker is actually ActiveMQ Artemis. Interesting switch.

Someone asked about the fact that sometimes the verbs are out of order in my posts. Even missing verbs. Well, full disclosure here, I’m dyslexic and the more I learn German the worse my English gets. As my Italian degrades my French too. I don’t know why.   Thanks, Grammarly.