Archief - Tomorrowland 2014

Ooli zei:

Straks moet TML nog een tour gaan doen in BE alleen om de vraag aan te kunnen. TML Spring, TML Summer, ... misschien wat te veel van't goeie!

Klik om te vergroten...

Aangezien ze hier Black en Sensation hebben laten vallen voor Tomorrowland te organiseren denk ik niet dat ze een extra editie willen doen.
Mysteryland (het oudere broertje van Tomorrowland) had vroeger een indoor wintereditie. Dat is het oudste en nog actief outdoor dancefestival op dit moment, niet?

NDP zei:

Welke dag(en)? Staat niet op facebook

Klik om te vergroten...

De twee zondagen.

Uit de blogpost blijkt dus dat de refreshtijd in de queue 2 minuten is, maar wat houdt die 6 seconden dan precies in?
En kan je dus beter zelf de hele tijd refreshen omdat dat korter duurt dan 2minuten of toch gewoon van de refresh afblijven?

Eargasmmm zei:

dat mensen internet explorer nog gebruiken, dat snap ik dus echt niet. Dat ding valt uit na 2 youtubefilmpjes, zwijg stil van dit ticketsysteem er op laten bollen.

Klik om te vergroten...

Ik heb IE gebruikt en was sneller binnen met IE dan met elke andere browser

namreh zei:

Als schrijver van de blogpost ook even reageren. Ik heb deze morgen nog een leuk telefoongesprek gehad met de mensen bij Paylogic. Zij namen dit super sportief op (het had ook anders kunnen uitdraaien). Ik heb hen dan ook proficiat gewenst met hun systeem, dat perfect synchroon bleef lopen.

Zij gaan inderdaad wel wat aanpassingen doen aan het systeem, maar daar zijn ze natuurlijk beperkt in. Ik ben benieuwd wat ze gaan inbouwen. Als ze echt iets mooi inbouwen wordt het tenminste echt een loterij, nu was het geen loterij en was het kwestie van kennis en timing.

Ik vrees/vermoed dat er ook kopers met minder goede bedoelingen, deze manier hebben gebruikt om tickets in te slagen (wij waren allen met 4-5 browserschermen binnen, dus hadden 100 tickets kunnen kopen (autch voor de kredietkaartafrekening dan ;-) ).

Was leuke uitdaging, perfect gelukt en laat ons zeggen dat mijn google analytics overuren aan het draaien is met 300 simultane bezoekers op die blogpost.

Klik om te vergroten...

Als je nu eens zaterdagnamiddag een update post hier op 9Ls hoe het systeem dan zal werken ... dan is goed

Thuisgekomen om 17.35 vorig jaar bij de worldwide sale (start 17 u), pc opgezet en ondertussen gegeten. Toen ik terugkwam kwartier later, rond 18 uur, er direct in.
Maw wanhoop nooit en ga een kaars branden in de kerk ! (flame mij achteraf)

illuvattarr zei:

Uit de blogpost blijkt dus dat de refreshtijd in de queue 2 minuten is, maar wat houdt die 6 seconden dan precies in?
En kan je dus beter zelf de hele tijd refreshen omdat dat korter duurt dan 2minuten of toch gewoon van de refresh afblijven?

Klik om te vergroten...

Om het bondig samen te vatten, now that the cat's out of the bag:
- Algemeen is het je doel om ervoor te zorgen dat je request aankomt bij de de paylogic queue server van zodra die open gaat (om 11:00 op HUN klok). Daarvoor moet je een request uitsturen enkele milliseconden voor 11u op de klok van de paylogic queue. Een request uitzenden is NIET hetzelfde als de pagina openen (zie volgende punt)
- Indien je zelf refresht, wacht de browser 5 seconden vooraleer ze de request uitstuurt. Indien je dus continu refresht voordat die 5s om zijn, zal je browser nooit in de wachtrij komen. Van zodra je officieel in de wachtrij zit, heeft opnieuw refreshen geen zin, want je browser gaat in de achtergrond automatisch de queue server om nieuwe info vragen. (heel sporadisch blokkeert dit automatisch proces, en dit is een van de redenen waarom mensen soms aanhalen dat ze na refreshen "onmiddellijk in de shop" waren) --> dit heeft paylogic gedaan om te vermijden dat F5 drukken ook massaal veel requests naar hun servers uitstuurt.
- Voordat de queue officieel opengaat zal je browser automatisch om de 2 minuten de queue contacteren.
- Er is nog een heel leuk trucje van Paylogic. Namelijk (vereenvoudigd uitgelegd): als je de wachtrij open hebt een tiental seconden vòòr 11u en je refresht niet, en jouw eigen computerklok slaat 11u (los van of de paylogic queue open is of niet), dan gaat je browser DOEN ALSOF die wel open is en je in de wachtrij staat. In realiteit is dat NIET zo. Je browser gaat dan pas random tussen de 0 en de 60s na 11u contact opnemen met de queue om je in de wachtrij te plaatsen.

