sikerült egy kevéske hibát csinálnom:
sherlockd error[114]: (csonkolt szonak legalabb 3 karakteret meg kell adnia)
úgy néz ki, a cseh programozók gondoltak egy-két mindenre...
a forrást még átnézem egy kis hibakeresésért...
a torzsasztalban kereses immar nem boritja fel a hozzaszolasok megszokott sorrendetjet..
ugyhogy akinek eddig ezzel problemaja volt, ezentul hasznalhatja batran..
Ha tenyleg keresni akarok es nem csak bohockodni a csupa jofej Indexes vilagban, akkor azert Google.com. Ha az erdekel, hogy a userek 90%-a mennyire tudja megtalalni oldalaimat, akkor AltaVizsla.
Szegeny staff-nak el kene fogadnia, hogy sokkal dragabb cuccot kell ahhoz vasarolni, hogy ezen a fronton versenykepes legyen az Index.
Ja es kedves HC Indexelok, meg kene nezni az Index altal "mert" latogatottsagot az Origon es itt (viccesen ugy hivjak, hogy "Median Webaudit"). Az utobbi napokban meg jobban elhuzott az Origo. Lehet, hogy sokan a Findex gyengesege kapcsan jottek ra, hogy a kisse elavult AltaVizsla meg mindig milyen jo?
Hallom hamarossan ujra indul a Google.hu (ViaNovo-n)- gyorsabb, tobb info stb.
Kivancsi vagyok... Az elso feljleszto csapattal (valami EGIS vagy EGUS) nagyon rafaztak a fiuk...
Ez a fulltextsearch jó dolog, de így kezd egy kisse elavulni. Értem ezalatt, hogy a "'keresendo szoveg' magyar" beírása a google-be jobb oldalakat talált. Általában ezek megtalálhatók az index.index-szel is, nameg az A.V. -vel is, azonban a google sorrendje általában azt hozta ki, ami tényleg érdekes. Mondom mindezt úgy, hogy nagy altavista felhasználó vagyok (még az altavista.digital.com óta...) és soksoksoros advanced queryket szoktam volt oda beírni, mégis.. a google kényelmesebb.
A T. stáb azt írjahogy intelligens kereső... nekem inkább egy jó izmos keresőnek tünik, de olyannak, ahol az embernek még meg kell izzadnia, ha eredményt akar találni.
Mondok két konkrét (szélsőséges) példát:
"free sex picts" -re az első néhány találat minden, csak nem ingyenes; (vagyis spam jön ezerrel)
"linux download" -ra mindenféle linux alatti cuccok jönnek elő, olyan oldal, ahonnan az oprendszer tölthető, nem.
Szóval, jön az newbie, beírja, aztán nem azt kapja, amit akart.
Szóval, nem akarjátok inkább az egészet lecserélni valami egyedire? Az [origo] még mindig az altavista.digital.com farvizén fut, ezt egy névtelen keresővel nehéz lesz utolcammogni.
Csupan egy maganvelemeny, de szerintem a findex.hu az szornyu lenne. Egeresznek raadasul igaza van az asszociacioval kapcsolatban, nalam is ez jott be.
Index vs. Origo. Origot valoban jo lenne lenyomni mar szerintem is, egyszeruen jobb az Index. Origonal valoban egy rettenetesen nagy % az Altavizsla miatt megy oda, talan meg tobb is, mint amit irtal, Egeresz. Erdemes egymas melle tenni az Index es az Origo fooldalanak latogatottsagat, utana pedig a latogatonkenti oldalletolteseket. Van egy olyan gyanum, hogy az Origot ezzel a keresovel lehet es kell lenyomni. De zt mintha mar emlitette volna UP az InternetGalaxison a Kossuth teren anno, x honapja.
Ha csak magamba belegondolok. Origora kizarolag AV miatt jarok, az oldalletoltesek szama az Indexen csak a mai nap tobbszorose volt annak, mint az Origon letoltott oldalak szama az elmult 1-2 evben.
nem érted a lényeget :-) a lényeg az, hogy az [origo] auditált nézettségét igencsak megdobja a tetején található kereső -- úgy is mondhatjuk, hogy az [origo] nézettségének 36%-a igazábol a kereső hozza (további 30% a freemail), magára az [origo] hírekre, illetve az [origo] fórumra alig kiváncsi valaki. Viszont, mivelhogy mégiscsak ott van az altavizsla, így az [origo] auditált nézettsége meghaladja az index nézettségét, ami bosszantja az index T. stábját.
Innentől kezdve tökmindegy, hogy hogyan hívják a keresőt. (Egyébként a ,,findex'' aranyos, kár, hogy magyarban (az angolul nem tudóknál) a fi kezdetű lágy hanggal folytatódó szavakra asszociálhatnak.)
Magyarán az index keresője nem a demosznak szól, hanem azoknak a hírdetőknek, akik a webaudit statisztikából csak a számszerű összeget nézik.
Magánvélemény volt eddig, de még magánvéleményebbem, hogyha az indexnek sikerül felkúsznia az [origo] felé, akkor a matáv-féle csakazértse alapján olyan [origo] hírverés kezdődik, hogy ahoz képest az aug 20.-ai tüzijáték csendes, sötét, néptelen rendezvény.
érdemi teszt, performance (ha már a security területén tulvagyunk...) Az teszthez az apache-hoz mellekelt ab programot használtam, a tesztgép és az index.index.hu között legalább 10 mbites link volt:
10 darab párhuzamos kapcsolat (mert 300-at soknak tartottad, ok)
Concurrency Level: 10
Time taken for tests: 613.576 seconds
Complete requests: 3000
Failed requests: 1818
(Connect: 0, Length: 1818, Exceptions: 0)
Keep-Alive requests: 0
Total transferred: 148588447 bytes
HTML transferred: 147798921 bytes
Requests per second: 4.89
Transfer rate: 242.17 kb/s received
Connnection Times (ms)
min avg max
Connect: 2 24 313
Processing: 398 1549 4863
Total: 400 1573 5176
- a connect time jó (de ez el is várható 10 keepalive kapcsolatnál) a total time türhető.
A failed request szamot egy kicsit soknak tartom... aztszem az ab akkor számol olyat, ha nem 200-as kóddal tér vissza.
Másszóval, látom beleírtál egy ellenörzést, pedig (miután elmult éjjel a fejfájásom) még szivesen kiprobáltam volna egy sid= "query terminator, újsor, shellhívás, commentjel" verziót :-)
Akkor rátérhetünk az érdemi tesztelésre is, ugye :-))
uh... ezzel a masklen-el igazad van :-))
mondjuk konkretan nem tudnek igy olyan postgres query-t osszeallitani ami kart okozna a rendszerben.. asszem insertet nem lehet igy betenni..
nade azert kijavitom jool
az az igazsag, hogy lekerdezesenkent max 1 nagyon egyszeru select + insert hajtodik vegre mivel a postgres adatbazist csak a keresesek statisztikai celu tarolasara hasznaljuk..
a kereso motorhoz semmi koze, annak teljesen fuggetlen adatbazisa van
(btw azert nem mazlink van, hanem a postgres locking mechanizmusat atneztuk..)
egyebkent 300 konkurrens lekerdezes az napi kb 10m keresest jelentene... ennyire azert nem szamitunk a kozeli jovoben :-))
Na, akkor leirom egy picit bovebben, hogy
miert verciki a parameter-nem ellenorzes.
Ok, ugy tunik, hogy osszeallitotok egy query-t a PostgreSQL szamara a 80. sorban. (hm, apt-get install postgresql-doc, egy ora olvasas)
mit szolsz a kovetkezohoz?
sid=%20masklen%28%27194.88.58.33%27%29
(vagyis masklen('194.88.58.33') )
szintaktikailag helyes eredmenyt ad, es ugy tunik, hogy a masklen() hivast a PostgreSQL vegrahajtotta.
----
A lock-kal kapcsolatban:
nekem ugy tunik (mert valtozik a sid), hogy olvasasonkent tortenik egy adatbazis update. Termeszetesen olvasasonkent rengeteg adatbazis query tortenik. Ezert tartom erdekesnek, hogy nagy szamu parhuzamos lekerdezes eseten a kenyszeru 'write lock' mennyire uti a nagyszamu 'read lock' -ot, es ez mennyire kerulheto meg. Pl, probaljatok mar ki 300 parhuzamos kapcsolattal a rendszer mukodeset, ne elesben haljon le, akkor mar aligha lesz ido az egeszet ujragondolni. Hasonloan, az adatbazis update a keresomotor felol mennyire gatolja az adatbazis query-t a lekerdezes felol, stb. Na, ujabb 20 perc PostgreSQL doksi olvasas, aztirja, hogy a query default lock-ja "ACCESS SHARE MODE" ami nem utkozik az update default "ROW EXCLUSIVE MODE" -val. hm... lehet, hogy mazlitok van az adatbazismotorral. Ehez persze a konkret kodot kellene ismerni, igy csak tippelgetek.
keress: %%%%%%%*
eredmény: sherlockd error[113]: (a csonkolt szo tul sok talalatot eredmenyez, adjon meg hosszabb elotagot)
keress: %%%%%%%%*
eredmény: A keresése nem eredményezett találatot.
-- szerintem a ,,sherolckd error'' zavaró.
keress: ..sid=2147483648
eredmény: Warning: PostgreSQL query failed: ERROR: pg_atoi: error reading "2147483648": Numerical result out of range in /var/www/search.php3 on line 79
Warning: Supplied argument is not a valid PostgreSQL result resource in /var/www/search.php3 on line 79
Warning: Cannot add header information - headers already sent by (output started at /var/www/search.php3:79) in /var/www/search.php3 on line 156
Warning: Cannot add header information - headers already sent by (output started at /var/www/search.php3:79) in /var/www/search.php3 on line 157
-- hasonló a nem számmá konvertálható értékekkel:
... sid=t
... from=6000 (tul nagy szám)
sherlockd error[106]: (hiba)
Tudom, szőrösszivű vagyok... de szerintem az a ,,sid=t ''-re adott hibakezelés vérciki.
Másik. A ProgreSQL kepes rekord szintu lockra?
HA nem, akkor itt is komoly problematok lesz a nagyszamu folyamatos lekerdezesnel. Akarcsak magaban a forumban.
Másik. Milyen motor van alatta? Az indexer alatt? a spider alatt? figyelembe veszi a robots.txt -t?
Másik. Az url szűrés lesz majd részleges?
pl url:www.elte.hu -ra 1940 találatot adott, az url:elte.hu és
url:*elte.hu -ra egyet sem.
Lavór... ööö Whyling: a Matáv az Matáv, ha valamit a kezükbe vesznek, az olyan is lesz.... Miért lenne jobb a Vizsla, mint a többi részlegük? :-((
Gyertyános: ha a topikgazdának nem jön fel automatikusan a kedvencekben a sajátja, akkor az csak egy elfuserált tamagoccsitulajdonosnak jó, akinek sorra döglenek a kütyüi...
Pozsi: kösz a választ. Anchor :-((((. Jó lenne következtetni belőle. (Olyan programon dolgozom, amely a lementett topicot szétdarabolja, hogy az egyes hozzáköpések egy levelezőben folderekbe rendezhetők legyenek, és ehhez lett volna jó.) De végül is megkerülhető egy külön táblázat felvételével.
A kifejezések keresése valóban fontos lenne. Például hogyan keresek FAT32 drivert NT alá? Az nt-t kidobja, hogy csak két betű. A Vizslán írhatok ilyent hogy nt-alá (A szóközök helyettesíthetők - jellel, egyszerűbb mint az ékezet)
Nevek keresésénél is fontos lenne. A Heurékában legalább ott van helyette a NEAR operátor.
A topicokban annak tartalma alapján való keresés érdekes - így újraéledhetnek pár hónapja halott topicok is - a gond az hogy a topicgazda nem biztos hogy észreveszi, ill. lehet hogy már nem érdekli a téma.
Szabó János... egy szerencsétlen névválasztás megpecsételi a sorsát a legkitűnőbb embereknek is... Talán még írd be mellé, hogy: honvéd* avagy padödö -mp3, szerintem jobb lesz mindenkinek. (Próbáltátok már a kiváló csillagos keresést? Ragozó nyelvek esetében elengedhetetlen.)
Ha jól tudom, "sher" a kereső szignója. Arra ne fogadj nagy összeggel, hogy milyen IP-ről jön, az lehet, hogy változik az idők folyamán.
Ékezetek ügyben sokat vitáztunk illetve éjjel hosszasan rágtuk a kispárna sarkát, végül is arra jutottunk, hogy az a néhány találat, amit a rosszul kezelt ékezetek miatt vesztünk, valamint a könnyebb begépelhetőség (nem mindenki magyar vindózzal nyomul ám! képzelj el egy dél-koreai Linux for Macintosh-t) megéri, ékezet suxx. Talán többet nyerünk, mint vesztünk ezzel a döntéssel.
--
ERN0.GLYKOLSTOP.E170
http://franko.index.hu/ - ez neked vicces.
Jó ez a kereső a találatok szempontjából. Viszont nagyon hiányolom a lap fissítésének dátumát! Időrendbe lehessen rakni a lapokat, hogy a legfrisseket nézhessem meg.
Jó opció volna, a csak egy lapot minden szerverrol, helyről.
Ja, és ne feledjétek, az Altavizslánál könnyű jobbnak lenni: a régi lapjaimat két év alatt sem sikerült kiszedni, és az újakat sem regisztrálni. Továbbá sok az elavult link a találatok közt.
HAJRÁ!
