Search is dood

[OverSoft]

Ik weet niet of ik het via hier moet doen, maar ik doe het toch maar.

Sinds een minuut of 10 is de search overleden, je kan wel zoeken, maar hij vindt niets.

[ACM]

wat probeer je te vinden dan

Zo te merken zijn er weer mensen die niet beseffen dat het van f5 trager ipv sneller wordt

De load is weer eens veel te hoog...

[ Voor 70% gewijzigd door ACM op 01-06-2003 12:49 ]

[ArthurMorgan]

tja, irritant ja... ik kwam er ook al achter. Naja zal vast wel weer opgelost worden zo
ACM, waar ik ook op zoek hij doet het niet.

[ Voor 20% gewijzigd door ArthurMorgan op 01-06-2003 12:48 ]

[Erkens]

search doet het hier prima hoor (duurt alleen iets langer dan normaal)

[ Voor 37% gewijzigd door Erkens op 01-06-2003 12:50 ]

[ACM]

code:

acm@ares(pts/0):~
acm$ uptime
 12:49:21 up 101 days, 14:31,  1 user,  load average: 13.90, 13.70, 9.40

Zucht....

en er zitten uiteraard weer een hele serie 'ge-f5-de' zoekopdrachten tussen, die nog steeds lopen en niet door php af te knallen zijn zodra de gebruiker weggaat

edit:

Nahja, soms is het al zo traag dat je niet beseft dat jouw query de boel alleen nog maar slomer maakt natuurlijk.

[ Voor 19% gewijzigd door ACM op 01-06-2003 12:52 ]

[Toet3r]

doet het hier ook, nog geen minuut gelede heb ik hem gebruikt en het werkte allemaal goed, op dat ie redelijk sloom is na dan

[Erkens]

ACM schreef op 01 June 2003 @ 12:50:
Zucht....

en er zitten uiteraard weer een hele serie 'ge-f5-de' zoekopdrachten tussen, die nog steeds lopen en niet door php af te knallen zijn zodra de gebruiker weggaat

is tegen dat f5 gedrag niets te doen
(wetende dat tweakers vaak erg ongeduldig zijn )

[ACM]

de search heeft zijn ups en downs, zodra er veel mensen een phrase-search doen en ook op f5 gaat rammen wordt het erg sloom...

daar is niet veel aan te doen, ook een snellere machine helpt daar maar deels tegen.
En daar elke keer een topic over openen maakt het trouwens ook niet sneller

[Ramon]

heeft PHP geen caching systeem

[ACM]

Erkens schreef op 01 June 2003 @ 12:52:
is tegen dat f5 gedrag niets te doen
(wetende dat tweakers vaak erg ongeduldig zijn )

Iedereen bannen die dat doet bedoel je?

Nee, php wacht op een antwoord van de searchengine en verwerkt dan geen 'user went away' meldingen, totdat de searchengine klaar is en een antwoord geeft, zodat php weer verder kan...

Ik heb wel een script gebouwd dat elke query die langer dan een minuut al loopt killed, want de kans is klein dat de gebruiker daar nog op wacht of dat als ie erop wacht het antwoord hem nog bereikt.
En dat zelfde script killed ook alle duplicate queries, aangezien de kans nihil is dat twee gebruikers toevallig tegelijkertijd dezelfde query afvuren. De kans is wel groot dat zo iemand op f5 duwde.
Dat script veegt elke minuut de processlist redelijk schoon, maar soms is het zo erg dat ie er gewoon weinig aan kan doen. Bijvoorbeeld omdat er juist vrij veel verschillende opdrachten lopen.

Maar binnen React is er weinig aan te doen, door de beperkingen van oa php zelf hierin.

[ACM]

Tampie schreef op 01 June 2003 @ 12:54:
heeft PHP geen caching systeem

En wat zou dat moeten doen?

De zoekresultaten opslaan? Als ie ze nog niet gevonden heeft zodra iemand op f5 drukt heeft dat weinig zin

Maar heel letterlijk: Nee, heeft het niet. Je kan dat soort dingen uiteraard wel maken.

[Snow_King]

ACM schreef op 01 June 2003 @ 12:57:
[...]

En wat zou dat moeten doen?

De zoekresultaten opslaan? Als ie ze nog niet gevonden heeft zodra iemand op f5 drukt heeft dat weinig zin

Maar heel letterlijk: Nee, heeft het niet. Je kan dat soort dingen uiteraard wel maken.

maak dat dan

nee, maar ik dacht wel eens gehoord te hebben van een cache systeem in php?

[Ramon]

je zou toch bijvoorbeeld iets kunnen maken wat de resultaten cached voor 5 minuten ofzo? zodat er niet weer een nieuwe database request gedaan hoeft te worden binnen die tijd, waarmee je dus F5 afvangt, en mensen die misschien op hetzelfde zoeken?

Of is dit onzin?

[Verwijderd]

Snow_King schreef op 01 June 2003 @ 14:56:
[...]


maak dat dan

nee, maar ik dacht wel eens gehoord te hebben van een cache systeem in php?

ASP.NET heeft dat

[Verwijderd]

Is het niet mogelijk een sessie als 'zoekende' te markeren? En dan een constructie als:

als zoekdende dan bericht 'er is nog een zoektocht actief' anders ga zoeken

[Snow_King]

Tampie schreef op 01 juni 2003 @ 14:59:
je zou toch bijvoorbeeld iets kunnen maken wat de resultaten cached voor 5 minuten ofzo? zodat er niet weer een nieuwe database request gedaan hoeft te worden binnen die tijd, waarmee je dus F5 afvangt, en mensen die misschien op hetzelfde zoeken?

Of is dit onzin?

dan gaat php dus voor DB spelen ipv MySQL?
Want zoals jij het zegt zou je de gehele DB moeten chachen, want de kans dat iedereen exact de zelfde querie doet is echt 0.0000000000000000000000001% ofzo

[Ramon]

Snow_King schreef op 01 juni 2003 @ 15:01:
[...]


