Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Ask] Go (Golang) Oso performance improvement advice #1647

Open
bxcodec opened this issue Nov 15, 2022 · 3 comments
Open

[Ask] Go (Golang) Oso performance improvement advice #1647

bxcodec opened this issue Nov 15, 2022 · 3 comments

Comments

@bxcodec
Copy link

bxcodec commented Nov 15, 2022

Context:

We're using go-oso v0.26.0 (github.com/osohq/go-oso)

We have a strict timeout which is 2s. If the request exceeded 2s, we would automatically return a timeout response.
After digging deeper through profiling, we found that the Oso Go library takes at least 2s for some requests every 1-hour interval.
image

Asks

  • Any advice on how we can improve this? Every 1 hour, our response time will increase up to 2-5s, when it's normally on P95 around 30ms. Could it be the GC issue?
  • Any best practice that we can follow?
@samscott89
Copy link
Member

Hey @bxcodec.

We're looking into possible reasons why this is. GC definitely seems like a likely candidate.

In the meantime, would you mind trying with 0.26.3 and see if that helps at all? We fixed a potential issue where we were unnecessarily acquiring a write lock on a mutex in 0.26.2 (#1592). So there's a chance we're seeing a deadlock here.

@bxcodec
Copy link
Author

bxcodec commented Nov 16, 2022

Hi @samscott89

Thanks for replying, we will try to upgrade the version first, and see whether the issue still persists

@bxcodec
Copy link
Author

bxcodec commented Nov 21, 2022

For visibility, more conversation can be seen on the Oso community slack channel here https://oso-oss.slack.com/archives/C017KSBTD4M/p1668498111192659

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants