Run virtual services on private locations

After you have created a virtual service, you can configure it to run on a private location.

  1. Navigate to the Service virtualization tab and click Virtual services.

  2. Under Create log, enable or disable logging on the private location. If enabled, it will create one log file per virtual service on the Private Location, or if the file exists, append the log.

  3. If you plan to run the virtual service in a private location, select a preferred port in the Port field.
    preferred-port.png

Virtual services on private locations using Docker

The following best practices apply to virtual services on private locations using Docker.

On the Parameters tab of a mock service, you can configure authentication:

  1. Select an SSL authentication type:

    • No authentication (default)

    • 1-way SSL

    • 2-way SSL

  2. If you selected SSL:
    1. Select an existing Keystore or upload a new one.
    2. Provide the Keystore password and the password used to access individual keys in the keystore.
      (Optional) To define how to identify during SSL/TLS communication using an alias for a private key entry defined in your keystore, select the Alias and provide an Alias password.

Select a preferred port

If you plan to run the virtual service in a private location and you are creating a Docker-based transaction virtual service, you can define a preferred port. If the port is available, it will be assigned to the virtual service.

  • If you leave the Port field blank, a port is chosen from the range defined for the Private Location. To learn more, see Setting port range on your agent.
  • If the preferred port is outside of the defined port range, a notification message is shown and a new port within the defined range has to be entered.
  • If an existing service is running on the preferred port already, a notification message appears when you run the virtual service. BlazeMeter then selects the first available port within the defined range.

To update the preferred port for a virtual service running in a Docker-based private location, follow these steps:

  1. Stop the running virtual service.
  2. Update the existing preferred port to the new port number.
  3. Run the virtual service again.
    If the port is available, it will be assigned to the virtual service.

Virtual services on private locations using Kubernetes

The following best practices apply to virtual services on private locations using Kubernetes.

Rules for endpoints generated for Kubernetes virtual services deployment

For a private location that uses Kubernetes, the URL format is the following:

http(s)://(mock-name[40])(serviceid[9])-<port>-<namespace>.<sub-domain> 
  • Virtual service name
    First 40 lowercase alpha numeric characters of the virtual service name. If the first 40 characters of a virtual service name conflict with any other existing virtual service name, a unique ID is added to the endpoint in the following format:
    http(s)://(mock-name[40])(some uid[4])(serviceid[9])-<port>-<namespace>.<sub-domain>
  • Service ID
    ID associated with the service name. Service ID is used in the endpoints that are generated after you deploy your virtual service. When you know your service ID, you can predict the format of your virtual service endpoint.
    View the service ID in the Service drop-down list and copy it to clipboard.

    show-service-id.png

  • Port
    8080 for transaction virtual services.
  • Namespace
    Your Kubernetes namespace.
  • Sub-domain
    Configured as a part of an agent set up.
In a very rare case for virtual service deployments in a private cloud: If you specify a virtual service name to be a lowercase alphanumeric string with 128-character length, it is treated as an encoded string and the old format for endpoints is used to support backward compatibility.
The old format for transaction virtual services is the following:
http(s)://servicemock<mock_id>-8080-<k8s_namespace>.<sub-domain>

Share private locations across workspaces

If you have several BlazeMeter workspaces, you can choose to maintain separate private locations for each workspace, or share private locations across several workspaces.

Sharing private locations across multiple workspaces in service virtualization helps you to:

  • Use your private locations more efficiently.

  • Manage them more easily on the account level.

  • Deploy virtual services from any workspace that shares the location.

When a private location is shared between workspaces, virtual services remain isolated: Virtual services deployed in one workspace are not visible in another.

To learn more about sharing private locations, see Manage private locations.

To use shared locations:

  1. (For existing virtual services) Stop the virtual service and verify it is stopped.

  2. Share the location with the required workspaces.

    The Location dropdown now includes the new the shared private locations.

  3. Select a shared private location and choose a port.

  4. Start the virtual service on the shared private location.

Custom memory configuration

The following settings are optional and relevant only for virtual services running on private locations.

Depending on your use case, you may want more control over the Java heap size (Xms controls the initial heap and Xmx the maximum heap value). By default, the virtual service inherits the agent-level Xmx and Xms values.

If virtual services run on a private location, you can choose to override memory values for individual virtual services. The maximum allowed value is set by the account owner, and the customized values must remain within the account-level maximum limits. Also, Xms must not be greater than Xmx. The override is applied the next time the virtual service container starts.

These optional memory settings give you more predictable memory control while still allowing tuning for individual virtual services within the approved limit.

  1. As the account owner, navigate to the Service Virtualization tab, click Admin, and go to the Memory Settings section.

  2. Configure account-level memory settings for virtual services:
    • Memory override limits (Xmx/Xms)
      Sets the minimum and maximum JVM heap (Xmx/Xms options) that a Virtual Service's memory override may request on private locations. Enforced automatically when the Virtual Service is deployed.
      • Minimum heap (MB)
        Applies to both Xmx and Xms.
      • Maximum heap (MB)
        Applies to both Xmx and Xms. Enter 0 for unlimited.
  3. As a user, navigate to the Service Virtualization tab, and click Virtual Services.
  4. Edit a virtual service running on a private location.
  5. On the Memory tab, override account-wide JVM heap settings for individual virtual services. Your values are bound to the limits set by the account owner.
    • Xmx (MB) Sets the maximum memory allocation pool.
    • Xms (MB) Sets the initial memory allocation pool.
  6. Click Save.