dan gaat php dus voor DB spelen ipv MySQL?
Want zoals jij het zegt zou je de gehele DB moeten chachen, want de kans dat iedereen exact de zelfde querie doet is echt 0.0000000000000000000000001% ofzo

lijkt me niet dat de hele DB geraadpleegt wordt in 5 minuten toch? ACM zegt dat F5en een probleem is, en dat kan je oplossen door een bepaalde tijd dingen (zoekresultaten) te cachen, zodat ze niet elke keer als iemand F5ed er een nieuwe request naar de DB moet.

[ArthurMorgan]

Maar hij vraagt een nieuwe query aan (dmv f5) voordat de vorige uitgevoerd en gechaced is. Dus dan worden ze ws alsnog beide opgevraagd en pas daarna gecached.... en heb je er alsnog weinig aan.

[Spider.007]

is het niet mogelijk om een process af te schieten zodra door een user een tweede zoekopdracht wordt afgeschoten

[ACM]

Tampie schreef op 01 June 2003 @ 14:59:
je zou toch bijvoorbeeld iets kunnen maken wat de resultaten cached voor 5 minuten ofzo? zodat er niet weer een nieuwe database request gedaan hoeft te worden binnen die tijd, waarmee je dus F5 afvangt, en mensen die misschien op hetzelfde zoeken?

Of is dit onzin?

't Nadeel van die f5 duwers is niet dat ze f5 duwen, maar dat de 'vorige query' nog niet klaar was. Dus dat er ook nog geen resultaat is dat gecached had kunnen worden.

Verder zijn de zoekopdrachten dusdanig divers dat het niet echt raadzaam is daar nog een cacheing layer tussen te proppen, enkel voor de spaarzame gevallen dat gebruikers meerdere malen hetzelfde opzoeken.
Uiteraard heb je sowieso nog de 'bladeraars', waarmee je dus eenmalig 100 results op kan halen, terwijl die persoon er bijv maar 25 bekijkt en dus de volgende request lekker vlot kan lopen. Maar als de mensen dan niet bladeren (doen ze niet zo veel) of hun query wijzigen heeft die cacheing al geen nut meer

Al met al denk ik dat er wel _wat_ winst te halen is door zoekresultaten te cachen, maar of die winst opweegt tegen de verhoogde complexiteit en dergelijke? Dat weet ik niet

Verwijderd schreef op 01 June 2003 @ 15:01:
Is het niet mogelijk een sessie als 'zoekende' te markeren? En dan een constructie als:

als zoekdende dan bericht 'er is nog een zoektocht actief' anders ga zoeken

Zoiets zou kunnen werken. Maar heeft een heel groot nadeel. Namelijk dat als een zoekopdracht bijv een minuut duurt, dan is de kans heeel klein dat er nog een resultaat terug komt. Ongeacht of de gebruiker hier 'schuld' (door de browser weg te klikken) aan had of niet.

En dan staat de sessie voor de rest van de levensduur als 'zoekende' gemarkeerd

[ArthurMorgan]

Spider.007 schreef op 01 juni 2003 @ 15:18:
is het niet mogelijk om een process af te schieten zodra door een user een tweede zoekopdracht wordt afgeschoten

ACM schreef op 01 juni 2003 @ 12:50:

code:

acm@ares(pts/0):~
acm$ uptime
 12:49:21 up 101 days, 14:31,  1 user,  load average: 13.90, 13.70, 9.40

Zucht....

en er zitten uiteraard weer een hele serie 'ge-f5-de' zoekopdrachten tussen, die nog steeds lopen en niet door php af te knallen zijn zodra de gebruiker weggaat

blijkbaar niet dus

[ACM]

Spider.007 schreef op 01 June 2003 @ 15:18:
is het niet mogelijk om een process af te schieten zodra door een user een tweede zoekopdracht wordt afgeschoten

Dat is ook helaas maar een deel van het probleem.

Want als er 20 gebruikers tegelijk zijn, dan stort de load sowieso al in. Wat jij zegt gebeurt nu al een beetje trouwens, met het script dat ik hier beschrijf: ACM in "Search is dood"

't Voordeel van jouw versie is natuurlijk dat er bij jou direct de vorige wordt afgeschoten (en ja das te maken), 't voordeel van zoals ik het heb is dat er veel eenvoudiger gewerkt kan worden en ook queries die niet ge-f5-ed zijn, maar gewoon te lang duren weggehaald worden.

Alfredt schreef op 01 juni 2003 @ 15:19:
blijkbaar niet dus

Nee, dat zijn verschillende gevallen

Hoewel het wat lastiger wordt als er een 'remote-database' gebruikt gaat worden, wat enigszins in de planning ligt

[ Voor 17% gewijzigd door ACM op 01-06-2003 15:43 . Reden: *cough, spelfout* ]

[Spider.007]

Alfredt schreef op 01 juni 2003 @ 15:19:
[...]


[...]

blijkbaar niet dus

Inderdaad; maar waarom niet Het is immers ook mogelijk om queries van meer dan 1 minuut af te schieten; dan moet het toch ook mogelijk zijn om aan een process een user te hangen en op basis daarvan te killen

ik moet sneller tikken; bedankt ACM

Hoewel het wat lastiger wordt als er een 'remote-database' gebruikt gaat worden, wat enigszins in de planning licht

Programmeurs en spelling

[ Voor 25% gewijzigd door Spider.007 op 01-06-2003 15:32 ]

[Verwijderd]

Spider.007 schreef op 01 juni 2003 @ 15:25:


[...]
Programmeurs en spelling

Dit is wel behoorlijk ernstig inderdaad.

[ACM]

't is warm he?

[Glashelder]

ACM schreef op 01 June 2003 @ 15:43:
't is warm he?

dan ga je toch naar Tele2-City. Daar hebben ze airco

[G33rt]

dual-zip schreef op 01 juni 2003 @ 15:45:
[...]

dan ga je toch naar Tele2-City. Daar hebben ze airco

en een heleboel hete servers

[kieskes]

Tis daar altijd lekker 22C hoor

