Van pár weboldal a szerveren ami WP-t használ. Ezeket rendszerint én tartom karban. Frissítéskor mindegyik elszáll mert nem elég neki 20 Mb memória. Megnéztem mit lehet javítani az ügyön.
A kódot megvizsgálva azt tapasztaltam, hogy a teljes zipet egyszer, és a teljes ziptartalmat még egyszer beolvassa memóriába. Namármost ez nem túl memóriabarát megoldás így kicsit átírtam (trac ide vonatkozó javítása, nevetséges).
A fő ághoz készült javítást megpróbálom majd keresztülnyomni a rendszeren, hátha elfogadják.
web
kézzel gzippelt tartalom
A mod_gzip és a hasonló on-the-fly tartalomtömörítéssel az a gondom, hogy a processzort eszi (ha nem is nagyon de azért jobban mintha nem tenné). Statikus tartalom esetén is jó ha sávszélességet spórolunk. Ez a megoldás pont ezt a tartalomtípust veszi célba. Ha létezik tömörítve az eredeti helyett azt szolgálja ki, így spórolva a processzoridővel és a sávszélességgel. A megoldás bővíthető a végtelenségig bármilyen fájltípusra.
AddType image/jpg jpg jpgz
AddEncoding gzip jpgz
RewriteEngine on
RewriteCond %{HTTP:Accept-encoding} gzip
RewriteCond %{REQUEST_URI} ^(.*).jpg$
RewriteCond %{DOCUMENT_ROOT}%{SCRIPT_FILENAME}.jpgz -f
RewriteRule ^(.*)$ $1.jpgz [L]
mj: ModRewrite debuggolás.
RewriteLog “logpath.log”
RewriteLogLevel 9
rossz rss
Adott egy galéria és hozzá egy RSS csatorna. Mi lenne a logikus ilyenkor? Az RSS-ben utazik a frissen feltett kép bélyegképe is. E helyett csak egy mondatot közölnek a képről. Van is rss meg nincs is.
abaqoos
http://webisztan.blog.hu/2008/10/15/mar_weben_is_mukodik_a_magyar_paypal
Szép, szép, csak:
A biztonságos kapcsolat sikertelen
A www.abaqoos.hu érvénytelen biztonsági tanúsítványt használ.
A tanúsítvány csak a következőre érvényes: *.abaqoos.com.
(Hibakód: ssl_error_bad_cert_domain)
Ezek után azért vakarja a jó magyar a fejét, főleg online fizetés esetén…
szóelválasztás weben
Az ingatlanguru kapcsán kezdtem el gondolkodni azon, hogy hogyan lehetne automatikusan (kiszolgáló vagy kliens oldalon) szóelválasztást végezni. Erre azért van szükség mert ha sorkizárt szöveget akarunk megjeleníteni a weben akkor sajnos nem ússzuk meg a szóelválasztást. Viszont azt nem lehet kiszámolni hogy hova kell tenni az elválasztó jelet, a böngésző hol törné a szót. Erre megoldás a ­ tilde.
Ha az összes lehetséges elválasztási helyre ­ karaktert teszünk és ezt megjelenítjük a böngészőben sorkizárt módban, a böngésző automatikusan elválasztja a szöveget ha a szótaghatár ér a bekezdés szélére. Régóta létezik a libhnj és a Tipográl oldalról letölthető elválasztásiminta-gyűjtemény, de php alól ezeket nem lehet használni, nincs libhnj kiterjesztés php-hoz (pythonhoz találtam egyedül). A fentiek tükrében nincs más feladat mint írni egy kiterjesztést ami a libhnj bindingje. Írtam c-ben és php-ban egy kezdetleges próba programot ami egy adott szöveget feldolgoz és szavanként elvégzi az elválasztást. Így néz ki a kimenet:
http://workshop.connor.hu/tmp/hyphen_example.html
A php program miatt még nem tökéletes, de nem is az volt a cél, mint inkább a lib használatának megismerése ahhoz, hogy kiterjesztést tudjak írni php-hoz.
hi5 és blacklist
Elkezdtem feltenni a feketelistára a hi5-ot. Megelégeltem.
korom
<trend> Mindenki a google brózeréről ír, így nem akarunk lemaradni írok én is. Nincs linuxra. Majd lesz. </trend>
újfajta spam
Van egy sanda gyanúm, hogy egy újfajta spam van kialakulóban. Most kaptam egy levelet a gmail-es címemre, miszerint épp most regisztráltam egy új weboldalra (külföldi). Valós felhasználónév, véletlenszerű jelszó. Első gondolatom az volt hogy valaki regisztrált a nevemben, de aztán rájöttem, hogy ennek így semmi értelme nem lenne, hiszen, véletlenszerűen generált jelszó esetén nincs értelme ilyesminek. Marad az a megoldás, hogy a spamlistát arra használja az oldal tulaja, hogy valós hozzáféréseket biztosít. Így egyszer legalább meg fogja látogatni az áldozat a weboldalt hiszen a valótlan regisztrációt törölni kell, nehogy visszaéljenek azzal.
Ötletes. De ettől függetlenül szarjon sünt az ilyen.
Ja, és a regisztrációt nem lehet törölni.
86
Szeretnék féltéglát köszörülni annak a fején akinek a jóvoltából mai napon ezidáig 86 db backscatter-t kaptam.
Ennek eredményeképpen hamarosan kész a visszapattanó levelek spamszűrője.
hogyan rontsuk el ami működik?
Egy barátom útján ismertem meg a fotosokvilaga.hu oldalt ami annó egészen jó kis oldal volt. Aztán az oldalt lelkesedésből fenntartó tulaj hosszú idő után úgy gondolta, hogy az a rendszer amit használnak nem jó, újat kell csinálni.
Hosszas csönd és fejlesztés után készült el az ami most látható. Sajnos itt romlott el az egész.
Az addig rendben van hogy mindenki mindent lelkesedésből csinál de azért van egy bizonyos szint ami alá azért nem kéne adni. Gondolok itt a nyilvános php hibaüzenetekre, a kezdetben jól beállított mysql-re (max 3 db egyidejű kapcsolattal egy igen forgalmas oldalnál gyak. felér a halállal), kategóriánként a képek nevében az egyediség biztosításának hiányára, használat közben jelentkező tömérdek mysql hibára, szétesős menüre (teljesen szükségtelen lenne, mert csak egy fehér doboz) stb stb stb… A másik amit nem értek, hogy az oldalak migrációjakor miért kell kihagyni azt a lépést hogy az adatok migrálása az egyik rendszerből a másikba? Mindenki azt szajkózza, hogy “azt nem lehet”… Ezt sem fogom soha megérteni. (A hup.hu migrációjakor is a régi posztok szálkövetésének migrálása se lett volna 50 sor kódnál nagyobb.)
Ezek után el lehet képzeni, hogy mennyi volt a teljesítmény teszt (webstress), alkalmazás teszt és mennyire moduláris a kód.
Elszomorító. De tényleg.