Open ianthetechie opened 3 years ago
Hey there :wave:
I haven't used Hug much, but could this be the same issue as https://github.com/falconry/falcon/issues/1550 ?
If that is the root cause, it has been fixed; however the fix is not a part of any stable release yet.
@ianthetechie I don't know if Hug fully supports Falcon 3.0 out of the box, and you may run into other issues instead.
But it would be awesome if you could give falcon==3.0.0a3
a spin, and check if it improves your test suite performance.
I've noticed similar issues with the test suite run times when using hug.test.call
and the similar method based calls. Using falcon==3.0.0a3
dramatically improves that run time (12+ mins to ~100s). There does seem to be at least some incompatibility either in hug
or my usage because I have a couple failures as well as deprecation warnings. Thanks for the heads up about this Falcon issue!
Sorry for the complete ot, @ianthetechie I'm interested in knowing what tool(s) did you use to generate the graph?
Sorry I haven't had a chance to test with the falcon 3.0 alpha yet but I haven't forgotten ;)
@CaselIT the graph was generated by the PyCharm profiler.
Hey Tim,
I stumbled across an issue when digging into why our unit test suite was performing poorly. I'm not sure whether this is an issue with hug or falcon, but here's the quick overview. We have a suite of around 1000 tests that we run in pytest. We noticed running times were creeping up to around 30 mins. I initially blamed CI runners and questionable database operations but dug a little deeper with a profiler and discovered that around 75% of running time was spent constructing falcon APIs, of all things...
This was, to say the least, a bit surprising. So I dug in a bit more and realized that
hug.test.call
is creating a new server every single invocation, which is to say, a few thousand invocations per test run. TL;DR, I was able to cut runtimes by about 80% by not doing this. As for what to do about it, I'd welcome your input. This may be an issue with falcon, but my gut says this really shouldn't be something hug is doing.I have hazarded a guess at the general direction of a fix, but I admit elements of this are quite hacking and I'm almost positive this isn't the right approach. The fixes may be more appropriately applied to the
server()
method, but I tried to keep my own changes as surgical as possible and relegated to the test framework. We are currently using this code internally. I would welcome your feedback on this and can open a PR with a cleaned up solution if this is on the right track.Cheers!