[Verwijderd]

kieskes schreef op 01 juni 2003 @ 16:04:
Tis daar altijd lekker 22C hoor

En dat is koeler dan buiten.

[Snow_King]

G33rt schreef op 01 June 2003 @ 16:03:
[...]


en een heleboel hete servers

ik denk dat ACM daar ok wel heet van wordt, of niet ACM?

[ACM]

Nee absoluut niet... Die TC ruimte is echt erg om langer dan een paar minuten te zijn, al die herrie en suffe servers...

Magoed, hou het een beetje 'on topic', 't is de HK niet hier.

[Devian]

Ik vind de search ook vrij bagger de laatste tijd.. traag.. helft van de tijd komt tie met 0 resultaten.. doe je het dannog eens dan vind tie in 1x wel wat... error 404's erbij tussen.. en vroeger had tie ook betere resultaten.. ( toen die nog los van react werkte..)

[chem]

404 lijkt me stug, dat zal IE's bagger interpretatie wel zijn.
Er is trouwens niet veranderd aan Omega, behalve de aansturing. Dat hij dus vroeger beter werkte, is een gevoelsmatige mening.

[Apen-nootjes]

mm.... beetje off-topic.. chem.. je hebt een raar kleurtje.. (paars ) 'k ken wel groen = adje en rood = modje maar wat is paars nu weer????

Apen-nootjes is zich nu al een beetje aan het schamen dat hij het niet weet...

[Glashelder]

Paars betekent dat ie van Parse is. Maar wat is een devver nou precies?

[Apen-nootjes]

devver = develeper.. dus iemand die de (forum)software ontwikkeld

[Ramon]

developer

[SED]

ACM schreef op 01 June 2003 @ 15:43:
't is warm he?

Waarom niet gewoon de f5 key disablen in het browser window.
Als je niet weet hoe dat moet kijk dan even hier:

http://www.faqts.com/know...w.phtml/aid/18584/fid/125

dit is geen oplossing voor de gebreken van php maar een workaround

[MSalters]

Klein vraagje: Waarom PHP voor de search? Aansluiten op Parse?

[Erkens]

MSalters schreef op 03 juni 2003 @ 21:31:
Klein vraagje: Waarom PHP voor de search? Aansluiten op Parse?

volgens mij was Omega een C++ search engine

quote: http://www.xapian.org/features.php

• Written in C++.

[ Voor 16% gewijzigd door Erkens op 03-06-2003 21:35 ]

[chem]

Omega is een C++ interface (CGI) voor Xapian, een C++ probalistic indexer.

[ACM]

Sterker nog, omega is een interface voor xapian, geschikt voor cgi interactive en commandlineparametered cli (om het maar lastig uit te leggen).

Dat wij die dan weer via php aansturen is om het idd aan te laten sluiten op react

[joepP]

chem schreef op 03 juni 2003 @ 21:35:
Omega is een C++ interface (CGI) voor Xapian, een C++ probalistic indexer.

Hoe onmogelijk is het er een extra laagje tussen te bouwen in C++ die de requests queued, zodat de load niet te hoog wordt? En dubbele requests afvangt?

Lijkt me toch niet zo moeilijk?

[EnsconcE]

SED schreef op 03 June 2003 @ 21:08:
[...]


Waarom niet gewoon de f5 key disablen in het browser window.
Als je niet weet hoe dat moet kijk dan even hier:

http://www.faqts.com/know...w.phtml/aid/18584/fid/125

dit is geen oplossing voor de gebreken van php maar een workaround

zit je dan niet met het probleem waneer de query verzonden is hij is nogal lang bezig en de pagina niet helemaal geladen is dat je alsnog f5 kan drukken, of die mooie knop bovenaan je venster???

wat d8 je van een script te schrijven dat men maar 1 zoekopdr8 tegelijk kan uitvoeren, dus op het moment dat er een 2de zoekopdr8 aankomt terwijl de 1ste nog niet verwerkt is dat de 1ste gekilled word?

[ACM]

joepP schreef op 04 June 2003 @ 11:39:

en dus moet iedereen een minuut of wat wachten op het moment dat er een paar trage queries achter elkaar tussenzitten?

Maar de architectuur van omega is dat het ad-hoc wordt aangeroepen, het is geen daemon. Een daemon zou wel iets helpen, maar niet eens zo heel veel (tenzij je ervoor zorgt dat er max 5 clients tegelijk draaien ofzo).

Dus het is nu niet een kwestie van een while-loopje aanpassen, maar het bouwen van een complete daemon. En dat is vast niet moeilijk, maar ook weer niet weinig werk

Het is wel de bedoeling zoiets te maken odd trouwens.

[ Voor 15% gewijzigd door ACM op 04-06-2003 12:14 ]

[joepP]

ACM schreef op 04 June 2003 @ 12:12:
[...]

en dus moet iedereen een minuut of wat wachten op het moment dat er een paar trage queries achter elkaar tussenzitten?

Maar de architectuur van omega is dat het ad-hoc wordt aangeroepen, het is geen daemon. Een daemon zou wel iets helpen, maar niet eens zo heel veel (tenzij je ervoor zorgt dat er max 5 clients tegelijk draaien ofzo).

Dus het is nu niet een kwestie van een while-loopje aanpassen, maar het bouwen van een complete daemon. En dat is vast niet moeilijk, maar ook weer niet weinig werk

Het is wel de bedoeling zoiets te maken odd trouwens.

Het grootste voordeel is natuurlijk dat je de queries dan wel kan onthouden, en indien iemand een zoekopdracht opgeeft die nog draait kan je direct een vriendelijk verzoekschermpje maken om dat NOOIT meer te doen

Als het dan af en toe traag gaat loopt het niet helemaal meer in de soep door de F5-rammers.

Overigens schrijft een programmeur met ervaring op het relevante platform zo'n progsel binnen een uurtje.

[ Voor 6% gewijzigd door joepP op 04-06-2003 16:47 ]

[Snow_King]

een ander heel radicaal idee.

