xml - 3 megfelelő bejegyzés

Mutass mindent

Jelöld be, hogy főbb mely kategóriákat akarod olvasni, vagy ha csak egyet: kattints a nevére.


mindet
jan
feb
már
ápr
máj
jún
júl
aug
sze
okt
nov
dec
2007
-
-
-
-
-
-
-
-
-
-
2006
-
-
-
-
-
-
-
-
-
-
-
Haszprus

Mission one completed (XML parser optimalizáció)

©   Haszprus   |   fejlesztés mátrix php xml

A cégnél az első feladatom egy olyan script optimalizálása volt, amely 12-től 30 vagy akár még több MB-ig terjedő XML állományok alapján hajt végre nagyságrendileg 100-500e egymással összefüggő SQL insertet (értsd: mély és széles xml-fa).

Az eredeti progi egy 30 megás XML-lel kb. 2 perc 40 másodpercnyi munkát adott az apache.exe-nek (ennyit foglalt a prociból tehát az apache), miközben a memóriahasználat az alapjáratú 27 MB-ról felment 558 MB-ra. A program teljes futási ideje 383 másodperc volt.

Elég sok időt eltöltöttem azzal, hogy egyrészt a program logikáját megértsem, másrészt utána nézzek, hogy vajon van-e valami hatékonyabb XML parser. Miután nem találtam a használt megoldásnál jobbat (tekintve hogy az se a teljes dokumentumfát tárolta a memóriában), már majdnem ott kötöttem ki, hogy ezt bizony nem lehet (vagy én nem tudom) optimalizálni (bár persze kételkedtem), ehelyett kicsit kitesztelgettem, hogy hogyan is működik a php-ben a változók és objektumok megsemmisítése (ld. __destruct), és a megfelelő stratégiai helyen mért csapás eredményeként a program most nem növeli az apache alapjáratú memóriafoglalását egy megával sem (Érdekes módon az unset nem segített.)

Azaz az én verzióm a 30 megás XML-lel ugyanúgy 2 perc 40 másodpercig tekeri az apache.exe-t, azonban összesen csak 358 másodpercig fut (fél perc nyeremény itt, miközben sebességre még nem is optimalizáltam), és ami a lényeg, hogy 27-ről nem 558 MB-ra nyomja fel az apache memóriahasználatát, hanem mindössze 29-re. Nem kell mondani, hogy ez mennyire előnyös egy olyan környezetben, ahol más dolgok is futnak (ti. ez egy webszerver).

Amikor nekiálltam a dolognak, egy nagyságrendi változást akartam volna elérni, aztán ahogy beleástam magam, megelégedtem volna akár egy memóriafelezéssel is, végül már majdnem teljesen feladtam, de arra álmomban sem gondoltam, hogy sikerül a memóriahasználatot úgy ahogy van megszűntetni Ettől igen jó kedvem lett

Rulz.

Haszprus

Topicfigyelő rss

©   Haszprus   |   fejlesztés rss xml

[Olvasói kérésre] csináltam egy olyan RSS feedet, amelyik értesít, ha válasz érkezik egy hozzászólásodra. Igazából ez csak egy topicfigyelő. Kicsit konkrétabban, azokat a hozzászólásokat szedi be a feedbe, amelyek olyan bejegyzésekhez érkeznek, amikhez hozzászóltál.

Elérése: blog.haszprus.hu/rss/kommentek/?follow=x, ahol x a user id-d, az én esetemben pl. 1. A user id-det megtalálod az adatlapodon, de ez a link már kapásból elő van készítve az oldal rss-listájában is, amennyiben be vagy jelentkezve. (Firefoxnál a címsáv jobb szélén rss ikonra klikk…)

Haszprus

XSLT + XPath + CSS + XML + XHTML alapú RSS feed

©   Haszprus   |   css fejlesztés rss xml

Na, validhuszárok, webdizájnerek, csorgassátok a nyálatokat, itt egy XSLT + XPath + CSS alapon megjelenített RSS feed.

Mi ebben az érdekes? Először is, teljesen tetszőleges tartalmat rakhatok a böngészőben megjelenő rss feed köré. Másodszor, a bejegyzések címei immáron linkként mutathatnak a komment.php-re. Ezt css alapú formázással nem lehet megvalósítani.

Igazából ha az RSS nem kényszerítene arra, hogy CDATA-ba tegyem a descriptiont, akkor még frankóbb lenne. Lehetséges egyébként hogy ezt a problémát valahogy át lehet hidalni, nem jártam körül a témát, őszintén szólva.

Szerintem szép lett.

Egy pusztán css-sel formázott RSS feed így nézne ki. For the record, a Haszprus überblog közel fél éve CSS-sel formázott RSS-sel nyomul(t eddig).

Végül, nem tudok itthon még egy megszállottról, aki RSS feedre XSLT sablont rakott volna. Igaz, nem is kerestem. És az itthon alatt most nem a lakást értem, lol.