GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — Calls to the get_online_features API are slower in v0.42.0 than in v0.40.1 · Issue #4887 · feast-dev/feast

Calls to the get_online_features API are slower in v0.42.0 than in v0.40.1 #4887

New issue
Copy link
New issue
Copy link
Closed
#4892
robhowley/feast
#10
robhowley/feast#10
Closed
Calls to the get_online_features API are slower in v0.42.0 than in v0.40.1#4887
#4892
robhowley/feast
#10
Copy link
Labels
kind/bugpriority/p2

Description

@j1wonpark
j1wonpark
opened on Jan 3, 2025
Issue body actions

Expected Behavior

The call to the get_online_features API must be faster or equal to v0.42.0 than v0.40.1.

Current Behavior

v0.42.0 is slower than v0.40.1

Steps to reproduce

Specifications

  • Version: v0.42.0, v0.41.*
  • Platform: Kubernetes + Redis (Online) + Bigquery (Offline) + PostgreSQL(SQLRegistry)
  • Subsystem:

Possible Solution

Need to change the default behavior to sync (based fastapi - anyio threadpool), or change the part where blocking (or delay) occurs in async to async.

I was running 0.40.1, and upgraded to 0.41.2 / 0.42.0, but I actually found that it got slower.

Looking at the structure of async def get_online_features
(1) Get the information of the requested feature_view.
(2) Check the permission (when using RBAC).
(3) Get the value from the online store using asynchronous.
(4) Deserialize the protocol buffer message from the online store into a dict.

It flows in this order, but only (3) is actually protected by the threadpool or eventloop.
However, (1), (2), and (4) also take a lot of time for protobuf serialization-deserialization, and as a result, (1), (2), and (4) lose time when performed with a single thread (async) compared to multi-threading.

Activity

  1. j1wonpark
    added
    kind/bug
    priority/p2
    on Jan 3, 2025
  2. j1wonpark commented on Jan 3, 2025

    @j1wonpark
    j1wonpark
    on Jan 3, 2025
    ContributorAuthor
    More actions
    Screenshot 2025-01-03 at 5 46 36 PM

    This is a graph of the latency changes (v0.42.0 -> v0.40.1) in my system.

  3. franciscojavierarceo
    closed this as completedin #4892on Jan 15, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    kind/bugpriority/p2

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions

      You are visitor 01402503 — GeezerVison does not store the pages you look up.
      Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.