CONCREET:
- Refreshen om 11u stipt is sterk afgewezen, dan ga je pas om 11:00:05 in de queue zitten en ben je hopeloos te laat.
- het is het beste om te refreshen zoals op de blog van Herman staat, OF bv net iets meer dan 5 seconden voor 11u (rekening houden met laadtijd pagina + wachttijd browser).

Ongelooflijk veel succes gewenst!!

Okee bedankt voor de duidelijke uitleg hierboven.
Maar stel dat je dus later dan 11.00u de link aanklikt, dan heb je geen enkele invloed meer om er eerder doorheen te komen? Refreshen heeft dan dus geen zin? Het gaat dus puur om die ene window of opportuniy van die paar miliseconden tussen 10.59.54 en 10.59.55?

Een laatste vraagje nog: die 6 seconden vertraging, treedt die maar 1x op als je de link aanklikt of ook elke keer na 2 minuten als je automatisch ververst wordt?

Paul Kalkbrenner en Loco Dice erbij, de deftige namen beginnen te komen!

Het gaat idd om die ene window. Daar is het first come first serve van zodra de queue open is. Op dit moment lijkt dat toch zo

Die 6 seconden vertraging is er enkel bij manuele refresh. Bij de autorefresh treedt deze NIET op!

Correctie: bij manuele refresh en eerste inladen, voor de duidelijkheid!

Ooli zei:

Correctie: bij manuele refresh en eerste inladen, voor de duidelijkheid!

Klik om te vergroten...

Thanks voor je antwoord!
Dus dan klopt dit stukje niet op de blogpost, omdat er niet alleen bij de 1e keer 6seconden wordt opgeteld?

Een voorbeeldje van een onfortuinlijke/onwetende collega:

1. Ticketpagina opengedaan om 10:57:00
2. Ticketpagina ontvangt van Paylogic om 10:57:06 het antwoord dat de wachtrij niet open staat
3. Ticketpagina refreshed zichzelf om 10:59:06
4. Ticketpagina ontvangt van Paylogic om 10:59:12 het antwoord dat de wachtrij niet open staat
5. Ticketpagina refreshed zichzelf om 11:01:12
6. Ticketpagina ontvangt van Paylogic om 11:01:18 het antwoord dat de wachtrij openstaat en op welke plaats de collega staat

Ik vraag me af hoe de mainstage er dit jaar uit zal zien... Persoonlijke favoriet was the Book of Wisdom

Spyronamic zei:

Ik vraag me af hoe de mainstage er dit jaar uit zal zien... Persoonlijke favoriet was the Book of Wisdom

Klik om te vergroten...

Die van mij was het blauwe masker/monster, 2009 met Moby.

illuvattarr zei:

Thanks voor je antwoord!
Dus dan klopt dit stukje niet op de blogpost, omdat er niet alleen bij de 1e keer 6seconden wordt opgeteld?

Een voorbeeldje van een onfortuinlijke/onwetende collega:

1. Ticketpagina opengedaan om 10:57:00
2. Ticketpagina ontvangt van Paylogic om 10:57:06 het antwoord dat de wachtrij niet open staat
3. Ticketpagina refreshed zichzelf om 10:59:06
4. Ticketpagina ontvangt van Paylogic om 10:59:12 het antwoord dat de wachtrij niet open staat
5. Ticketpagina refreshed zichzelf om 11:01:12
6. Ticketpagina ontvangt van Paylogic om 11:01:18 het antwoord dat de wachtrij openstaat en op welke plaats de collega staat

Klik om te vergroten...

Inderdaad, dat is fout...

Moet zijn:

