You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
PyPI load impact and CDN expenses of Pyodide #3127
Every new user, not page load since downloads would be cached. Though yes cache is not shared between domains, so still a lot.
Currently, the Pyodide downloads is at 0.5 TB/day provided by the JSDelivr CDN (which itself serves around 150 TB/day across all projects, date uncertain). Even if PyPI added support for WASM and we switched everything there, this would be neglible as compared to their bandwidth of 900 TB/day. as of 2021.
Though if there is much more adoption, this would become more of an issue as we become either non neglible in the JSDelivr CDN overall bandwidth, or that of PyPI.
In the end a lot of this is not about numbers themselves, since non of these projects pay for bandwidth, but about the willingness of CND providers (Fastly, Cloudflare and others) to foot the bill. I don't really know well the situation there.
BTW, tn the case of JSDelivr CDN, there is a bit less risk as they have agreements with multiple CDNs, not just one as in the case of PyPI.
But also for high-traffic websites, in the long term, we might want to advise users to use bundlers more (https://github.com/pyodide/pyodide-pack (very experimental) or some others to come), as downloading a full dependency tree from CDN it's really optimal for production applications.
2c from jupyterlite: we've found reproducible, offline-capable builds to be a fairly important use case. Being able to pull (and cache) well-versioned PyPI assets in development/CI from a lockfile helps ensure not only availability but the correctness of the end user application.
With the serverworker we've added, it goes a bit further, such that once using a site, it can go fully offline, powered only by the browser's cache. ServiceWorker requests still aren't free, and have pointy edges in some browsers.
While pyodide-pack (very cool) looks useful for a certain class of application, for interactive use cases like jupyterlite, where many pyodide runtimes will be open in separate workers, I think there's also a place for offline package resolution and lazy loading on install/import.
With #3093 (micropip as a separate repo), perhaps having pyodide-pack's functionality available from the CPython side would be feasible, coupled with some of the suggestions on that issue for additional APIs (e.g. add_pypi_json_resolver).
Yes, absolutely jupyterlite is a rather different use-case than the one for which pyodide-pack was written. Having offline mode in jupyterlite is also very cool!
I think there's also a place for offline package resolution and lazy loading on install/import.
I wonder what the distribution of that 900TB PyPI bandwidth looks like? If the majority of that bandwidth usage comes from a small number (e.g. < 100) of popular packages, then this may be relevant:
Basically it's a shared cache (instead of a separate cache per domain) that is only for payloads that are popular enough that it's less of an issue for privacy. It's unclear whether this will actually land in Chromium let alone other browsers, and how popular an asset needs to be to make it into the shared cache, and whether it'll trade off well enough against the (ideally very small) privacy hit, but if this feature (or some variation of it) does land, then it could be pretty significant in terms of the way we'd need to think about this issue.
Decentraleyes is a free and open-source browser extension used for local content delivery network (CDN) emulation. Its primary task is to block connections to major CDNs such as Cloudflare and Google (for privacy and anti-tracking purposes), and serve popular web libraries (such as JQuery and AngularJS) locally on the user's machine.[3] Decentraleyes is available for the Microsoft Edge, Mozilla Firefox + Firefox ESR, Google Chrome, Pale Moon and Opera web browsers.[4]
But that would require users to install an extension
"Subresource Integrity
Subresource Integrity (SRI) is a security feature that enables browsers to verify that resources they fetch (for example, from a CDN) are delivered without unexpected manipulation. It works by allowing you to provide a cryptographic hash that a fetched resource must match*
Are unsigned hashes of arbitrary code in a browser/WASM application sandboxed process all running as the same user sufficient? FWIW, Service Workers and Task Workers can communicate between browser tabs and there's Same Origin still kind of.
Activity
rth commentedon Sep 18, 2022
Every new user, not page load since downloads would be cached. Though yes cache is not shared between domains, so still a lot.
Currently, the Pyodide downloads is at 0.5 TB/day provided by the JSDelivr CDN (which itself serves around 150 TB/day across all projects, date uncertain). Even if PyPI added support for WASM and we switched everything there, this would be neglible as compared to their bandwidth of 900 TB/day. as of 2021.
Though if there is much more adoption, this would become more of an issue as we become either non neglible in the JSDelivr CDN overall bandwidth, or that of PyPI.
rth commentedon Sep 18, 2022
In the end a lot of this is not about numbers themselves, since non of these projects pay for bandwidth, but about the willingness of CND providers (Fastly, Cloudflare and others) to foot the bill. I don't really know well the situation there.
BTW, tn the case of JSDelivr CDN, there is a bit less risk as they have agreements with multiple CDNs, not just one as in the case of PyPI.
rth commentedon Sep 18, 2022
But also for high-traffic websites, in the long term, we might want to advise users to use bundlers more (https://github.com/pyodide/pyodide-pack (very experimental) or some others to come), as downloading a full dependency tree from CDN it's really optimal for production applications.
bollwyvl commentedon Sep 20, 2022
2c from jupyterlite: we've found reproducible, offline-capable builds to be a fairly important use case. Being able to pull (and cache) well-versioned PyPI assets in development/CI from a lockfile helps ensure not only availability but the correctness of the end user application.
With the serverworker we've added, it goes a bit further, such that once using a site, it can go fully offline, powered only by the browser's cache. ServiceWorker requests still aren't free, and have pointy edges in some browsers.
While
pyodide-pack(very cool) looks useful for a certain class of application, for interactive use cases like jupyterlite, where many pyodide runtimes will be open in separate workers, I think there's also a place for offline package resolution and lazy loading on install/import.With #3093 (
micropipas a separate repo), perhaps havingpyodide-pack's functionality available from the CPython side would be feasible, coupled with some of the suggestions on that issue for additional APIs (e.g.add_pypi_json_resolver).rth commentedon Sep 21, 2022
Yes, absolutely jupyterlite is a rather different use-case than the one for which
pyodide-packwas written. Having offline mode in jupyterlite is also very cool!Agreed.
rth commentedon Sep 21, 2022
I haven't fully completed the micropip migration yet but I will get to it :)
josephrocca commentedon Jan 6, 2023
I wonder what the distribution of that 900TB PyPI bandwidth looks like? If the majority of that bandwidth usage comes from a small number (e.g. < 100) of popular packages, then this may be relevant:
https://groups.google.com/a/chromium.org/g/blink-dev/c/9xWJK3IgJb4/m/SYLfUccOBgAJ
Basically it's a shared cache (instead of a separate cache per domain) that is only for payloads that are popular enough that it's less of an issue for privacy. It's unclear whether this will actually land in Chromium let alone other browsers, and how popular an asset needs to be to make it into the shared cache, and whether it'll trade off well enough against the (ideally very small) privacy hit, but if this feature (or some variation of it) does land, then it could be pretty significant in terms of the way we'd need to think about this issue.
westurner commentedon Jan 6, 2023
https://en.wikipedia.org/wiki/Decentraleyes :
But that would require users to install an extension
westurner commentedon Jan 6, 2023
Are unsigned hashes of arbitrary code in a browser/WASM application sandboxed process all running as the same user sufficient? FWIW, Service Workers and Task Workers can communicate between browser tabs and there's Same Origin still kind of.
westurner commentedon Jan 6, 2023
See also: "Avoid too many requests to PyPI" jupyterlite/jupyterlite#225