User Upload  of Submission

• upload data file to server ~500ms
• virus scan inbound file ~250ms
• store file in data volume ~170ms
• record submission in database ~100ms
• post file to turnitin ~30,000ms
• post submission record to admin ~500ms
• email user ~250ms
• generate document thumbnail ~500ms

lots of things to do ~2500ms* before we show user upload submission results in browser

*excludes posting file to external entities

users get bored easily

whilst all these processes are taking place we could show a progress bar, or pictures of cats

please wait

whilst we process your upload

please wait

whilst we process your upload

still waiting

for your upload to be processed?

click on cat video

processing*

*5 mins before the deadline your not the only one submitting their work

bored user = click back / cancel / close window 

increased chances that not all the required proceses will complete successfully

peaky* load spikes

*pesky

how it should be done

• upload file
• record submission, start background processing
• return user to submission page
• user receives progress update messages as they occur then updates web page user interface

We cant process all these tasks in realtime

when the deadline for submissions is near, thats when the load will be the highest

scaling

by distributing the work amoungst multiple compute nodes we can do more stuff at once

forming an orderly line

who is next please

redis:queuing

• maintain list of jobs that need to be done
• concurrent creation of jobs by web servers etc
• first come first served (fifo) order of processing
• multiple task workers
• requeue failed tasks with customisable retry delay
  • job only removed from queue on success
  • job idempotency 
• dynamic handling of load spikes

the upload processing queue

• create workers for each long running task
• distribute the workers across a number of compute nodes or run multiple workers in parallel *
• each worker emits status update events eg virus scan ok

* depending on the nature of the task, be it io / cpu bound will determine the number of worker instances for a specific queue or job type that you will want to run in parallel per physical (or virtual) node

keeping track

• workers publish events to relevant topics when states changes or progress has (or has not) been made
• store state in database and maintain an audit trail of events and related context info

once uploaded

• show user submission results page
• use stored database state to render page
• establish websocket connection (to receive live updates) and authenticate to 'sync' web plus websocket sessions
• subscribe to your submission's topic "submission.420"
• websocket router authorises topic+user subscription 
• worker emits update message to topic: "your score is 42"
• browser receieves update message on subscribed topic and updates user interface / flashes message to user

powered by

to power the distribution of queued jobs we employ a number of key pieces of technology ranging from servers to frameworks, all thanks to the open source community

redis

redis is to key value stores as the sky is to clouds* - by combining a multitude of set operations, redis can be used for a number of senarious ranging from fifo queues to publish and subscribe message channels to buffers to list but a few

*depending on the weather not directly related to "cloud" computing

Releasing Grades

once marking is complete, the grades are then released

and the user can then see their grade*

* no reloading of page required unless you don't already have it loaded!

releasing the grades

• update assignment: set grade release date
• emit message to assignment topic to notify users of the event (flash message to user)
• emit message to each submission topic to notify users of grade so user interface can be updated

flash messaging

• display (flash) a message to a user
• can contain link, button, be modal, hide in n secs etc
• handle incoming flash message close to browser page movements (ie click link, recv msg, browser loads clicked link, recv'd msg never has chance to be seen) *
• useful for notification of state updates, errors, warnings etc.

*only confirm msg as received after its been in view for a certain time or a dom element has been toggled else it will be shown on next page view

web::sockets

message passing for the asynchronous  

wamp router

• component based router for websockets
• subscribes to redis topics and publishes messages to clients subscribed to the topics
• can reformat, filter, lookup more data before passing message on to websocket subscribers
• authenticates subscribers and authenticates subscription requests to provide the AA in AAA*

*Authentication, Authorisation, Accounting