Results still slow to access/download?

[shane]

I was wondering if we still should except some slowness in terms of accessing or downloading results, after the previous DDoS attack? I experienced two things that suggested there may still be some slowness, but it may be something I did or on my system.

First, before clearing some results from the server, I clicked to download them, and it took a while to start the download, though there were few results.

Second, after I deleted some results and then went to confirm the deletion (though I know you get a message confirming the deletion) by clicking on the three dots next to Results, it just get the spinner rather than an updated list.

Thanks.

[Jeremy]

Hello,

Yes, the servers still experience important delays in generating the results files. This is due to multiple factors. The attack monopolized the available resources, and many operations were put on hold, and some are still ongoing at present.

There also are new operations added to the queue every day, including, notably, requests to save important incoming data (sometimes of thousands of lines) which take priority over other operations, but also requests to generate results files, which also use up a good amount of memory.
I seem to notice several requests for results files within less than a second. Users of the farm who fail to get their results or get them very slowly should refrain from clicking multiple times on the Download button(s), of from refreshing the page repeatedly and requesting the results again. All the requests are being received, even if they take time: unfortunately, sending multiple requests will only slow down everything, and you will get your results with an even greater delay

Finally, possibly as a result of the original Ibex farm going down and of the recent attack, our database has now grown significantly. Because of the great amount of results lines in the database, accessing them takes a longer time (incidentally, this is why users receive notifications inviting them to regularly clear their results files from our servers)

Note that, as I am writing this message, the servers are not currently experience slowdowns, but you can expect slowdown episodes to occur again in the near future. I apologize for the inconvenience

Jeremy

[lilyokc]

Hi,

I’m joining the thread since I have a related question.

I have a new participant completing my experiment, which I know because I can see all of their recordings uploaded to my server. However, when I download the results file, while there was no significant delay in doing so, it only shows the submissions from up to the second to last participant. I wonder if this also has to do with the same servers issue, or is this something going on with my script, in which case I can share that.

Thanks!

[shane]

Hi Jeremy,

Thank you for the thorough and clear answer. That all makes sense, and I will keep it in mind as I accumulate and download results.

Thanks again,
Shane

[Jeremy]

Hi,

However, when I download the results file, while there was no significant delay in doing so, it only shows the submissions from up to the second to last participant.

How many submissions/lines do you have in your results file? There is a 100K-line limit on generating results files: if your results contain more lines than that, you will need to generate multiple results files, using the “from… to…” fields above the “Download” button

(also, if your experiment’s UploadRecordings trial takes place before your SendResults trial—as it should—there is a possibility that your participant did have their recordings uploaded while their responses were never send to the server, if they closed their tab too early)

Jeremy

[lilyokc]

Hi Jeremy,

I only have 6 submissions, so it’s probably not due to the results file being too large. I think what probably happened is that this participant closed the tab too early.

Is there any way for me to obtain information like subject ID and group before the SendResults trial, just in case this sort of thing happens again and I cannot retrieve these information?

Thanks,
Lily

[Jeremy]

I’m afraid that information is not available before the SendResults trial by default, but what you can do is name your MediaRecorder elements using it, eg (assuming you retreive the ID from the URL):

Template( row => 
  // ... code
    newMediaRecorder('record-'+GetURLParameter('id')+'-'+row.Group+'-'+row.Item, "audio")
  // ... code

Jeremy

[Author]

Posts