VIP Web Services best practice for high-availability and optimal performance
search cancel

VIP Web Services best practice for high-availability and optimal performance


Article ID: 150810


Updated On:


VIP Service


VIP Web Services best practice for high-availability and optimal performance


VIP Web services


Clients that connect to VIP Services can be web applications, web services, and XML gateway appliances implemented in Java, C, C++, .NET, PHP, or other popular languages. Clients should support TLS 1.2 protocol and should have the ability to configure a trusted certificate store. (See also: VIP Services Web API Implementation Guide)
During a certificate-based mutual authentication:

  • The VIP client initiates an HTTPS call.
  • The server responds with the server certificate chain (SSL certificate and Intermediate CA) up to, but not including, the root certificate.
  • The client verifies the server certificate with the trust points that are stored in its local trust store (See also: Symantec VIP Client Auth Certificate root and intermediate CA)
  • The client sends the server the VIP certificate.
  • The server verifies the VIP certificate with the trust points stored in its local trust store.
  • After the transmission is secured, the client is authenticated and allowed to access protected services. 

Your client implementation will vary depending on your specific configuration. The following are best-practice guidelines meant to provide connectivity optimization. 

Symantec VIP Web Services (API) Best Practices for High Availability and Optimal Performance

  • Client applications must use the TLS 1.2 protocol with mutual authentication.
  • The SSL server certificates for Symantec VIP services are signed by the Root CA “VIP Organizational Root CA G1”. Include this root certificate in the trusted CA certificate store configured in client applications.
  • Leverage the Root CA as the trust anchor and not the Intermediate CA, as the Intermediate CAs are subject to change.
  • Disable DNS caching for * URLs to benefit from the VIP Services high-availability feature.
  • Restart your VIP connection service adapter after a VIP certificate change.
  • If your application is coded in Java™: Some Java JVMs cache DNS entries by default and ignore the TTL that is specified in the DNS protocol. If your application is Java-based, you need to disable this behavior by setting the networkaddress.cache.ttl and networkaddress.cache.negative.ttl Java security properties to 0. (source:
  • Enable HTTP 1.1 keep-alive to save setup costs for subsequent requests after a connection has been established.
  • Use connection pools to avoid creating new connections. Connection pool parameters will vary - refer to your Web Services library documentation on how to enable and tune connection pools.
  • For monitoring purposes, the GetServerTime API can be used to monitor connectivity from the client-side. This lightweight API provides an estimate of the lowest response time that you can expect from the client.
  • Symantec recommends an SSL timeout of up to 5 seconds and 3 retries.
  • Due to VIP Service load balancing algorithms, SSL session resumption is not supported. Enable persistent connections to prevent transaction sharing between load-balanced cluster nodes.   
  • Run any type of bulk update (such as disabling credentials of inactive users) during off-peak hours. Typically, these hours should be scheduled during weekends or between 12:00 AM PST to 3:00 AM PST.
  • Load data can be obtained directly from Symantec. Do not perform load testing on VIP end-points. 
  • VIP Web Service WSDLs, unique URLs, and product documentation are often updated when VIP server-side APIs are updated. Periodically check VIP Manager for the latest builds.
  • Enable the VIP Report Streaming Service to obtain your VIP event logs from the VIP Cloud for end-to-end logging. (see About the VIP Report Streaming Service API). 
  • Add a unique request ID with each request to locate the transaction in VIP Manager and other VIP logs. Use naming logic to identify the source of the request, such as subsystem or IP address. For example, VIP123456789 or TUSCON5_123456.
  • Consider adding the source and destination IP address to the message header to capture this data in the event logs. (see Returning IP and source information in VIP event logs)