museum-digital:blog - Infrastructure

Rendrakás - teljesítmény, stabilitás, kompromisszumok

2026-01-12T00:00:00+00:00

A legutóbbi bejegyzés (azaz a PHP 8.5-re frissítés az AI-scraperek rohamának közepette)¹ és az ezt követően bevezetett, IP-címenként sokkal szigorúbb forgalomkorlátozás óta az MD körüli stabilitási problémák javultak – de még nem oldódtak meg teljesen.

Ennek megfelelően kibővítettük az erőforrás-igényes kulcsfunkciók újragondolására irányuló erőfeszítéseinket a nagyobb stabilitás érdekében. A korábbi gyakorlattól eltérően most már olyan funkciókat is teljesen eltávolítunk vagy letiltunk, amelyek a jelenlegi körülmények között egyszerűen nem tarthatók fenn.

PDF-generálás

Eddig alapvetően kétféle PDF készült (szerveroldalon) a museum-digital portáljain: egyrészt a tárgyoldalak PDF-reprezentációi („adatlap”), másrészt olyan PDF-ek, amelyek egy tárgy összes képét egyetlen dokumentumba foglalták az egyszerű nyomtatás érdekében.

Ez utóbbi – már a feladat jellegéből adódóan is – rendkívül erőforrás-igényes volt. Az összes képfájlt be kellett tölteni, beágyazni a PDF-be, tömöríteni, majd elérhetővé tenni. Emiatt ez az opció egyre kevesebb tárgynál volt elérhető. Míg eredetileg minden háromnál több képpel rendelkező tárgynál használható volt, később már csak a 40 képnél kevesebbel rendelkező tárgyakra korlátoztuk. Így az elérhetőségét egyre nehezebb volt egyértelműen kommunikálni, miközben a hasznossága csökkent az összes kép letöltését lehetővé tevő új funkció bevezetésével. Az alapvető erőforrás-igényesség azonban megmaradt, és mivel a scraperek minden elérhető linkre rákattintanak, ez a PDF-generálási forma továbbra is meglehetősen gyakran futott (a legutóbbi botaktivitás-növekedés előtt néhány másodpercenként). A funkciót a múlt héten teljes egészében eltávolítottuk.

Az „adatlap” PDF-ek generálását szintén tovább korlátoztuk. Ahogy az előző blogbejegyzésben is írtuk, a hasznosságuk jelentősen csökkent a nyomtatási stíluslap bevezetésével (jobb eredményt érhetünk el, ha egyszerűen a CTRL + P billentyűkombinációval nyomtatjuk PDF-be a tárgyoldalt). Ennek ellenére továbbra is népszerűek maradtak, ezért nem szüntettük meg őket teljesen. A szerver stabilitásának védelme érdekében azonban további korlátozásokat vezettünk be: ha a szerverterhelés a kényelmes szint fölé emelkedik, a PDF nem készül el, és hibaüzenet jelenik meg. Ha a terhelés magas (a kényelmes szint kb. 70%-a felett), és a felhasználó böngészőjének nyelve nem az adott museum-digital példány alapértelmezett nyelve, ugyanez a hibaüzenet jelenik meg.

Sikertelen keresési oldalak

Ha egy tárgykeresés nem ad találatot, a felhasználó egy sikertelen keresési oldalra kerül, ahol alternatív keresési javaslatokat kínálunk. Ez lényegében ugyanaz az elv, mint amikor a Google automatikusan javításokat javasol elgépelések esetén. Az alternatívák azonosítása és az előnézetek felkínálása azonban nem „ingyenes”: erőforrásokat igényel, miközben a javaslatok hasznossága és pontossága esetről esetre változik.

A naplófájlokat vizsgálva nagyszámú lekérdezést láttunk nem létező entitásokra – nyilvánvalóan olyan scraperektől, amelyek az URL-sémát elemezve különböző azonosítókat próbálgattak. Minden egyes ilyen lekérdezés lefutott, majd a sikertelen keresési oldalra irányított, ami újabb javaslatok és előnézetek betöltését váltotta ki, így kevés haszon mellett további szervererőforrásokat használt (azon túl, hogy még több letapogatható linket kínált). Most a PDF-adatlapoknál alkalmazotthoz hasonló logikát vezettünk be: a javaslatok és előnézetek csak akkor generálódnak, ha a szerverterhelés viszonylag alacsony, és ebben az esetben is az elsődleges nyelvet használó felhasználók enyhe előnyt élveznek.

Idővonalak

