Remote

Description

This remote online store lets you interact with a remote feature server. You can use this online store to retrieve online features via store.get_online_features() from a remote feature server.

Examples

The registry is pointing to registry of remote feature store. If it is not accessible then should be configured to use remote registry.

feature_store.yaml
project: my-local-project
registry: /remote/data/registry.db
provider: local
online_store:
  path: http://localhost:6566
  type: remote
  cert: /path/to/cert.pem
entity_key_serialization_version: 3
auth:
  type: no_auth

cert is an optional configuration to the public certificate path when the online server starts in TLS(SSL) mode. This may be needed if the online server is started with a self-signed certificate, typically this file ends with *.crt, *.cer, or *.pem.

Connection Pooling Configuration

The remote online store uses HTTP connection pooling to improve performance by reusing TCP/TLS connections across multiple requests. This significantly reduces latency by avoiding the overhead of establishing new connections for each request.

Configuration Options

Option
Type
Default
Description

connection_pool_size

int

50

Maximum number of connections to keep in the pool. Increase for high-concurrency workloads.

connection_idle_timeout

int

300

Maximum time in seconds a session can be idle before being closed. Set to 0 to disable idle timeout.

connection_retries

int

3

Number of retries for failed requests with exponential backoff.

Example with Connection Pooling

Use Cases

High-throughput workloads:

Long-running services:

Resource-constrained environments:

Performance Benefits

Connection pooling provides significant latency improvements:

  • Without pooling: Each request requires a new TCP connection (~10-50ms) and TLS handshake (~30-100ms)

  • With pooling: Subsequent requests reuse existing connections, eliminating connection overhead

This is especially beneficial for:

  • High-frequency feature retrieval in real-time inference pipelines

  • Batch processing with many sequential get_online_features() calls

  • Services with authentication enabled (reduces token refresh overhead)

Session Cleanup

The HTTP session is automatically managed with idle timeout, but you can also explicitly close it when your application is shutting down or when you want to release resources.

The recommended way to ensure proper cleanup is to use the FeatureStore as a context manager:

Explicit cleanup

You can also explicitly close the session by calling close() on the FeatureStore:

Direct session management

For advanced use cases, you can directly manage the HTTP session via HttpSessionManager:

How to configure Authentication and Authorization

Please refer the page for more details on how to configure authentication and authorization.

Last updated

Was this helpful?