I have nginx sitting in front of my bokeh server. It has been working well for the most part, however today, I happened to notice something odd in the logs. When I bring up the any of my notebooks, they seem to be loading twice, at least, based on the stdout logs, that is what it looks like. It doesn’t seem to be the browser double requesting, so I am not sure what is going on. All I know is that I could be saving 1/2 the load time if I can prevent it from happening, which would be a plus.
Hi @chrisr it’s hard to say much without more details. I’ll mention that the initial HTTP connection returns a script that immediately makes a second websocket connection (which is what is actually used for everything). Perhaps this is what you are seeing.
Thanks @Bryan . I don’t think that is it. The first connection downloads the script that makes the web socket connection, so that first connection shouldn’t actually run the notebook. Only after the websocket is connected should the notebook code run I believe. When I am watching the logfile, I see the notebook being executed twice. It doesn’t seem to be timeout related, because some notebooks take only a few seconds, and other can take 30 or 40 seconds, but in both cases, usually, it runs twice. About 10% of the time, it only runs once, which makes it even weirder.
I am starting the bokeh server like this:
nohup bokeh serve --keep-alive 3000 --num-procs 0 --allow-websocket-origin=abseil1.fyre.ibm.com --use-xheaders --port 5100 --log-file bokeh_serve.out &
As mentioned, I have nginx in front of it. I setup nginx as suggested here: https://bokeh.pydata.org/en/latest/docs/user_guide/server.html
What other kind of details would help?
@chrisr actually I think I need to get clarification on something. I didn’t notice the explicitly the first post but you have repeated that the notebooks are running twice. Are you running the Bokeh server on notebooks, i.e.
bokeh serve foo.ipynb
If not, I don’t understand what you mean by “the notebook is running twice” since the Bokeh server does not serve notebooks (as notebooks).
If it is what you mean, and also if your nginx is configured to load balance mulitple bokeh servers at once, then I can see how this might happen. The initial HTTP request does create a session (i.e. run the app code). If there is just one Bokeh server, the websocket connects and starts using that same session. But if there is more than one Bokeh server, and the websocket connection lands on a different server process, then the second process has to manufacture a new session on the fly (i.e. also run the app code). This is the only scenario that comes to mind given the information you have provided. If you are not running multiple servers / load balancing then I don’t have an explanation.
I would like to change this in the future so that session creation only happens on the websocket connection, and not on the HTTP connection. ↩︎
Sorry, yes, that is what I mean. I have a set of notebooks that I developed using holoviews that I make available to a wider audience by downloading them to a server, and serving them with a standalone bokeh server, which I guess I hadn’t actually put together, but yes, turns them into bokeh apps. So the output from the apps (that are stored in notebook .ipynb files) seems to execute twice instead of just once like I would expect.
Are you running multiple instances of the bokeh server behind nginx? (see above, you replied while I was editing my original reply)
Yes, I am specifying --num-procs 0 and so it is starting up 5 instances.
OK, that’s almost certainly what is going on then. As I mentioned I would like to change things so that session creation only happens on the websocket side of things, so this situation would be avoided. I am not actually sure there is an actual issue for this, though. Would you mind creating one on GitHub?
@chrisr I replied on the issue, but I will also reply here. I found these instructions for implementing session affinity with free Nginx:
If you could try them out with your specific case it would be extremely helpful to know whether it helps.
Thanks @Bryan , sticky sessions does help. I have updated the git issue with the details.
That’s actually fantastic to hear, I will update the docs and default suggested config