Today any engineering team while working on any applications had to deal with volumes of real time data transactions, literally in millions. Our backend services are basically microservices which talks to each other on purpose. And we definitely need a high performance communication mechanism for communicate between microservices. One of the microservices is exposed public and rest of other microservices are internal. We mostly go with REST with following advantages also:

  • Easy to understand.
  • Web infrastructure is already built on top of http
  • Tools for in inspection, modification, testing are readily available.
  • Loose coupling between client and server makes changes relatively easy.
  • There are lot of frameworks in most of the widely used languages to create REST Api’s.
  • Http status codes are well defined and helps in identifying cause of problems

Despite of all the above, I wondered how did gRPC secure the goal! It’s now when I started reflecting on the pain points of REST.

  • While creating RESTful services, most of us follow a standard practice of writing client library and all we need to do is update client library whenever there is a change in api contracts.
  • Streaming is difficult and its highly impossible in most of the languages.
  • Duplex streaming is not possible.
  • Hard to get multiple resources in single request.
  • Need semantic versioning whenever the api contract needs to be changed.

How does microservices talk to each other without a client library? Had so many questions around it and found the answer. The answer is google ‘protobuf’.

This paper outlines a brief introduction of gRPC, how QA can start performance testing of the gRPC services using Gatling. Currently with many performance test tool in market like JMeter, Gatling, Locust which all are mainly based for HTTTP calls not the gRPC and how we can use Gatling for performing gRPC performance testing. The solution can be scoped to integrate into the build pipeline, thus executing the performance tests automatically.

Benefits and Takeaways : Following are the benefits and takeaways of this presentation:
a) What is gRPC and Why gRPC ?

b) Understanding of protobuf file
c) Gatling as performance tool for gRPC

d) How to write a simple performance test for gRPC
e) Test Reporting / How can we integrate with Jenkins.

 
 

Outline/Structure of the Talk

This talk outlines a brief introduction of gRPC, how QA can start performance testing of the gRPC services using Gatling. Currently with many performance test tool in market like JMeter, Gatling, Locust which all are mainly based for HTTTP calls not the gRPC and how we can use Gatling for performing gRPC performance testing. The solution can be scoped to integrate into the build pipeline, thus executing the performance tests automatically.

  • 10 - Minutes - gRPC Concepts, Why gRPC, Understanding Protobuf file
  • 5 - Minutes- Gatling as performance tool
  • 10 -Minutes - On-demand Gatling with gRPC Demo
  • 5 -Minutes- Reporting and Jenkin Integration
  • 5 - MinutesQ & A

Learning Outcome

Following are the benefits and takeaways of this presentation:

a) What is gRPC and Why gRPC ?

b) Understanding of protobuf file
c) Gatling as performance tool for gRPC

d) How to write a simple performance test for gRPC
e) Test Reporting / How can we integrate with Jenkins.

Target Audience

Test Automation Professional, Performance Engineers, Agile Testing, Testing gRPC services

schedule Submitted 10 months ago

Public Feedback


    • Krishnan Mahadevan
      keyboard_arrow_down

      Krishnan Mahadevan - My experiments with Grid

      45 Mins
      Tutorial
      Intermediate

      Everyone starts off with a simple grid setup which involves a hub and one or more nodes.

      This traditional setup is a good start but the moment one starts to get serious with the selenium grid and decide to house their own selenium grid for their local executions, that is when issues start.

      My experiences with the Selenium grid in the past couple of years has led me to get introduced some of the most prevalent problems with maintaining an in-house selenium grid.

      • Nodes get unhooked randomly due to network glitches.
      • Nodes introduce false failures due to memory leaks.
      • Selenium Grid running out of capacity.
      • Nodes require OS upgrades/patches etc.
      • Needing to deal with auto upgrades by browsers (especially chrome and firefox)

      Some of these issues I managed to fix by building a "Self Healing" Grid wherein the nodes automatically get restarted after they have serviced "n" tests. But that still didn’t solve many of these other problems.

      That was when I felt, what if there was an on-demand selenium grid.

      What if the Grid could do the following ?

      • The Grid auto scales itself in terms of the nodes based on the current load.
      • The Grid does not require a lot of infrastructure to support it.
      • The Grid can plug itself into some of the cloud providers or leverage a solution such as Docker so that the nodes can be spun and shutdown at will.

      That was how the idea of "Just Ask" an on-demand grid was born.

      Just-Ask is an on-demand grid. It has no nodes attached to it.

      It’s designed to spin off nodes on demand, run test against the newly spun off node and after test runs to completion, clean-up the node as well. The node can be backed by anything. It could be Docker (or) it could be a VM running on any of the popular clouds.

      The session aspires to walk the audience through with my experiments with the selenium grid, my learnings on the selenium grid internals and how I used all of that knowledge to build my own On Demand Selenium Grid. What better avenue to share these learnings than a Selenium Conference.

      The session will introduce the audience to the grid internals and their concepts such as

      • What is a Selenium Remote Proxy ? What is it used for? What can you do with it?
      • What is a Hub (or) Node level Servlet ? When would you need one ?
      • All of this followed by a quick demo on "Just Ask", the on-demand grid that I have built and open sourced here: https://github.com/rationaleEmotions/just-ask