skavish:Unfortunately it will not solve this problem if the link to the image preview still leads to the origin server (server the link points to) because requesting this image is loading the server, not requesting the link itself
Senza categoria
3
Post
3
Autori
0
Visualizzazioni
-
skavish:
Unfortunately it will not solve this problem if the link to the image preview still leads to the origin server (server the link points to) because requesting this image is loading the server, not requesting the link itself.
Sure it will somewhat reduce the load, but not enough to deal with the problem.
the link target and its image preview don't have to be on the same server.
as for the load itself, the image probably requires more bandwidth but otherwise a request is a request. the thundering herd problem isn't caused by images vs text, it's caused by up to 30,000 requests being made within the same 60-second window, and mostly concurrent at the beginning of that window (because not every software adds a random delay). as an example, the default nginx configuration uses 1 worker process that allows 512 worker connections per process. common advice is to use 1 process per CPU core, and maybe raise the connection limit to 1024 per process. so for a typical low-spec web server or VPS, you're looking at maybe 500 - 4000 connections before nginx starts dropping them. not a problem for static assets, because even for relatively large image previews, not much work has to be done, and requests can be fulfilled quite quickly. it's more of a problem for resources that have to be dynamically generated, because that's work that the server has to repeat for each request. a cache can greatly reduce this workload for the server.
skavish:we need to use some semi-centralized server which caches the link meta info and the image. This server may be implemented using custom fasp protocol, in fact we are running such server internally now and plan to open it soon.
the "semi-centralized server" can be the origin server. you don't strictly need an intermediary, but if you trust an intermediary, it can reduce load on the origin server by effectively using the intermediary as a proxy.
also, instead of using a custom protocol, you can use a standard one.
thisismissem:I would expect the preview image to be the URL of the one cached by the Mastodon server, not the original image URL. That’s also how AT Proto / Bluesky handles the link preview images — they’re stored as blobs in your PDS and distributed via Bluesky’s CDN.
the publisher of the AS2 resource gets to decide, so yes they can do this if they wish.
-
skavish:
Unfortunately it will not solve this problem if the link to the image preview still leads to the origin server (server the link points to) because requesting this image is loading the server, not requesting the link itself.
Sure it will somewhat reduce the load, but not enough to deal with the problem.
the link target and its image preview don't have to be on the same server.
as for the load itself, the image probably requires more bandwidth but otherwise a request is a request. the thundering herd problem isn't caused by images vs text, it's caused by up to 30,000 requests being made within the same 60-second window, and mostly concurrent at the beginning of that window (because not every software adds a random delay). as an example, the default nginx configuration uses 1 worker process that allows 512 worker connections per process. common advice is to use 1 process per CPU core, and maybe raise the connection limit to 1024 per process. so for a typical low-spec web server or VPS, you're looking at maybe 500 - 4000 connections before nginx starts dropping them. not a problem for static assets, because even for relatively large image previews, not much work has to be done, and requests can be fulfilled quite quickly. it's more of a problem for resources that have to be dynamically generated, because that's work that the server has to repeat for each request. a cache can greatly reduce this workload for the server.
skavish:we need to use some semi-centralized server which caches the link meta info and the image. This server may be implemented using custom fasp protocol, in fact we are running such server internally now and plan to open it soon.
the "semi-centralized server" can be the origin server. you don't strictly need an intermediary, but if you trust an intermediary, it can reduce load on the origin server by effectively using the intermediary as a proxy.
also, instead of using a custom protocol, you can use a standard one.
thisismissem:I would expect the preview image to be the URL of the one cached by the Mastodon server, not the original image URL. That’s also how AT Proto / Bluesky handles the link preview images — they’re stored as blobs in your PDS and distributed via Bluesky’s CDN.
the publisher of the AS2 resource gets to decide, so yes they can do this if they wish.
I think the best option is to include an
Objectderived type, likePageorArticle, at the top level.Linkhas limited metadata. I don't think attachment -> Link -> preview -> Article is the shortest path to getting metadata shared to the client. -
I think the best option is to include an
Objectderived type, likePageorArticle, at the top level.Linkhas limited metadata. I don't think attachment -> Link -> preview -> Article is the shortest path to getting metadata shared to the client.evan@cosocial.ca if we're putting
PageorArticleat the top level (ofattachment, I think you mean?), that would suggest that every link preview be given an id and managed by the publisher. That suggests some level of responsibility over the link, and all I really want to do is just fire off a hyperlink.So in the vast majority of cases,
{ attachment: [{ href: "..." }] }will do just fine, no?
Gli ultimi otto messaggi ricevuti dalla Federazione
-
@DarioZanette cosa dicono su facebug? Ormai sono quasi 3 anni che l'ho abbandonato :D
-
@snow
Erano 200 e passa, gli unici 145 sono quelli ancora vivi per fortuna 🤣 a parte poche eccezioni che potrebbero forse tornare in futuro, ma la vedo difficile
-
@jones potete fare di meglio miei cari piccoli tamagochi
-
-
@DarioZanette
io l'unico elettrodomestico che ho e che si potrebbe collegare a internet è la lavatrice MIELE, ma ovviamente non mi fido e rimane una lavatrice ignorante che fa solamente il suo lavoro
@ildisinformatico
-
@DigiDavidex @ildisinformatico oppure continuo a comprare elettrodomestici che NON si collegano a internet. Battlestar Galactica docet.
-
ora cerco "controindicazioni eccesso curcuma" online 😂
-
@guiscardo va meglio? due stelline e due boost eh, mica pannocchie! :)
