3

We have a web application which currently operates like this on a typical view/page:

  • the front has to display 100+ "previews" (in the form of base64 images)
  • each of this preview is built on-demand by the backend when the front requests it
  • a pool of 8 standard ajax requests are running in queue until all previews are loaded

Let me illustrate this with a picture:

Initial loading

Sometimes the user does something that modifies some of the previews and those (and only those) have to be requested again by the front. In this case it goes like this:

Modified previews loading

At this moment, waiting for 100+ previews to load initially can take a long time (between 30 and 50 seconds), which is very annoying.

Before coming to the actual question, let me state a few points:

  • each preview is totally independent from the others
  • each preview can be built almost instantly by the back-end
  • each preview's base64 payload weighs virtually nothing (a few kb)
  • establishing an http connection actually takes most of the time
  • of course, no more than around 8 ajax requests can work concurrently
  • if the user leaves to another view while 8 requests are being handled, the browser will wait to have some room in his ajax queue before loading elements from the new view, which is very annoying (the new view can remain empty for many seconds before something happens)
  • we can't bulk all the previews in one big request because sometimes (and it's not predictable), it happens that a particular preview takes a lot of time (several seconds) to built, and we don't want to penalize the other previews which could be loaded much faster

So, my questions are:

  • could using a socket dramatically improve connection time so that the app is much more responsive at initial loading and in case of modifications in previews?

  • could messages exchanged in this socket be asynchronous so that if we ask for 100+ previews at the same time, they will all be loaded very quickly? And if so, is there a maximum number of concurrent messages in the socket?

  • can all the concurrent messages for which the front is currently waiting for, be instantly dropped if the user exits this view to visit another one? or does it even matter if there are virtually no concurrent messages limit?

We're using EmberJS for the front with EmberData and Flask for the back.

3

Could using a socket dramatically improve connection time so that the app is much more responsive at initial loading and in case of modifications in previews?

Yes. Sockets are designed specifically for this.

Could messages exchanged in this socket be asynchronous so that if we ask for 100+ previews at the same time, they will all be loaded very quickly?

The design would most likely take the form: receive a message, update a tile. It would be asynchronous in the sense that it would not require either a partial or complete page reload.

Is there a maximum number of concurrent messages in the socket?

One, as far as I know. But you can receive serial messages very rapidly.

can all the concurrent messages for which the front is currently waiting for, be instantly dropped if the user exits this view to visit another one?

Send a message to the host to the effect that the view has changed. Program the host to respond accordingly.

See Also
http://socket.io/
http://socket.io/blog/introducing-socket-io-1-0/

  • Thanks for your response. Is there really no standard way to exchange messages in parallel, as all the previews are thoroughly independent from one another? – Jivan Feb 11 '16 at 0:22
  • 1
    Set up multiple websocket channels. But really you should only need one. You could also send updates for all 100 previews in the same packet, but you told me that they're all independent. You'll have to experiment to see what kind of arrangement works the best for your particular application. – Robert Harvey Feb 11 '16 at 0:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.