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
Uncategorized
3
Posts
3
Posters
0
Views
-
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
-
Quizzino della domenica: a,b
@matematica - Non sbagliatevi con le operazioni aritmetiche..
-
@dubito_ergo_sum @sport ma soprattutto perché l'arabo che alle olimpiadi invernali è pressoché inesistente e non il cinese per esempio?
-
A Simple Desktop Pomodoro Timer
Pomodoro timers are a simple productivity tool. They help you work in dedicated chunks of time, usually 25 minutes in a sitting, before taking a short break and then beginning again. [Clovis Fritzen] built just such a timer of his own, and added a few bonus features to fill out its functionality.
The timer is based around the popular ESP32-S2 microcontroller, which has the benefit of onboard WiFi connectivity. This allows the project to query the Internet for things like time and date updates via NTP, as well as weather conditions, and the value of the Brazilian Real versus the American dollar. The microcontroller is paired with an SHT21 sensor for displaying temperature and humidity in the immediate environment, and an e-paper display for showing timer status and other relevant information. A button on top of the device allows cycling between 15, 30, 45, and 60 minute Pomodoro cycles, and there’s a buzzer to audibly call time. It’s all wrapped up in a cardboard housing that somehow pairs rather nicely with the e-paper display aesthetic.
If Pomodoro is your chosen method of productivity hacking, a project like this could suit you very well. We’ve featured a few similar builds before, too.
-
My favorite recent snarky slogan.
-
Venerdì sciopero internazionale dei porti. è la prima mobilitazione unitaria di portuali europei e mediterranei nella storia
@anarchia
“I portuali non lavorano per la guerra“. E’ con queste parole che i sindacati di Enedep di Grecia, Lab dei Paesi Baschi, Liman-Is di Turchia, ODT del Marocco e USB in Italia hanno
-
@MLE_online @brouhaha specifically, it is an ER32 collet wrench.
-
@j_l_meek yep! sidenotes 🙂
-
@swelljoe @MLE_online
Looks like a wrench to me.
