mirror of
https://github.com/sigma67/ytmusicapi.git
synced 2026-04-25 15:26:01 +03:00
[GH-ISSUE #159] Sessions and Persistent TCP connections #119
Labels
No labels
a/b
bug
documentation
enhancement
good first issue
help wanted
invalid
pull-request
question
wontfix
yt-error
yt-update
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/ytmusicapi#119
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @0xbrayo on GitHub (Jan 26, 2021).
Original GitHub issue: https://github.com/sigma67/ytmusicapi/issues/159
Hi, I'm using this module to fetch data about multiple songs at a go, I noticed that the script creates a new TCP connection for each request, which adds about 2 to 3 RTTs to each song requests, anyway, I would appreciate it if you would provide for the user the capability to pass a requests.session() to the YTMusicClient. Or find a way to keep a master session within the class for each new class. I would be down to help you with implementing it if it's a feature you will deem necessary
@sigma67 commented on GitHub (Jan 26, 2021):
Sounds like a good idea. We could initiate the session on instantiation and reuse it in _send_request. We can use the tests to measure before-after performance.
I'd prefer to make it the default behavior if performance results are good. Feel free to make some suggestions of your own or start implementing if you'd like.
Edit: We can probably take inspiration from spotipy: https://github.com/plamere/spotipy/blob/master/spotipy/client.py#L191
@0xbrayo commented on GitHub (Jan 26, 2021):
That's exactly where I got the idea from
@sigma67 commented on GitHub (Jan 27, 2021):
Preliminary results are looking good, shaves off about 0.3s or 6% off the best case total test time when running
test_search. Obviously many factors at play here, but it should be a great improvement for users with many calls per instance.@sigma67 commented on GitHub (Jan 29, 2021):
Do you think the current implementation is satisfactory to close this issue @brayo-pip ?
@0xbrayo commented on GitHub (Jan 29, 2021):
I was offline, sorry lemme review and ger back to you
@0xbrayo commented on GitHub (Jan 29, 2021):
I think it's perfect, I like that there's the option to either pass a Session or simply use an in-class Session