Az idővonalak továbbra is népszerűek, de egyben problémásak is. A naplókban gyakran láttunk olyan lekérdezéseket, amelyek az idővonalakat kezdő- és záródátum szerinti kereséssel kombinálták. Ez valószínűleg egy újabb, végtelen URL-generálási ciklus lehetőségét jelentette a scraperek számára: megadni egy idővonalat, ami továbbirányít egy adott időszakra szűrt keresési oldalra, majd megnyitni az adott időszak idővonalát. Ezt a viselkedést most lehetetlenné tettük. Ha egy keresésnél idővonal-alapú szűrés („után”, „előtt”) van beállítva, az idővonalak többé nem jelennek meg az oldalsávban. Ha valaki URL-manipulációval vagy az API-n keresztül mégis megpróbálja őket előállítani, hibaoldalt kap.

Keresés: rendbetétel, képkeresés és entitások ellenőrzése

Egy összetettebb optimalizálás érintette a tárgykeresés magját is. Körülbelül 2021-ben vezettük be az új keresési logikát. Szinte minden, a központi keresési logikára épülő oldal – keresési eredményeket összefoglaló oldalak, térképek, idővonalak – átállt erre. Egyetlen kivétel volt: a képkeresés. Mivel azonban az új keresési logika újrahasznált bizonyos funkciókat a régi keresésből, mindkettőt külön osztályként tartottuk meg, amelyek idővel egyre nőttek. Már önmagában az új keresési logika betöltése is körülbelül 1 ms-ot vett igénybe (OPCache nélkül, PHPBench-csel mérve). Ez elsőre kevésnek tűnhet, de a kód modularizáltságának hiányára utal, és jelentőséggel bír sok kiszámíthatatlan kérés esetén.

Valóban, az új keresési logika írásakor nem választottuk szét kellőképpen a HTML-generálást, a lekérdezés-összeállítást és az adatbázis-lekérdezést. A múlt heti frissítésekkel ezekhez most külön osztályok tartoznak, és a kizárólag a régi keresési funkciókhoz kapcsolódó elemek átkerültek a képkeresési logikát kezelő osztályba. Ez az új / fő keresési logika indulási idejét körülbelül a felére csökkentette (kb. 0,6 ms).

Másodszor, csökkentettük a képkeresésnél elérhető keresési opciók számát. A megmaradó paraméterek vagy valóban a képekhez kapcsolódnak, vagy a kontrollált szótárakhoz kötődnek. Pozitív mellékhatásként ez kommunikációs problémákat is megold: eddig nehezen volt érthető a különbség aközött, hogy a képeket a saját licencük, vagy az általuk ábrázolt tárgyak (nem feltétlenül kapcsolódó) metaadatainak licence alapján keressük.

Végül, ahogy fentebb is említettük, a naplók sok olyan lekérdezést mutattak, amelyek például teljesen nem létező helyekhez, vagy olyan helyekhez kapcsolódtak, amelyek egyetlen tárgyhoz sem kötődnek. Ezért amikor egy helyre vagy kulcsszóra keresnek, már a lekérdezés összeállításakor ellenőrizzük, hogy az adott bevitelnek van-e bármilyen nyilvános előfordulása az adott példányban. Ha egyáltalán nincs kapcsolat, akkor egyértelmű, hogy a bevitel más paraméterekkel kombináló, részletesebb lekérdezés sem fog eredményt adni.

A jelenlegi helyzet

Mindezek a fejlesztések segítenek, de érdemes ránézni a jelenlegi valós adatokra is. Egyrészt az adatbázis-szerver terhelése most gyakran a várható érték felére vagy akár az alá is csökken. Ez pozitív jel a rendszer stabilitása szempontjából a csúcsidőn kívül.

Másrészt jól látható terhelési csúcsok jelentkeznek reggel (Németországban kb. 10:20 körül) és délután (kb. 17 óra körül kezdődően). A reggeli csúcs valószínűleg a munkanap kezdetéhez kapcsolódik, és a múlt héten többször is a szerver leállásához vezetett. Ezt feltehetően csak a PHP-FPM beállításainak további finomhangolásával lehet orvosolni. A délutáni és kora esti csúcsok okai nehezebben magyarázhatók, de összességében sokkal kevésbé kritikusak.

Dolgozunk rajta.

A scraper (magyarul gyakran: adatgyűjtő robot, webes letapogató) egy olyan automatikus program vagy bot, amely weboldalakat látogat végig, és adatokat gyűjt ki róluk.

info

AI Use

(Post image generated using Z-Image)

info

License

This content is licensed under a Creative Commons Attribution 4.0 International license.

A scraper (magyarul gyakran: adatgyűjtő robot, webes letapogató) egy olyan automatikus program vagy bot, amely weboldalakat látogat végig, és adatokat gyűjt ki róluk.

Trimmelés

2026-01-12T00:00:00+00:00

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.

A musdb főoldal most tartalmaz egy feedet, amely a museum-digital fejlesztésével kapcsolatos és a régióban történő eseményekről szóló legfrissebb híreket mutatja. A bejegyzések kronologikus sorrendben jelennek meg.

info

AI Use

(Post image generated using Z-Image)

info

License

Ez a tartalom a Creative Commons Attribution 4.0 Nemzetközi licenc alatt érhető el.