Install the FME SDK
Overview
Our SDKs are designed to live at the application layer of your application and provide a secure and out-of-the-box method for controlling your experiments and feature flags.
Each SDK has two main functions:
- Serve as a decision engine for your application
- Automatically capture what variants of your features your customers are served
Harness FME SDKs
Split SDKs are for specific languages or use cases. To choose the best SDK for your scenario, see the respective SDK documentation.
Client-side SDKs
Client-side SDK Suites
Client-side RUM Agents
Server-side SDKs
Optional Infrastructure
Decision engine
When you set up rules for your feature flags and experiments to be targeted to subsets of your customer base in Split (e.g., run a 50/50 test of a new home page on customers in New York), our SDKs automatically download down these rules and maintain a local copy of them on your machines. From there, our SDKs then take care of keeping themselves up to date by periodically checking for any changes to the rules that are made in the Split user interface.
When your application then loads for your customers, you can simply ask the SDK via a method called getTreatment to decide what variant of a feature the customer should see.
Since the SDK is maintaining a local copy of the rules that govern your features and experiments, it can simply reference that copy of your rules and make the decision to serve "on" or "off" to your customer without having to make a single remote call. From there, you can take the decision returned by our SDK and use that information to serve up the proper experience to your customer.
The getTreatment function requires a customer ID, which is usually a hash representation of the current session's customer. The SDK uses the customer ID when the feature flag includes percentage-based targeting rules (for example: 50% "On" and 50% "Off"). In this case, this is not relevant since we are assigning 100% of a single treatment. However, the SDK still requires the customer ID to calculate the treatment.
If the implementation will not use percentage-based treatments, then apply a dummy customer ID with any string value.
In this manner, our SDK is able to abstract out any need to hardcode this type of decision making in your application.
Capturing what your customer was served
Each time our SDK makes a decision of what your customer should be served, it automatically takes that information and queues it up on your machines. The SDK then takes care of all the work in passing this information up to Split in the background without ever slowing down your application.
By capturing this information, you can easily understand what customers are being served and set the basis for being able to properly measure your experiments.
Handling impressions and events load
The SDK will post the queue content when it becomes full. However, if the load consistently exceeds capacity, the queue will repeatedly fill and be posted, clearing it. Meanwhile, new impressions or events generated during this period are not stored because the queue is full, resulting in data loss.
Harness recommends verifying these SDK configuration parameters against your production generation rates for impressions and events, ensuring the SDK is properly configured to handle the load.
By default, all FME SDKs have configuration parameters that allow them to process a heavy load of generated Impressions and Events. These default parameter values are documented in the respective SDK documentation.
In the Java SDK, for example, the Configuration section includes parameters and default values for posting impressions:
impressionsRefreshRate = 60(seconds)impressionsQueueSize = 30k
These settings mean the SDK can handle up to 30,000 impressions (each generated by a single getTreatment call) every 60 seconds.
If your application generates more than 30,000 impressions per minute, you will need to adjust these parameters. For instance, generating 60,000 impressions per minute could be handled by setting:
impressionsRefreshRate = 20orimpressionsQueueSize = 70k
Harness recommends providing some buffer so the SDK can handle the actual load. If the queue size is reached, the SDK will attempt to post its contents regardless of the impression post thread’s scheduled run time.
The same concept applies to events created using the SDK’s track() method.
The relevant Java SDK parameters for posting events are:
eventFlushIntervalInMillis = 30000(30 seconds)eventsQueueSize = 500
These values allow the Java SDK to handle up to 1,000 events per minute.