Je plaatst 2 database servers, elke INSERT querie laat je uitvoeren op 2 servers.
De databases blijven dus gelijk.

Je kan ook een master en slave setup maken.

Bij het starten van GoT pakt ie random een server.
Je hebt dat dus twee keer zo veel capiciteit.
De zoek queries worden ook verdeeld over 2 servers.

idee?

[Kees]

zoeken gaat allang niet meer via mysql

[Vaudtje]

En deze dan:
Na het starten van een zoekopdracht krijgt gebruiker een geweldig geile animated gif te zien met "U bent aan het zoeken...." en een cancel knoppie.
Deze pagina pollt alleen maar of het zoekresultaat er al is, of is gewoon een niet afgesloten response die, zodra alles klaar is een location.replace doet (Elke zoekvraag moet dus wel een id krijgen).
Als je dan F5't, krijg je geen nieuwe zoekopdracht .
Uitgeknalde browsertjes vang je eventueel af door de 'connection reset by peer' melding, of door het bestaande ACM mechanisme.
En met de cancel knop kan de gebruiker voortijdig een nieuwe zoekvraag starten, zodat het zoek proces dan ook meteen kan worden afgeschoten.

Nou alleen nog ff bouwen...

[ACM]

joepP schreef op 04 June 2003 @ 16:44:
Het grootste voordeel is natuurlijk dat je de queries dan wel kan onthouden, en indien iemand een zoekopdracht opgeeft die nog draait kan je direct een vriendelijk verzoekschermpje maken om dat NOOIT meer te doen

Als het dan af en toe traag gaat loopt het niet helemaal meer in de soep door de F5-rammers.

Klopt, maar het is dan ook zo dat dit ook veranderingen in react met zich mee brengt en we binnenkort een machine met een fatsoenlijke harddisk-setup willen inzetten. Dan moet er sowieso een daemonnetje gedraaid worden en daar komen uiteraard ook dat soort dingen wel in (hoewel een xinetd-setup ook erg makkelijk is )

Overigens schrijft een programmeur met ervaring op het relevante platform zo'n progsel binnen een uurtje.

Juistum, multithreading in c++ op linux is alleen helaas niet zo triviaal als dat is voor Java of zelfs c zelf
Multiprocessing is wel mogelijk en dat is ook wel vrij simpel te bouwen, maar je zit nog steeds met locking en dergelijke.

En aangezien het nu al een c++ cli-app is, is het wel zo mooi en efficient om die hele c++-app te vervangen door een enkele daemon die in c++ geschreven is.

[ACM]

Snow_King schreef op 04 June 2003 @ 17:45:
De zoek queries worden ook verdeeld over 2 servers.

Dat zou kunnen, hoewel de searchengineniet met mysql werkt, maar dan heb je twee servers die zwaar belast worden en niet meer echt voor andere taken gebruikt kunnen worden. En hoewel we er een paar hebben houdt het nou ook weer niet echt over

Vaudtje schreef op 04 June 2003 @ 18:17:
Nou alleen nog ff bouwen...

Idd, lekker bewerkelijk

[Exirion]

joepP schreef op 04 June 2003 @ 16:44:
Overigens schrijft een programmeur met ervaring op het relevante platform zo'n progsel binnen een uurtje.

Nou, waar blijft ie? Heb je 'm nou nog niet af?

[rammes]

wat is het alternatief als zoekmachine???

[ACM]

wat bedoel je met die vraag

alternatief van wat ten opzichte van wat?

[Devian]

ACM schreef op 04 juni 2003 @ 19:18:
wat bedoel je met die vraag

alternatief van wat ten opzichte van wat?

hij vraagt naar de 2e zoekmachine die er niet is

[Red]

Devian schreef op 04 juni 2003 @ 19:30:
[...]


hij vraagt naar de 2e zoekmachine die er niet is

Met google kan je ook nog altijd GoT doorzoeken, kijk maar

http://www.google.nl/sear...et&btnG=Google+zoeken&lr=

[ Voor 5% gewijzigd door Red op 04-06-2003 20:00 ]

[xoror]

joepP schreef op 04 juni 2003 @ 16:44:
[...]


Het grootste voordeel is natuurlijk dat je de queries dan wel kan onthouden, en indien iemand een zoekopdracht opgeeft die nog draait kan je direct een vriendelijk verzoekschermpje maken om dat NOOIT meer te doen

Als het dan af en toe traag gaat loopt het niet helemaal meer in de soep door de F5-rammers.

Overigens schrijft een programmeur met ervaring op het relevante platform zo'n progsel binnen een uurtje.

LOL, jij heb denk ik nog nooit een programma in elkaar gedraaid. Een deamon schrijven die ook nog iets nuttigs doet is niet zo triviaal als jij het voorstelt.

je hebt het ook al over result caching, dat impliceert complexe logica om de boel niet uit de hand te laten lopen. (dit gedeelte lukt je al niet in 1 uur). en dan ben ik nog niet begonnen over shared resources die je moet managen onder de threads, of met shared mem/ipc met processen.

jij gaat er ook vanuit dat een 'programmeur met ervaring' vrijwel geen fouten maakt (want anders lukt het ECHT niet in een uurtje). Juist als je het goed en nauwkeurig wil designen om bugs en bijwerking te verminderen ben je ontzettend veel tijd kwijt aan je design (die je later dik gaat terug verdienen (onderhoud, bugs, speed etc)).

oh, en dan heb ik het nog niet eens gehad over stresstest etc

anyway ik heb me erg geamuseerd over je posting. misschien moet je wat meer research doen wat er allemaal bij een zoek machine komt kijken.

[joepP]

xoror schreef op 04 juni 2003 @ 20:03:
[...]


LOL, jij heb denk ik nog nooit een programma in elkaar gedraaid. Een deamon schrijven die ook nog iets nuttigs doet is niet zo triviaal als jij het voorstelt.

Dat zal je nog erg tegenvallen.

