Scale Up Mock Service Performance Using Instances

This feature is accessible only to a select set of enterprise-tier customers.

BlazeMeter Performance Tests support horizontal scaling for Mock Services. You use Mock Services to achieve consistent performance while testing software components independently of external services.

For high-load performance tests scenarios, a single Mock Service can become a bottleneck. If you notice timeout errors or higher response times during a large-scale performance test, we recommend creating multiple instances of your Mock Services.

• How Many Mock Service Instances Can I Use?
• How Do I Enable Mock Service Instances in the Public Cloud?
• How Do I Enable Mock Service Instances On Premise?
• Configure the Load Balancer
• Configure the Ingress Controller
• Configure the Nginx Environment
• How Do I Use Mock Service Instances?
• How Do I Create a Mock Service with Instances Using the Public API?
• What is the Right Number of Instances for My Load?
• Public Cloud with Instances
• Docker set-up in a Private Location without Instances

How Many Mock Service Instances Can I Use?

The number of available Mock Service Instances in your account depends on the usage plan that you are subscribed to.

• Enterprise customers have access to up to several Instances per Mock Service.
• The free tier comes with one Instance per Mock Service.

How Do I Enable Mock Service Instances in the Public Cloud?

Enterprise users of the public cloud do not need any set-up to use Mock Service Instances.

How Do I Enable Mock Service Instances On Premise?

If you use BlazeMeter in a private location, provide the Instances through Kubernetes environments. One Instance is one Kubernetes pod replica of a given Mock Service. Please refer to the official documentation on how to install Crane on a Kubernetes location.

For more information on how to install Crane on either Docker or Kubernetes, see Installing the Agent.

Configure the Load Balancer

To be able to process high load, there need to be enough resources for handling incoming connections. Configure an ingress and a load balancer suitable for your system, for example, using Nginx.

Tip: Some performance tips:

• Tweak the keep-alive parameter (see code sample) to limit the number of created connections.
• Tweak your resources to have as many connections available as needed on each Nginx pod.
• Add Nginx pods if one is not enough to handle the required load.

Configure the Ingress Controller

The following code shows an example of how to configure the Ingress controller using Kubernetes deployment.

Number of pods: 30

spec:
  replicas: 30

Resource configuration for each pod:

        resources:
          limits:
            cpu: "8"
            memory: 32Gi
          requests:
            cpu: "4"
            memory: 8Gi

Health check configuration:

Under large loads, increase the default timeout for the health check, which can cause the pod to be restarted even if it works fine.

  livenessProbe:
          failureThreshold: 3
          httpGet:
            path: /healthz
            port: 10254
            scheme: HTTP
          initialDelaySeconds: 10
          periodSeconds: 10
          successThreshold: 1
          timeoutSeconds: 60

Configure the Nginx Environment

Configure Nginx using a Kubernetes configmap. For more information, see Introduction - NGINX Ingress Controller.

Baseline nginx configmap setup:

  disable-access-log: "true"
  enable-underscores-in-headers: "true"
  http-snippet: |
    sendfile on;
  keep-alive: "240"
  keep-alive-requests: "50000"
  limit-conn-status-code: "429"
  limit-rate: "0"
  limit-rate-after: "0"
  limit-req-status-code: "408"
  max-worker-connections: "0"
  max-worker-open-files: "0"
  proxy-connect-timeout: "120"
  proxy-read-timeout: "120"
  proxy-send-timeout: "120"
  reuse-port: "true"
  ssl-redirect: "false"
  upstream-keepalive-connections: "50"
  upstream-keepalive-requests: "50000"
  upstream-keepalive-timeout: "300"
  worker-cpu-affinity: auto
  worker-processes: auto

How Do I Use Mock Service Instances?

Testers can use Instances together with the Think Time parameter to simulate the expected response time of a real service.

You define the Number of Instances in the Parameters tab of the Mock Service definition. The default is one. The possible maximum value depends on your usage plan.

After you define the Number of Instances setting for a Mock Service and start it, the instances are automatically provisioned. From your point of view as the user, the instances appear behind a single Mock Service endpoint.

How Do I Create a Mock Service with Instances Using the Public API?

If you are using the public Mock Service API, provide the numeric replicas value in the POST call when you create the Mock Service. The default is one (1).

What is the Right Number of Instances for My Load?

The following reference table shows baseline values of the response time to expect for different numbers of Instances used under different loads.

Public Cloud with Instances

The results apply to Mock Services provisioned by the BlazeMeter public cloud. The Mock Service and Load Generators were located in the same location, "US East Virginia" in the Google Cloud Platform.

The following values are a reference how the on-premise cluster of the Public cloud is configured:

Mock Service configuration:

• Number of Transactions: 10
• Think Time: 250 ms
• Response Size: 1 KB

Results:

Docker set-up in a Private Location without Instances

The following reference value is a baseline value for MockServices running as a single docker container in a private location, for comparison. The metrics have been measured with the wrk benchmarking tool. The mock service runs on a VM that was configured with CentOS, 16 CPUs, and 32 GB RAM.

Mock Service configuration:

• Number of Transactions: 10
• Think Time: 0 ms
• Response Size: 1 KB

Results:

• Response load: ~39000 hits per second