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

change session cache dimensions #15953

Closed
wants to merge 1 commit into from
Closed

Conversation

icing
Copy link
Contributor

@icing icing commented Jan 9, 2025

Now that we can (experimentally) import/export sessions, let's adjust the session cache somewhat:

  • for non-share transfers, 3 peers with 2 tickets each should be enough
  • share session caches get reused, so we want something larger. 25 peers with 2 tickets each seems better than 8 we had before. That means 50 tickets max and in my tests, we import those in ~3ms on my machine. Obviously this is a made up number up for debate.

@bagder
Copy link
Member

bagder commented Jan 10, 2025

for non-share transfers, 3 peers with 2 tickets each should be enough

We should remember that the same easy handle can be reused for new transfers over and over that may iterate over many hosts so we shouldn't restrict it too much.

One thing that struck me: how is the situation for the multi handle? Doesn't it share a session cache for all handles by default?

@icing
Copy link
Contributor Author

icing commented Jan 10, 2025

for non-share transfers, 3 peers with 2 tickets each should be enough

We should remember that the same easy handle can be reused for new transfers over and over that may iterate over many hosts so we shouldn't restrict it too much.

Which means older session tickets will be replaced. I can live with that. We had 5 entries before.

One thing that struck me: how is the situation for the multi handle? Doesn't it share a session cache for all handles by default?

No, it does not.

@bagder
Copy link
Member

bagder commented Jan 10, 2025

No, it does not.

Clearly room for improvement. I can't think of any notable drawback in having it used that way. Can you?

@icing
Copy link
Contributor Author

icing commented Jan 10, 2025

No, it does not.

Clearly room for improvement. I can't think of any notable drawback in having it used that way. Can you?

I think it would be a good change, yes.

@bagder bagder closed this in 34cebd8 Jan 10, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants