Dev server takes minute and a half to boot up

[kshefchek]

This is non urgent but something I noticed while hacking on biolink, running the dev server via:

python biolink/app.py

takes ~100 seconds to start up. This can be cumbersome when making small changes and checking updates. There appears to be some preloading steps that are executed twice. See the attached logs: biolink-dev-logs.txt

[cmungall]

that's not good, Deepak and I can take a look at this

[deepakunni3]

I noticed this two weeks ago and here is what I gathered.

• AnnotationScore class initializes OwlSimApi, which in turn loads scigraph:ontology into memory (~30 seconds)
• PhenoSimEngine class initializes OwlSimApi, which in turn loads scigraph:ontology into memory (~30 seconds)
• This is done at startup to prevent large wait times for API calls that uses AnnotationScore and PhenoSimEngine
• It takes about ~70 seconds for the App to initialize in production
• It takes almost twice that for the App to initialize in dev
  • because in dev mode, we are running the app in FLASK_DEBUG mode, which initializes the app twice. https://github.com/biolink/biolink-api/blob/697e298202688c351f8a4314421e7a0ae648b2ce/biolink/app.py#L73 The second time, Werkzeug reloader spawns a child process so that it can restart that process each time there is a code change (https://stackoverflow.com/questions/25504149/why-does-running-the-flask-dev-server-run-itself-twice/25504196)

Notes:

• It looks like the operation of loading scigraph:ontology into memory is not being cached since its querying scigraph each time
• We can disable the app from initializing twice in dev mode with the following (but we lose out on hot-reload):

  app.run(debug=True,use_reloader=False)

[kshefchek]

Ah so I'm the culprit! I'll have to remind myself what I'm doing here and take a different approach.

[deepakunni3]

If Ontobio is properly caching scigraph:ontology then this step should move faster. The first call will take 30 seconds and all subsequent initialization will take a fraction of that.

Although I am not sure why caching is not working.

[kshefchek]

possibly related - https://github.com/biolink/ontobio/pull/278#issuecomment-455020850

[deepakunni3]

Okay, I'll take a look at it. Might be a limitation of the caching mechanism used

[kshefchek]

uncommenting https://github.com/biolink/ontobio/blob/d2ab6facf14bc373c4f008e00c40b2e717a8285c/ontobio/ontol_factory.py#L78 helps a little. I'm questioning my design decision. OwlSim2Api could be treated like a singleton class, and I'm not sure the best place to instantiate it. Another option is to adjust the constructor so it's not creating a scigraph ontology factory, or moving the _get_owlsim_stats method out of the class and caching it.