je hebt het ook al over result caching, dat impliceert complexe logica om de boel niet uit de hand te laten lopen. (dit gedeelte lukt je al niet in 1 uur). en dan ben ik nog niet begonnen over shared resources die je moet managen onder de threads, of met shared mem/ipc met processen.

Ik heb het helemaal niet over result caching, slechts over een queuetje van 1 minuut die dubbele requests blokkeert. En daarop een aantal readers die de daadwerkelijke requests doen.

Ik zie één hele shared resource, namelijk die queue. Single writer, multiple readers. Daar heb je 1001 standaardimplementaties voor, ook in C++.

jij gaat er ook vanuit dat een 'programmeur met ervaring' vrijwel geen fouten maakt (want anders lukt het ECHT niet in een uurtje). Juist als je het goed en nauwkeurig wil designen om bugs en bijwerking te verminderen ben je ontzettend veel tijd kwijt aan je design (die je later dik gaat terug verdienen (onderhoud, bugs, speed etc)).

Luister, met een enkele queue en wat workerthreads ben je er al. Als je dat niet binnen een uurtje kan schrijven heb je geen ervaring met multithreading programmeren. Of je kan gewoon niet programmeren. We hebben het hier over misschien 100 regeltjes code als je een standaard multithreaded queue gebruikt.

oh, en dan heb ik het nog niet eens gehad over stresstest etc

anyway ik heb me erg geamuseerd over je posting. misschien moet je wat meer research doen wat er allemaal bij een zoek machine komt kijken.

Misschien moet je eens wat beter leren lezen. Ik stel een supersimpel progje voor, niets meer, niets minder. En maak je geen illusies, ik weet precies wat er komt kijken bij het ontwikkelen van fatsoenlijke grote softwarepakketten.

[ACM]

joepP schreef op 05 June 2003 @ 15:49:
Ik zie één hele shared resource, namelijk die queue. Single writer, multiple readers. Daar heb je 1001 standaardimplementaties voor, ook in C++.

Goed, doe mij de standaard threading library voor C++ onder unices es? (antwoord: bestaat niet, voor zover ik kon vinden tenminste)
Of de standaard mutex-library? (zal wel bij die standaard threading library zitten/horen)

Als je dat niet binnen een uurtje kan schrijven heb je geen ervaring met multithreading programmeren. Of je kan gewoon niet programmeren. We hebben het hier over misschien 100 regeltjes code als je een standaard multithreaded queue gebruikt.

Maak maar dan.

Ik ben ermee begonnen maar liep oa ertegenaan dat mijn ervaring met threading in C++ niet bestaat en alleen al het vinden van een threading library niet iets is dat je binnen een uur doet, als je tenminste de documentatie nog wilt vergelijken...

Ik vind jouw opmerking wel grappig, ik zou het in Java idd in een paar uur gemaakt hebben en heb dus wel enige ervaring met multithreading en ben ook geen onervaren programmeur.
Maar de keuzemogelijkheden bij jou zijn wat lastig dan, ik kan dus of niet programmeren of niet met threads omgaan... sja?

Ow vergeet niet dat het niet een standaard lege threading setup moet zijn, maar dat ie ook nog eens geintegreerd moet worden met de code van Xapian (bij mijn aanpak zette ik de code van Omega er vrijwel letterlijk tussen) en dat je genoodzaakt bent eerst een tijd lang te lezen op de socket om de opdracht te weten en die dan weg te geven, maar je mag natuurlijk niet tijdens het inlezen van 1 opdracht de daemon compleet blokkeren...
Athans, ik zou dat niet gedaan hebben.

Misschien moet je eens wat beter leren lezen. Ik stel een supersimpel progje voor, niets meer, niets minder. En maak je geen illusies, ik weet precies wat er komt kijken bij het ontwikkelen van fatsoenlijke grote softwarepakketten.

Dan nodig ik je bij deze uit zo'n daemon te bouwen, wel een die werkt op linux en samenwerkt met Xapian (evt door domweg de code van Omega te kopieren) dus he?

Wmb kan je de source die ik met mijn simpele forking-daemon al heb zo krijgen.

[Snow_King]

Ok, dit begint mij dus echt té ver te gaan.
Dacht dat we het hier over PHP & MySQL hadden, maar het gaat dus verder dan dat.
C++ en C, wtf?

Veel succes, maar dit gaat boven mijn kennis!

[joepP]

ACM schreef op 05 June 2003 @ 16:20:
[...]

Goed, doe mij de standaard threading library voor C++ onder unices es? (antwoord: bestaat niet, voor zover ik kon vinden tenminste)
Of de standaard mutex-library? (zal wel bij die standaard threading library zitten/horen)

[...]

Maak maar dan.

Onder Windows geen probleem, maar mijn ervaring met Linux is ongeveer 0. Blijkbaar onderschat ik de complexiteit van multithreading binnen de C++/Linux context...

Ik ben ermee begonnen maar liep oa ertegenaan dat mijn ervaring met threading in C++ niet bestaat en alleen al het vinden van een threading library niet iets is dat je binnen een uur doet, als je tenminste de documentatie nog wilt vergelijken...

Ik vind jouw opmerking wel grappig, ik zou het in Java idd in een paar uur gemaakt hebben en heb dus wel enige ervaring met multithreading en ben ook geen onervaren programmeur.
Maar de keuzemogelijkheden bij jou zijn wat lastig dan, ik kan dus of niet programmeren of niet met threads omgaan... sja?

Ik bedoel uiteraard wel "ervaren op het platform". Maar dat er geen standaardlibraries zijn voor multithreading lijkt me toch wel sterk, dat is toch een van de eerste dingen die je nodig hebt om een fatsoenlijke applicatie te bouwen?

Ow vergeet niet dat het niet een standaard lege threading setup moet zijn, maar dat ie ook nog eens geintegreerd moet worden met de code van Xapian (bij mijn aanpak zette ik de code van Omega er vrijwel letterlijk tussen) en dat je genoodzaakt bent eerst een tijd lang te lezen op de socket om de opdracht te weten en die dan weg te geven, maar je mag natuurlijk niet tijdens het inlezen van 1 opdracht de daemon compleet blokkeren...
Athans, ik zou dat niet gedaan hebben.

