Trimmelés

Az elmúlt hetekben a szerver stabilitásával küzdöttünk. Ahogy korábban írtuk, a kritikus, erőforrás-igényes és nyilvánosan elérhető feladatok hosszú ideje az idővonalak generálása (és így a bonyolult keresési lekérdezések) valamint a nagy fájlok feldolgozását vagy generálását érintő feladatok voltak; nevezetesen az IIIF API és a PDF-generálás.

A legutóbbi bejegyzésben részleteztem, hogyan korlátoztuk jelentősen a nyilvános PDF-generálási funkciók elérhetőségét a museum-digital rendszerben a rendelkezésre álló erőforrások szerint. Ez azonban, mint kiderült, nem volt elegendő a rendszereink megbízható stabilitásának biztosításához. Miután a szerver ismét leállt december 26-án, az IIIF Image API-t ugyanabba a PHP-környezetbe helyeztük, amit a PDF-generálás is használ – ez azt jelenti, hogy bármely felhasználó/IP csak 10 lekérést hajthat végre percenként, és bármely museum-digital példánynál csak egy PHP worker szolgálja ki azt. Ez lehetővé tette, hogy a frontend többi részén a maximálisan elérhető erőforrásokat jelentősen csökkentsük. (Két eseten kívül, ahol az IIIF Image API akár 80 MB RAM-ot is használhat és a frontend más része nem haladja meg az 5 MB-ot). Azóta a rendszer úgy fut, mintha az AI scrapelés soha nem lett volna probléma.

Korlátozott búcsú az IIIF-től és a szerveroldali képmanipulációtól

Mit jelent ez a gyakorlatban? Egyrészt nem távolítottuk el teljesen az IIIF kép API-t. Minden általa generált link érvényes marad és továbbra is kiszolgálásra kerül, még ha viszonylag lassan is.

Másrészt a felhasználói élmény az IIIF-nézőben való képböngészéskor jelentősen romlik, bár ez nagymértékben függ az adott IIIF-nézőtől. A legnépszerűbb „teljes” IIIF-nézők a Mirador és a Universal Viewer. Jelentős problémák (vagy a tárgy képeinek teljes használhatatlansága) várhatók a Mirador esetében. A Mirador alapbeállításban a képet több szegmensre bontva tölti be, majd ezekből állítja össze a megjelenített képet. A szegmensek létrehozása a szerveren történik, így erőforrást igényel központilag. Emellett rendkívül alacsony határidőket szab a válaszidőkre, amit a museum-digital IIIF Image API-ja most rendszeresen túllép az agresszív lekéréskorlátozás miatt. Ha csak az Universal Viewer demó telepítését nézzük, a szoftver sokkal célzottabban hívja az API-t, és a korlátozások ellenére még jól működhet.

Amennyire tudom, nincsenek publikált adatok az egyes IIIF-nézők piaci részesedéséről, illetve arról, hogy a API-tól független IIIF-nézőket valójában mennyire használják rendszeresen. A legszkeptikusabb – és valószínűleg helytálló – feltételezés az lenne, hogy azoknak a felhasználóknak az aránya, akik IIIF-et használnak API-mellett nem hosztolt nézővel, elhanyagolható, és a legtöbben a fent említett nézők egyikét használják. Tapasztalatunk ismét alátámasztja ezt: 2020-ban adtuk ki az IIIF 2 implementációnkat, de lényegében senki sem vette észre, amíg nem kezdtünk IIIF-nézőt is hosztolni.

Mivel a Miradort használjuk nézőként, feltételezhetjük, hogy a museum-digital „látható” IIIF kép API-ja többé-kevésbé nem működik megfelelően. Azok a fejlesztők, akik közvetlenül használják az API-t Mirador telepítése nélkül, még mindig profitálhatnak az API-ból. De ezek viszonylag kevesen vannak.

Az IIIF Image API számára biztosított erőforrások radikális korlátozása így valószínűleg egy búcsút jelent az IIIF-től, korlátozott formában. Az alapötlet nagyszerű: egységes módon hivatkozni egy kép részeire (vagy később egy szélesebb médiafájlra) és annotálni azt. A megnövekedett botaktivitás, a csökkenő források és a várhatóan növekvő hosztingköltségek idején a mi példánk korai jelzés lehet arra, hogy az API-t a szolgáltatók által implementált módon meghatározó döntés korlátozza az IIIF teljes támogatásának lehetőségét a jól felszerelt intézményekre. És ahogy a források csökkennek, egyre kevesebb intézményre jut. Reméljük, hogy az IIIF által kívánt alapvető cél más módon is elérhető lesz a jövőben; oly módon, ami bárki számára hozzáférhető. Reálisan ez azt jelenti, hogy a számításnak a kliensgépeken kell történnie, nem a szerveren.

