non-blocking backend - Githubissues

sfu-natlang / lensingwikipedia

Lensing Wikipedia is an interface to visually browse through human history as represented in Wikipedia. This the source code that runs the website:

http://lensingwikipedia.cs.sfu.ca

Other

11 stars 4 forks source link

non-blocking backend #143

Closed anoopsarkar closed 8 years ago

anoopsarkar commented 9 years ago

@KonceptGeek and I discussed in person a change to the backend that would launch a query as a new thread and also return results incrementally back to the frontend.

This is related to issues #135 and #125

KonceptGeek commented 9 years ago

@theq629 @vlad003 , if possible may be we can have a Skype call and discuss various issues related to backend and come up with a plan to fix it and make it more scalable.

theq629 commented 9 years ago

Sure, if we can find a time that works (my only free time tends to be Vancouver late afternoon).

anoopsarkar commented 9 years ago

Any progress on this?

avacariu commented 9 years ago

What we discussed on Skype yesterday:

For each query we get, create a coroutine using gevent
Make the frontend to poll the backend to check on the status of a query (to check if the query failed, or the whole backend crashed)
- If backend times out (which it shouldn't since the actual queries are running async), we can assume it crashed
We need to figure out where the bottleneck truly is (CPU or I/O), and see if gevent is going to be enough or whether we'll have to use multiple processes on the backend (with some sort of loadbalancer in front).
We need to look into sharding whoosh

anoopsarkar commented 9 years ago

Is this issue still alive?

avacariu commented 8 years ago

Since I now have uWSGI running the query backend, it's using multiple processes and many gevent workers, so it'll allow many simultaneous queries, and will practically never crash. Each query itself will still block, but none of them seem slow enough for that to be a significant issue (i.e. nothing's timing out); so I think that submitting a query and then polling is overkill, and will only add unnecessary overhead. By the time the frontend will start polling for a response, it would've gotten one from the backend anyways.

What remains to be done is speeding up the processing of responses from Whoosh so that the backend can respond to queries faster; there are several nested for loops that are potentially looping over a large number of items and there should be a way of at least parallelizing those. That's a bit of a different issue than this one, though, so I'll consider this one fixed.