[...]

Dan nodig ik je bij deze uit zo'n daemon te bouwen, wel een die werkt op linux en samenwerkt met Xapian (evt door domweg de code van Omega te kopieren) dus he?

Wmb kan je de source die ik met mijn simpele forking-daemon al heb zo krijgen.

Helaas, zoals gezegt kan ik niet met Linux overweg.

Maar toch, je maakt toch gewoon een progje dat:
- inkomende boodschappen aanneemt.
- checked of reeds eerder (< 1 minuut) dezelfde message is binnengekomen. Ja -> errormelding, Nee -> ram in verbinding + zoekopdracht in queue.

Verder nog meerdere gelijke threads die:
- uit de queue lezen
- de zoekopdracht doorgeeft aan het zoeksysteem
- wacht op result en dat weer teruggeven aan de client

Wat is daar precies het probleem mee?

[ACM]

joepP schreef op 05 June 2003 @ 17:01:


Ik bedoel uiteraard wel "ervaren op het platform". Maar dat er geen standaardlibraries zijn voor multithreading lijkt me toch wel sterk, dat is toch een van de eerste dingen die je nodig hebt om een fatsoenlijke applicatie te bouwen?

Ik geloof dat dat soort zaken een van de redenen zijn dat er voornamelijk in C gedevved blijft worden op Linux, pthreads is daar min of meer de standaard en dat werkt aardig... Hoewel ik Java vele malen beter vind met dat soort dingen.

Maar ik ben nou eenmaal geen ervaren c/c++ programmeur en dan is dat soort dingen opzoeken nog weer lastiger

Maar toch, je maakt toch gewoon een progje dat:
- inkomende boodschappen aanneemt.
- checked of reeds eerder (< 1 minuut) dezelfde message is binnengekomen. Ja -> errormelding, Nee -> ram in verbinding + zoekopdracht in queue.

Om de boodschap uit te lezen moet je wel al de verbinding opgezet hebben en je kan natuurlijk niet zomaar je centrale 'accept handler' die opdrachten laten uitlezen, als het es wat langer duurt zit je centrale process geblokkeerd.

Verder nog meerdere gelijke threads die:
- uit de queue lezen
- de zoekopdracht doorgeeft aan het zoeksysteem
- wacht op result en dat weer teruggeven aan de client

Mijn setup was trouwens om een lijstje bij te houden met actieve queries en dan daarin op te snorren of een searchquery al bestaat of niet, zoja -> error etc.

Wat is daar precies het probleem mee?

Niet veel
Behalve dat het niet zo duidelijk is hoe je het best/handigst multithreading in C++ kan verkrijgen onder linux...

[joepP]

ACM schreef op 05 juni 2003 @ 17:09:
[...]

Ik geloof dat dat soort zaken een van de redenen zijn dat er voornamelijk in C gedevved blijft worden op Linux, pthreads is daar min of meer de standaard en dat werkt aardig... Hoewel ik Java vele malen beter vind met dat soort dingen.

Maar ik ben nou eenmaal geen ervaren c/c++ programmeur en dan is dat soort dingen opzoeken nog weer lastiger

Klopt, het is klote ontwikkelen in een taal die je niet goed beheerst. Dus, iemand anders het laten doen. Bijvoorbeeld door een topic in P&W te openen.

[...]

Om de boodschap uit te lezen moet je wel al de verbinding opgezet hebben en je kan natuurlijk niet zomaar je centrale 'accept handler' die opdrachten laten uitlezen, als het es wat langer duurt zit je centrale process geblokkeerd.

Okee, dan accepteer je de connectie centraal, en doe je de afhandeling met een thread.

[...]

Mijn setup was trouwens om een lijstje bij te houden met actieve queries en dan daarin op te snorren of een searchquery al bestaat of niet, zoja -> error etc.

Kan ook, komt op hetzelfde neer uiteraard.

[...]

Niet veel
Behalve dat het niet zo duidelijk is hoe je het best/handigst multithreading in C++ kan verkrijgen onder linux...

Open een topic in P&W

[xoror]

het lukt je niet. je moet ook nog communicatie protocol afspreken waarmee php jouw deamon kan aanspreken etc. in een uur lukt je nooit. zelfs onder windows niet. Onder windows moet je het als een service schrijven. Wat dacht je daarnaast van user input filteren?

zoals ik het zo hoor ben jij echt een super coder

Luister, met een enkele queue en wat workerthreads ben je er al. Als je dat niet binnen een uurtje kan schrijven heb je geen ervaring met multithreading programmeren. Of je kan gewoon niet programmeren. We hebben het hier over misschien 100 regeltjes code als je een standaard multithreaded queue gebruikt.

sure bouw maar onder windows Binnen 1 uur. Een service die robuust en betrouwbaar is. en ook nuttige info terug geven.

acm:
http://www.boost.org/libs/thread/doc/index.html
gebruik de thread implementatie van boost. je kan ook pthreads gebruiken in c++ hoor of een wrapper.

[ACM]

xoror schreef op 05 juni 2003 @ 21:50:
het lukt je niet. je moet ook nog communicatie protocol afspreken waarmee php jouw deamon kan aanspreken etc. in een uur lukt je nooit.

Protocol is belachelijk simpel
Domweg de cli-parameter-parser van omega hergebruiken om een string die php opstuurde te decoderen.
Er is toch maar 1 functie: input is 'zoeken', output is 'zoek resultaat'

acm:
http://www.boost.org/libs/thread/doc/index.html
gebruik de thread implementatie van boost. je kan ook pthreads gebruiken in c++ hoor of een wrapper.

Humm, zal er es naar kijken. Btw, dat _is_ een wrapper voor pthreads
Ik was zelf met http://www.cs.wustl.edu/~schmidt/ACE.html deze aan het klooien.

[xoror]

right, ik prog nu hier direct met pthreads. het is vrij recht toe recht aan.

