digirati-co-uk / dlcs-search-service

Search service for IIIF Content Search and annotation indexing.
MIT License
3 stars 0 forks source link

Performance: Spike #27

Open mattmcgrattan opened 6 years ago

mattmcgrattan commented 6 years ago

Questions to consider:

Notes:

https://www.techempower.com/benchmarks/#section=data-r17&hw=ph&test=fortune&l=zijzen-1 https://fgimian.github.io/blog/2018/05/17/choosing-a-fast-python-api-framework/

mattmcgrattan commented 6 years ago

FWIW, my own current assumption is that probably Cython is a stretch too far in terms of maintainability, and getting Python code where a high percentage of the code is rendered as native C by cythonize is tricky. Often it's a mix of C and Python, which works fine, but you lose some of the speed advantages of native compilation.

Testing with CPython 3.x and PyPy from the start would be pretty useful, though. PyPy's JIT compiler is really pretty good, and generally "just works" with most standard Python code and libraries.

mattmcgrattan commented 6 years ago

We also haven't set yet what we consider adequate performance, in terms of response time, number of concurrent requests, etc.

stephenwf commented 5 years ago

Also related:

Although the last point may be its own ticket

john-root commented 5 years ago

The advantages of Flask include: currently widely adopted within the DLCS (commonality, consistency) commonly used so more likely that a given Python developer has experience many available modules for common requirements

(Django also meets all the above too, though I wouldn't personally want to use it for this)

john-root commented 5 years ago

Testing with CPython 3.x and PyPy from the start would be pretty useful, though. PyPy's JIT compiler is really pretty good, and generally "just works" with most standard Python code and libraries.

I think this makes sense and having it working with PyPy seems a realistic and useful goal