1. Ticketpagina opengedaan om 10:57:00
2. ticketpagina zendt request naar paylogic om 10:57:05 en enkele honderden ms (bv 360ms; hangt van je computer af)
2. Ticketpagina ontvangt van Paylogic om 10:57:05 en 400ms (=360+40) het antwoord dat de wachtrij niet open staat
3. Ticketpagina zendt request uit om 10:59:05 en 400ms (!) --> de 2 minuten tellen pas vanaf het moment dat het antwoord van de server is ontvangen
4. Ticketpagina ontvangt van Paylogic antwoord om 10:59:05 en 450ms (plus minus; 50ms varieert in functie van de load op de server) het antwoord dat de wachtrij niet open staat
4b. Ticketpagina DOET ALSOF je in de wachtrij bent om 11u stipt, van jouw computerklok. Dit gebeurt enkel indien je al minstens 1 antwoord had gekregen van de wachtrij voor 11u.
4c. Ticketpagina zendt een request uit, RANDOM tussen 11u en 11u01. Dit gebeurt enkel indien je al minstens 1 antwoord had gekregen van de wachtrij voor 11u. (ja!)
5. Ticketpagina zendt request uit om 11:01:05 en 450ms
6. Ticketpagina ontvangt van Paylogic om 11:01:05 en 500ms het antwoord dat de wachtrij openstaat en op welke plaats je staat. Inclusief je geschatte wachttijd, die niet wordt getoond maar wel wordt doorgezonden. --> kan zijn dat je via 4c al vroeger in de wachtrij stond.

Klik om te vergroten...

OPGELET: Paylogic kan de "2 minuten" periode dynamisch veranderen. Elke keer als je een antwoord krijgt van de Paylogic wachtrij hebben ze de mogelijkheid om het tijdstip van de volgende request te wijzigen. De berekening hierboven kan dus erg snel fout zijn. ADVIES, en je brengt me hier net op dit nieuw inzicht, waarvoor dank: Laad de pagina in om 16:59:55 (of 16:59:54 en enkele honderden milliseconden, afhankelijk van je PC snelheid). Waarom? Omdat Paylogic in staat is de 2 minuten te wijzigen bij het eerste antwoord dat je van de server ontvangt. Om 16:59:55 heb je dat antwoord nog nooit gekregen, bij de andere opties van Herman wel. Ook daar is de pagina van Herman dus niet helemaal juist. (sorry herman, 't was wel een zeer goede analyse hoor)

In the end is en blijft het wat gokken en geluk hebben hoor. Er zijn een aantal variabelen die je niet kan inschatten, zoals de snelheid waarmee je antwoord krijgt van de server.

PS: excuses voor de complexe uitleg, het is moeilijk om snel snel helder en tekstueel te verwoorden. Ik doe dit letterlijk tussen de soep en patatten

En nu begint het wedstrijdje met Paylogic Mijn gok is dat ze de refreshfrequentie lichtjes gaan randomizen. Altijd + of - enkele seconden. Dat is voldoende om de load te beperken.

Ooli zei:

OPGELET: Paylogic kan de "2 minuten" periode dynamisch veranderen.

Klik om te vergroten...

Dit is idd makkelijk te doen, maar dit is dan toch ook af te lezen in de javascript code van de queue(https://queue.paylogic.com/queue.js?v=386192 en zoeken op 120) ?

We kunnen deze thread bijna hernoemen naar "Programmeren voor dummies" (eerder was het "Buurtproblemen")

Blijf nog altijd de vingers kruisen voor een Pryda-feestje het eerste weekend. Please, please!

illuvattarr zei:

Dit is idd makkelijk te doen, maar dit is dan toch ook af te lezen in de javascript code van de queue(https://queue.paylogic.com/queue.js?v=386192 en zoeken op 120) ?

Klik om te vergroten...

Als je goed kijkt ga je merken dat je dit niet op voorhand kan voorspellen. 120 is de standaardwaarde.

Stan_V zei:

We kunnen deze thread bijna hernoemen naar "Programmeren voor dummies" (eerder was het "Buurtproblemen")

Blijf nog altijd de vingers kruisen voor een Pryda-feestje het eerste weekend. Please, please!

Klik om te vergroten...

Ik kruis

marcoVB zei:

Heb 4 tickets kunnen kopen voor het 2de weekend zonder camping..
Nu ben ik opzoek naar een oplossing voor ergens te kunnen slapen.
Mensen zonder camping, rijden die dan elke avond naar huis?

Klik om te vergroten...

er is een B&B in rumst homeNL die is aardig dicht bij het domein of je hebt ook een hotel in het centrum van Boom homepage_domus_hotel maar je zal er dan wel snel moeten bij zijn denk ik voor deze weekends.
je kan ook even horen of iemand zijn Dreamville passes doorverkoopt of je kan het weekend zelf een mobilhome huren maar dan raad ik je aan om die in Willebroek of Niel te parkeren want in Boom en Rumst wordt dan aardig gecontroleerd op wildcamperen en dat geldt eveneens voor mobilhomes.