Niet werkende winkelmand met mijn systeem toevoegen

[Wiethoofd]

Ik heb sinds kort mijn systeemspecs in mijn profiel helemaal up to date gebracht.
Toen wou ik voor de gein even zien voor hoeveel ik het nu allemaal had kunnen kopen en voegde ik alles aan mijn winkelmand toe.

Hier komt het probleem: Dit wou niet.
ik krijg een wit scherm, laden doet niets van de winkelmand. ook via de knop bovenin (pricewatch > winkelmand) heb ik hetzelfde als de inhoud eenmaal is 'toegevoegd'
Ik weet dat het redelijk veel onderdelen zijn, maar het lijkt me niet dat het niet kan (ik heb Firefox en IE6 en 7 geprobeerd, en in alle krijg ik een wit scherm).

Ook vrienden heb ik het laten testen die eveneens een wit scherm krijgen.
het systeem: gallery: Wiethoofd
de link voor de winkelmand staat onderaan.

Om de winkelmand weer werkend te krijgen gewoon even een simpel systeem van een vriend oid opzoeken en die aan je winkelmand toevoegen en de 'huidige inhoud' overschrijven activeert de winkelmand weer. (cookies verwijderen kan ook)

Als dit aub gemaakt kan worden, graag.

[Osiris]

De Webdev-bar-Response-headers-functie zegt dat ie een "500 Internal Server Error" geeft. Zal wel weer een geheugenprobleempje oid zijn? Dat was de vorige keer wel zo bij witte pagina's met een 500-error Maar da's natuurlijk puur een gokje van mij, ik ken de code niet

[Wiethoofd]

hoezo geheugen probleem? van mij of van de tweakers server?
en ik krijg geen error code te zien

[Osiris]

Tweakers server En nee, die error-code is de HTTP-response-type ofzo, headers enzo, die zie je normaliter ook niet.

[Wiethoofd]

dan ligt het dus niet aan mij en kan het gemaakt worden lijkt me
zo ja, hoe snel?

[Orion84]

Volgens mij heeft dit bar weinig met het forum te maken, maar met de code van de Frontpage. Kortom, deze melding hoort hier niet thuis.

Bugs in de Frontpage kan je melden op de devtrack

[crisp]

--> Pricewatch

en ja, bij een winkelmand met veel items kan het even duren voordat alle combinaties van goedkoopste aanbieders vergeleken zijn. Bij teveel items krijg je dan een timeout. Misschien moeten we gewoon een cap instellen op aantal items?

[Wiethoofd]

ik zal nog even topic openen op de gegeven link (dankje crisp)

