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.