Performance

How do writes and updates to an EdgeKV item impact read performance?

When you make a request for an EdgeKV item from EdgeWorkers, the edge server executing the EdgeWorkers code stores a local copy of the item. Subsequent reads of that item from EdgeWorkers executing on the same edge server will be very fast. The read does not need to go back to the persistent data store to fetch the item.

When you update an item (write or delete), it sends a signal to all edge servers that have a copy of that item to indicate that the local copy is no longer valid. Subsequent reads of that item will trigger a request to go back to the persistent store to fetch the updated version of the item. This request will be slower. A local copy is then kept and the cycle repeats.

For scaling reasons, it is not possible to have a single signal for each item in the key value store. A fixed set of signals map all items using a hashing algorithm. This means that when one item is updated, any other items that hash to the same signal are invalidated. To determine if those items have changed, the request must go back to the persistent store which adds delay to the read operation. This is a one-time impact per item per edge server as the item status, and value if applicable, is locally updated.

For optimal read performance try to maintain an average of more than 98 reads for every 2 writes to a key value store. You can also refer to the recommended limit on the number of distinct items that can be written per second to minimize the impact that writes have on read performance.

Does writing data to one namespace impact the performance of another namespace?

It is possible since the invalidation mechanism mentioned above applies across all namespaces. You cannot apply the invalidation mechanism on a per namespace basis.

How should I select the namespace geoLocation?

When reading an EdgeKV item, the local copy of that item is checked on the edge server executing the EdgeWorkers function. If a local copy is not present due to a cold hit, or it is invalid due to an update the request has to go all the way back to the persistent store to retrieve the item. The location of the item’s persistent store is one of several replicas within the geoLocation that is configured for the namespace from which the item is being requested. To minimize the latency for cold hits, you should configure the namespace geoLocation at the location closest to the majority of your end users.

For example, if most of your end users are in North America, you should choose the US geoLocation for the namespace used to service requests.

What is the expected EdgeKV performance from an EdgeWorker?

Latency of EdgeKV read requests is on par with that of Akamai’s CDN cached content when a copy of the requested item is present on the edge server executing the EdgeWorker making the request to EdgeKV.

If the EdgeKV request has to go to the persistent store to fetch the item, the latency is dictated by the proximity of the edge server to the closest persistent store replica. This is in turn influenced by the configured namespace geoLocation.

EdgeKV write and delete requests:

Always go to the persistent store.
Need to be replicated across all nodes within the configured namespace geoLocation.
The proximity of the Edge server to the configured namespace geoLocation dictates the latency of a request.
The latency to replicate the data within that geoLocation also dictates the latency of a request. Note that EdgeKV writes/deletes are always performed with strong consistency. For example, the data must be successfully written to or deleted from all replicas before the operation completes.

How can I improve the performance of EdgeKV requests?

Here are some recommendations to improve the performance of EdgeKV requests to an EdgeWorkers function:

Minimize updates, write and delete operations, to the data in the EdgeKV store. If possible, make batch updates during low traffic periods to minimize the impact of invalidation on read performance.
Maintain a read/write ratio of 98/2 read/write or better.
Do not exceed the recommended number of items per namespace or per account. See the Product limits for more information.
Avoid storing large items in EdgeKV, as large items incur more latency when requested from or written to the persistent store.
Consider your data model to avoid long tail data. The performance of frequently read items is higher than that of items seldom accessed.
Ensure that you select the geoLocation namespace closest to location of the majority of your end users.
If you don't need to validate the completion of the operation, you can use one of the following EdgeKV JavaScript methods to perform write or delete operations:

As a distributed key-value store, how is EdgeKV data stored to be performant, and to achieve redundancy and fault tolerance?

When data is written to EdgeKV, it is replicated across multiple instances of the persistent store within the geoLocation of the specified namespace. A copy of the data also exists on every edge server executing a read request for that data from an EdgeWorkers function.