jammer dat hij een timeout geeft, maar als ik die van een vriend toevoeg (item of 15, doet hij het wel meteen, en bij mij 29 items niet?
en als je een max doet, doe dan 30 - 50 ofzo, als je een casemod hebt heb je al gauw veel losse dingen...
en als er een max aan komt, vermeld dat dan aub ook bij het invoeren van je sysspecs.

[ACM]

Wiethoofd schreef op maandag 28 januari 2008 @ 22:10:
ik zal nog even topic openen op de gegeven link (dankje crisp)

Dat was nergens voor nodig Crisp had juist je topic verplaatst.

jammer dat hij een timeout geeft, maar als ik die van een vriend toevoeg (item of 15, doet hij het wel meteen, en bij mij 29 items niet?

Elk extra product betekent dat je gemiddeld genomen een stuk of vijftien extra prijzen te verwerken krijgt en de combinatorische explosie dus ook gemiddeld genomen een factor vijftien stijgt... Dat gaat dus niet lineair, maar exponentieel.
Dus 16 producten is al een stuk zwaarder dan 15 en 29 is heel veel zwaarder dan 15, als je mijn exponentiele schatting aanhoudt is 29 zelfs een factor 29192926025390625 zwaarder dan 15 producten in je mandje... Nou zal in de praktijk natuurlijk blijken dat je juist met dat soort grote lijsten relatief veel minder populaire producten hebt, dus laten we het bijstellen naar 8 prijzen per product, dan hou je slechts een factor 4398046511104 over...
Er zijn wel wat shortcuts mogelijk in de berekening, en daar worden er ook wel een aantal van genomen, en bovenstaande schatting is wel een worst case scenario maar ik hoop dat zo een beetje duidelijker is waarom het niet een kwestie van een "paar items extra" is bij jou, maar eigenlijk heel erg veel extra.

[ Voor 3% gewijzigd door ACM op 28-01-2008 22:28 ]

[Wiethoofd]

ik snap het, en ook weer niet.
dat er veel gerekend moet worden snap ik, maar is de tweakers.net server niet snel genoeg? (zelfs na de upgrade)
wat ik niet snap ik dat de tweakersserver niet aangeeft dat hij het niet aankan en hij m'n volledige winkelmand blokkeert

[ACM]

Wiethoofd schreef op maandag 28 januari 2008 @ 23:57:
maar is de tweakers.net server niet snel genoeg? (zelfs na de upgrade)

Welke upgrade? Maar het is heel simpel, dit soort berekeningen worden wel eens met "combinatorische explosies" aangeduid en dat geeft wel aan hoeveel rekenwerk het is. En nee, er is gewoon een limiet aan wat de snelste servers binnen een bepaalde tijd kunnen doen.
Meerdere processoren benutten zou kunnen helpen, ware het niet dat de programma-complexiteit enorm toeneemt en het voor de meeste gebruikers niet eens nodig is, en bovendien is het winkelmandje natuurlijk lang niet de enige pagina die door diezelfde servers geproduceerd moet worden. Daarnaast neemt de verwerkingscapaciteit dan maximaal met een factor 8 toe, terwijl je met één product extra al een factor 10 of meer aan complexiteit kan toevoegen.

wat ik niet snap ik dat de tweakersserver niet aangeeft dat hij het niet aankan en hij m'n volledige winkelmand blokkeert

Het is bijzonder lastig vooraf in te schatten of iets lang of kort gaat duren... Als je 29 producten zou selecteren waarvan de beschikbare leveranciers allemaal die 29 producten kunnen leveren, dan is het een kwestie van evenveel berekeningen als leveranciers. Maar als een deel van de leveranciers maar een deel van de geselecteerde producten kunnen leveren, dan wordt het dus zo'n combinatorische explosie. Daardoor er is niet vooraf in te schatten of ie het wel of niet aan zou moeten kunnen. En tijdens de berekeningen bepalen of het te lang duurt zou weer extra moeite en rekentijd kosten.

Ik heb net nog wel wat bedacht waar het mogelijk wat efficienter van kan worden, maar ook dan blijft er gewoon een praktische limiet aan hoe snel die lijst gegenereerd kan worden.

[Verwijderd]

Mag ik het bewandelen van de weg van 29 producten die allemaal meerdere leveranciers kennen (toeganswegen) vergelijken met het berekenen van de optimale route zoals gebeurt in routeplanners? Daar worden ook technieken toegepast om extremen te elimineren (de route van Amsterdam naar Rotterdam via Groningen wordt niet overwogen als mogelijke kortste route).

Misschien zie ik de parallel met DPC / OGR rekenen verkeerd, maar volgens mij worden op dit moment de resultaten volledig brute-force berekend waar dat niet nodig is

[ACM]

Verwijderd schreef op dinsdag 29 januari 2008 @ 08:49:
Mag ik het bewandelen van de weg van 29 producten die allemaal meerdere leveranciers kennen (toeganswegen) vergelijken met het berekenen van de optimale route zoals gebeurt in routeplanners?

Ja, het is zo'n soort probleem.

Misschien zie ik de parallel met DPC / OGR rekenen verkeerd, maar volgens mij worden op dit moment de resultaten volledig brute-force berekend waar dat niet nodig is

Het wordt sowieso niet volledig brute-force gedaan, want er zijn een paar aannames die er voor zorgen dat er veel minder rekenwerk is. De belangrijkste is nu dat we aannemen dat een gebruiker zo veel mogelijk van zijn winkelmandje bij dezelfde winkel besteld, dus dat je geen deelverzamelingen krijgt waarbij product X1 bij winkel Y wordt gekocht en product X2 bij winkel Z, ondanks dat Y hem ook levert.

En ik ben bezig met het maken van een schatting van de laagst mogelijke prijs per winkel, waardoor je inderdaad veel eerder moet kunnen stellen dat het met die winkel niet gaat lukken.

[ Voor 9% gewijzigd door ACM op 29-01-2008 09:40 ]