Hogy a történet pozitívan záruljon: mióta korlátoztuk az IIIF Image API-t, rendszereink újra kiválóan futnak, és lehetővé vált a museum-digital portáljainak további lekéréskorlátozásainak csökkentése. Figyelni fogjuk a helyzetet, és fokozatosan növeljük a limiteket, hogy több egyidejű API-lekérés engedélyezett legyen anélkül, hogy a stabilitást veszélyeztetnénk.

Kommunikáció

Másodsorban az egész ügy kihívást jelentett a kommunikációs csatornáink számára. Ha bárhol jelentős hiba történik a museum-digital rendszerben, én személyesen titkosított hibaüzenetet kapok e-mailben. Általában. Ebben az esetben a fő komponens, ami leállt, a PHP-szerver volt, amely a levelek küldéséért is felelős. Ha egy szolgáltatás leállt, az elsődleges módja a hibáról való értesülésnek az volt, hogy erről kaptunk e-maileket. Így a reakcióidők rosszabbak voltak, mint kellett volna. Ez azt jelenti, hogy javítanunk kell a monitorozást.

Másrészt az is problémát jelentett, hogy elmagyarázzuk, mi történik. Volt egy fórumtémánk a fórumon, amit kevesen olvastak. Voltak a blogbejegyzések, amelyeket szintén kevesen olvastak. Hiányzik (vagy hiányzott) egy egységes információforrás a jelenlegi eseményekről, amit feltételezhetően mindenki olvasna. A blog pontosan ezt a célt szolgálhatná és kellene, hogy szolgálja.

A musdb bejelentkező képernyőjének jobb felső sarkában évek óta a régió legutóbbi két blogbejegyzését, valamint a blog „fejlesztés” kategóriájának legfrissebb bejegyzéseit mutatjuk. Ezután alapértelmezetté tettük a „maradjak bejelentkezve” funkciót, ami azt jelenti, hogy az emberek már nagyon ritkán látják a bejelentkező oldalt.

A legtöbb felhasználó első oldala bejelentkezéskor vagy musdb megnyitásakor a „főoldal”, amelynek alapértelmezett aloldala korábban összefoglalót nyújtott a felhasználó által elérhető adatbázis-tartalomról, egy csempét a személyes jegyzetekhez, egy csempét a régió adminisztrátorainak üzeneteivel, egy csempét a Discourse fórum integrációjához, valamint linkeket a múzeum webes megjelenéséhez.

Az adatbázis-tartalom összefoglalója és a múzeum linkjei mindenképp hasznosak. A többi funkció kevésbé. Az aktuális használat ellenőrzése azt mutatta, hogy szinte senki nem használta a jegyzetfunkciókat (valószínűleg azért is, mert a musdb máshol jobb alternatívát kínál), míg a Discourse integráció évek óta nem volt használatban. Így a musdb elsődleges funkciói nagyrészt kihasználatlanok maradtak, miközben helyet foglaltak, amely a releváns blogbejegyzésekhez tartozó feed számára hasznosítható lett volna.

Ezért eltávolítottuk a használaton kívüli funkciókat, és helyettük egy esztétikailag tetszetősebb feedet helyeztünk el. Ez a feed most tartalmazza a felhasználó nyelvén a fejlesztési feed két legújabb blogbejegyzését, a regionális vagy nemzeti feedet (szintén a felhasználó nyelvén), valamint – ami fontos – az angol nyelvű fejlesztési feedet. A legfrissebb fejlesztéssel kapcsolatos bejegyzések egyikét sem fordítottuk le más nyelvre, főként azért, mert az időt inkább a problémák enyhítésére vagy javítására fordítottuk, nem pedig újabb nyelven történő leírására. Ráadásul a legtöbb felhasználó elég angoltudással rendelkezik a bejegyzések megértéséhez. Azok számára pedig, akik nem: a közösségi hozzájárulások – beleértve a fordításokat is – mindig szívesen látottak.

Az eredeti szöveget Joshua Ramon Enslin publikálta, 2025. december 29-én.
Forrás: https://blog.museum-digital.org/2025/12/29/trimming/