als je direct aan cli prog doorgeeft zou je denk ik maar deels helpen. waarom niet die code in je deamon stoppen. Stored omega zoek resultaten ? zodat vervolg opdrachten snel gaan ?
dat zou je wel kunnen bouwen (als het er niet in zit that is). Je kan dan gelijk cache systeem bouwen om zo je systeem te ontlasten. Het is toch vaak zo dat er veel wordt gezocht op bepaalde termen. als je het op deze manier bouwt zul je wel een bepaalde protocol moeten opzetten.

[ Voor 9% gewijzigd door xoror op 05-06-2003 22:15 ]

[MSalters]

Toch blijf ik me afvragen waarom het multi-threaded moet? Kun je niet simpelweg Xapian meerdere keren opstarten?

Natuurlijk moet je checken of de search al bezig is, maar daar is een oplossing voor. Hash de searchstring, maak een IPC key aan, probeer de message queue daarmee te openen. Lukt dat, dan ben je dus niet de eerste die die seach probeert (of je hebt een hash collision). In dat geval haal je het resultaat uit de message queue zodra het daar opduikt.
Kun je de msgQ niet openen, ben je de eerste en moet je'm dus aanmaken en je resultaat erop zetten.

[ACM]

xoror schreef op 05 juni 2003 @ 22:13:
als je direct aan cli prog doorgeeft zou je denk ik maar deels helpen. waarom niet die code in je deamon stoppen.

Dat bedoel ik dus

Maar gewoon die cli-parameter-parser gebruiken voor de parameters op de socket. Kan altijd later wel mooier.

Stored omega zoek resultaten ? zodat vervolg opdrachten snel gaan ?
dat zou je wel kunnen bouwen (als het er niet in zit that is). Je kan dan gelijk cache systeem bouwen om zo je systeem te ontlasten. Het is toch vaak zo dat er veel wordt gezocht op bepaalde termen. als je het op deze manier bouwt zul je wel een bepaalde protocol moeten opzetten.

Nee omega is vanzichzelf compleet stateless. Maar de resultaten voor het zoeken op dezelfde termen zullen toch niet altijd hetzelfde zijn. En als er herhaaldelijk wordt gezocht op dezelfde termen zullen de benodigde database-file-onderdelen sowieso al in het ram zitten, dus is het al relatief snel te doorzoeken.
Sterker nog _dat_ gebeurt natuurlijk al

[ACM]

MSalters schreef op 05 June 2003 @ 22:26:
Toch blijf ik me afvragen waarom het multi-threaded moet? Kun je niet simpelweg Xapian meerdere keren opstarten?

Ja dat kan en gebeurt nu natuurlijk al.

Natuurlijk moet je checken of de search al bezig is, maar daar is een oplossing voor. Hash de searchstring, maak een IPC key aan, probeer de message queue daarmee te openen. Lukt dat, dan ben je dus niet de eerste die die seach probeert (of je hebt een hash collision). In dat geval haal je het resultaat uit de message queue zodra het daar opduikt.
Kun je de msgQ niet openen, ben je de eerste en moet je'm dus aanmaken en je resultaat erop zetten.

Ah, en dat is makkelijker dan een multithreaded applicatie bouwen??

Feel free to build it, maar ik zou dat soort zaken in Java zo in elkaar draaien (hoewel, ipc in java? ) maar in C/C++ lukt me dat echt niet zomaar, dus ga ik ook niet ook nog eens proberen nieuwe paradigma toe te passen in een relatief nieuwe taal voor me

[xoror]

wat msalters schrijft is niet zo lastig hoor

IPC is communicatie mechanisme tussen processen.
en search string hashen doe je toch al neem ik aan ? als je je string hashed naar bepaald getal kan je veel sneller checken of die search al aan de gang is. Een hash collision is dat 2 verschillende input hetzelfde hash resultaat oplevert. je zou dan in de veronderstelling kunnen zijn dat het dezelfde zoek opdracht is (wat niet het geval is).

[ACM]

xoror schreef op 05 June 2003 @ 22:37:
wat msalters schrijft is niet zo lastig hoor

IPC is communicatie mechanisme tussen processen.
en search string hashen doe je toch al neem ik aan ? als je je string hashed naar bepaald getal kan je veel sneller checken of die search al aan de gang is. Een hash collision is dat 2 verschillende input hetzelfde hash resultaat oplevert. je zou dan in de veronderstelling kunnen zijn dat het dezelfde zoek opdracht is (wat niet het geval is).

Ik weet wat ipc is, heb er nooit wat mee gedaan echter.
Ik weet wat hashing is, echter doet omega _al_ het werk van het parsen van de zoekopdracht aangeleverd door php tot het formuleren van het resultaat, ik weet globaal wat wat doet, maar heb geen behoefte het helemaal door te worstelen en dat lijkt me ook niet noodzakelijk.

Ik weet zelfs wat een hash collision is

* ACM 's grootste barriere is niet _wat_ te implementeren, maar _hoe_ dat in c++ te doen... wat voor een ervaren c++ proggert vast een beetje vreemd zal lijken

[xoror]

goed, maar waarom bouwen jullie niet gewoon in php/mysql. je houdt gewoon per sessie bij of er al een search bezig is. Je staat gewoon 1 search per sessie toe. (tis toch zo dat een user die niet inlogt, ook een sessie krijgt met react ?)

de oplossing om een deamon te bouwen doet niets anders dan dat in dit geval...
beetje verspilde moeite wordt dat dan

[ACM]

En dus maar elke sessie een extra parameter en check geven?

Sja... vind ik ook niet zo elegant en er moet _toch_ een daemon komen (ok kan eenvoudig via xinetd ofzo) om omega te draaien op een andere server.

[Erkens]

xoror schreef op 05 June 2003 @ 23:20:
goed, maar waarom bouwen jullie niet gewoon in php/mysql. je houdt gewoon per sessie bij of er al een search bezig is. Je staat gewoon 1 search per sessie toe. (tis toch zo dat een user die niet inlogt, ook een sessie krijgt met react ?)

