Drupal 4.7 portolása Rustra AI segítséggel: 100ms -> 30ms (Hétvégi projekt)

Az elmúlt hétvégéken tettem egy kísérletet: fogtam a Drupal 4.7 forráskódját (én ezt használtam legelőször, még installere sem volt), és megpróbáltam átültetni Rust alá, hogy lássam, mit lehet kihozni belőle teljesítmény terén. A kísérlethez a Claude Code-ot és a Gemini CLI-t hívtam segítségül (hétvégén nem kellett tartanom tőle, hogy elfogyasztja a céges feladatok elől a használati keretemet).

Az eredmények elég meggyőzőek lettek. Az uncached homepage válaszideje 100ms-ről 30ms-re csökkent (azonos hardveren, a Drupal 4.7 DDEV containerben futott, a korrektség kedvéért). Akit érdekel a kód, itt megtalálja a repót: https://github.com/aronnovak/drupal-rust

https://imgur.com/inu3san (ez egy mérést mutat, konzisztens volt több futás után is amúgy).

CPU: i5-1235U

Meglepően könnyen ment a dolog, a portolás nagy részét az AI viszonylag fájdalommentesen elvégezte. Ahogy várható volt, az AI alapból simán kihagyta a security részeket (XSS, CSRF védelem, stb.). Konkrétan kérnem kellett, hogy implementálja a form protectionöket és a sanitizationt. A válaszidő viszont jelentősen csökkent.

További performance engineering kísérletek és case study-k itt: https://www.gizra.hu/blog/

Ti használnátok AI-t performance-kritikus kód refaktorálására éles környezetben?

( deje | 2026. 02. 09., h – 09:23 )

Kb 15 éve próbáltam ki, hogy egy Java-s PHP interpreterrel futtatam Drupal-t, Tomcat-en. Pontos méréseket nem csináltam, de hangolás nélkül is kenterbe verte az Apache HTTPD + mod_php párost. A JVM memória-kezelése és JIT compilere sokkal jobb, mint a PHP-é... legalábbis ez volt 15 éve. PHP-n nagyon sokat dob, ha van code cache...

Server: nginx-fpm, PHP 5.6 - ezt írja a DDEV. Nem Apache + modphp volt. A DDEV alapból tartalmaz minden olyan beállítást, ami a legnagyobb performance bakik elkerüléséhez szükséges. a A Java-s interpreter ügyes, bár nem tudom, hogy van-e mostanában jól karbantartott efféle megoldás. Bár gondolom azóta annyit javult a PHP teljesítménye, hogy nem annyira releváns egy ilyen projekt.

Anno még az előző munkahelyemen sacc/kb. 12 éve egyszer felmerült bennünk, hogy mennyire lassú a PHP (5.5-5.6 környékéről beszélünk). Mérések alapján az jött ki, hogy az idő 90%-a DB-zés. Utána nem is nagyon foglalkoztunk vele, csak ha valami látványosan lassú volt és inkább a DB querykre fókuszáltunk. Többet ért.

Nem egyszer lattam hogy DB koruli ORM -en ment el az ido, es DB -re fogtak.
Egy ORM read intesive workloadnal >5x idot toltott ORM -ben mint a DB ben. 
>8x -rol indult, es az ORM is tartalmazott nemi native codot, de interpreter az interpreter ..

Az ORM-en tul volt meg egy par object layer, <sarcasm>hogy ne tunjon lassunak  az ORM </sarcasm>, a db nem volt rossz.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Na, a kérdéses helyen nem volt semmiféle ORM :) Egyébként az ORM-mel önmagában még nem lenne gond. (Sőt... egyszer mértem össze az EF Core-t a klasszikus ADO.NET-es DataReaderrel, simán 20-30%-ot rávert arra, amit össze tudtam hozni, nem mondom, hogy reprezentatív mérés) A probléma inkább az, amikor az ORM miatt feleslegesen sok adatot kell mozgatni oda-vissza vagy feleslegesen újraimplementálni, komplexen (és/vagy rosszul) olyan dolgokat, amiket a DB-k egyébként tudnak.

( trey | 2026. 02. 09., h – 14:52 )

4.7? 

11.x-nél tartunk. 20 éves a 4.7 LOL

trey @ gépház

Teljesen lényegtelen. 7 like van ugyanerre a Linkedinen angolul... Azért kellett a kis kódbázis, hogy az AI ügynök kezelhető méretű problémát kapjon. A Drupal 11 forráskód más liga. Ez hobbi-portolás, hobbi token-kereten belül.

Ha adok neki egy rendes büdzsét, ugyanezt megteszi a Drupal 12 kódjával. Ja igen, a Drupal core fejlesztők 12-nél tartanak.

( Fisher v | 2026. 02. 11., sze – 20:02 )

"Ti használnátok AI-t performance-kritikus kód refaktorálására éles környezetben?"

Hogyne. Bár ugye erősen limitál, hogy akármit nem adhatok neki, mert mittomén hogy mennyire IP meg egyáltalán.

Viszont a saját motyóimat újabban átnézetem vele, pl. egységesítés, coding style fixek miatt. Meg hogy mit tud rajta optimalizálni. Na, ez pl. odáig fajult, hogy kioptimalizálta a scriptből a szerviz indítását. Mindenképp tanulságos eljátszani vele.

( Raynes v | 2026. 02. 15., v – 13:17 )

Ezen semmi tapsikolni való nincs, nem az AI meg a Rust érdeme. Ez csak példázza a futási sebességkülönbséget egy interpretált és egy gépi kódra fordított nyelv között. Egyrészt ha 8-as vagy újabb PHP-vel próbálod (bár ezen a 4.7-es DrewPali lehet nem futott volna) és bekapcsolod a JIT-et, akkor az a 100ms lement volna jóval 50 alá, másrészt ha a Zalyí C-re portolt volna, akkor talán 10ms környékére is. Csodák nincsenek.

“Linux isn't an OS, it's a troubleshooting sim game.” (a YouTube commenter)

Folyamatban van egy új teszt, a JSON:API részleges re-implementációja Rustban. Kurrens PHP, kurrens Drupal, stb.

példázza a futási sebességkülönbséget egy interpretált és egy gépi kódra fordított nyelv között

Igen, pontosan ez történt. De annyival gyorsabb lett újraimplementálni a rendszer egy részét, hogy valós alternatíva szerintem. Régebben senkinek nem jutott eszébe egy webfejlesztő csapatban, hogy fordított nyelvvel csináljon valamit (ritka kivételtől eltekintve, nálunk is volt házon belül Haskelles projekt), mert nem volt meg hozzá a kompetencia és/vagy az anyagi háttér.