de oplossing om een deamon te bouwen doet niets anders dan dat in dit geval...
beetje verspilde moeite wordt dat dan

mja, maar wat als ik meerdere searches tegelijk wil? wat nog wel eens gebeurt

[ACM]

Dan moet je even wachten

Anyway, ik kap met die c++-zooi.
Het kost me te veel tijd om bij te leren wat ik blijkbaar allemaal nog nodig heb om een fatsoenlijke daemon te schrijven hiervoor. En die tijd heb ik er niet voor en wil ik er ook niet voor vrijmaken.

Ik gooi de omega-cli-app wel 'gewoon' rechtstreeks achter xinetd met als optie dat ie de dienst moet weigeren als de load boven de 5 uitkomt.
Mocht iemand zich geroepen voelen een goede, efficiente deamon te schrijven, je kunt zo de software krijgen (is toch GPL ) om op voort te borduren, maar ik ga niemand vragen hiervoor.

[NoBody]

dan zit de load nu zeker ook boven de 5

iig kan ie nu ook niets vinden sinds een minuut of 2

[KaMiKaZe]

I second that, de search is zo dood als een pier

[Raku]

Ik kreeg net ook dit:
Forbidden
You don't have permission to access /forum.php/find/poster/36807 on this server.


--------------------------------------------------------------------------------

Apache/1.3.27 Server at search.gathering.tweakers.net Port 80

[Sir_Killalot]

Eth3r3al schreef op 07 June 2003 @ 04:33:
Ik kreeg net ook dit:
Forbidden
You don't have permission to access /forum.php/find/poster/36807 on this server.


--------------------------------------------------------------------------------

Apache/1.3.27 Server at search.gathering.tweakers.net Port 80

Je bent niet de enige

[Raku]

Sir_Killalot schreef op 07 June 2003 @ 04:42:
[...]


Je bent niet de enige

Eerst werkte alleen de search niet. Stom natuurlijk , ik wist niet dat zoeken op 36xxx hetzelfde is als gewoon zoeken... Klinkt ook wel logisch

[Verwijderd]

't is 10 voor 5 op een zaterdag. 't zal wel gewoon onderhoud zijn.

[Sir_Killalot]

Verwijderd schreef op 07 June 2003 @ 04:48:
't is 10 voor 5 op een zaterdag. 't zal wel gewoon onderhoud zijn.

Tsss, kunnen ze dat niet 's middags doen ofzo ??

[ Voor 5% gewijzigd door Sir_Killalot op 07-06-2003 04:59 ]

[Verwijderd]

Ja schandalig he

[Sir_Killalot]

Ik ga een claim indienen!

[iets]

Sir_Killalot schreef op 07 juni 2003 @ 04:58:
[...]


Tsss, kunnen ze dat niet 's middags doen ofzo ??

offtopic:
Die chello snelheidstester is een beetje buggy

[Sir_Killalot]

ShotGun schreef op 07 juni 2003 @ 05:06:
[...]

offtopic:
Die chello snelheidstester is een beetje buggy

Joh, gewoon op vorige klikken

daarvoor moet je niet bij mij zijn

_{je heb wel een foute XP theme zeg}

[Mentalist]

Verwijderd schreef op 07 June 2003 @ 05:04:
Ja schandalig he

Waarom doen ze dat niet 's ochtends vroeg? Dan ben ik er toch praktisch nooit

Maar idd, hier ook zo dood als een pier. Eerst kreeg ik een witte pagina, wat later een Forbidden en nu een "De pagina kan niet worden weergegeven.".

Krijgen we nou straks een #1?

[tweakerbee]

Ze kunnen hier ook echt geen fatsoenlijk tijd nemen voor onderhoud aan een van de servers. Altijd wel weer van die idioten die menen dat ze om half zes 's ochtends op tweakers.net moeten zitten. Gewoon die users een 24-uurs ban geven als er onderhoud komt Preventief ruimen, zeg maar.

[Sir_Killalot]

tweakerbee schreef op 07 June 2003 @ 05:30:
Ze kunnen hier ook echt geen fatsoenlijk tijd nemen voor onderhoud aan een van de servers. Altijd wel weer van die idioten die menen dat ze om half zes 's ochtends op tweakers.net moeten zitten. Gewoon die users een 24-uurs ban geven als er onderhoud komt Preventief ruimen, zeg maar.

met tweakers.net is niks mis hoor

[Verwijderd]

W3ird_N3rd schreef op 07 June 2003 @ 05:11:


Krijgen we nou straks een #1?

Nostalgie

[ACM]

't is dat ook geen onderhoud...

* ACM gaat es kijken wat er is.

[ACM]

Er is niks

Alles werkt hier gewoon?

Humm, misschien dat kees ergens mee bezig was, dat zou ik niet weten. Lijkt me niet trouwens, jullie zijn gewoon allemaal gek

[ Voor 69% gewijzigd door ACM op 07-06-2003 11:18 ]

[Sir_Killalot]

ACM schreef op 07 juni 2003 @ 11:17:
Er is niks

Alles werkt hier gewoon?

Humm, misschien dat kees ergens mee bezig was, dat zou ik niet weten. Lijkt me niet trouwens, jullie zijn gewoon allemaal gek

Rond 5.45 deed tie het weer

[Raku]

ACM schreef op 07 June 2003 @ 11:17:
Er is niks

Alles werkt hier gewoon?

Humm, misschien dat kees ergens mee bezig was, dat zou ik niet weten. Lijkt me niet trouwens, jullie zijn gewoon allemaal gek

* Raku meld zich alvast aan voor TBS

Maar is de username search niet gewoon hetzelfde als de normale search dan? Dus dat de normale search eruit ligt dat ook de username search eruit ligt?

[ACM]

Euh, hangt van de url af
Op je naam klikken is wel dezelfde server, maar gaat via mysql.

[Mentalist]

ACM schreef op 07 June 2003 @ 18:56:
Euh, hangt van de url af
Op je naam klikken is wel dezelfde server, maar gaat via mysql.

Op m'n naam klikken ging ook niet afgelopen nacht.