As you might probably already know, python3 is a single threaded, mono processor program, this seems to goes well with tinydb (json) that state being only made of full python, as well as bottle (web server).
In a world where you want to have something in pre-production or early production and low traffic (<100 ppl a week) what do you think of the idea of having a running bottle website with the built-in HTTP server (python) and tinydb as a database.
The two things I was wondering was :
a) data isolation (or concurrency) : but since everything is single threaded the processor will do the job of queuing the CRUD operations, one after the other, there won't be any concurrent access but regarding the low traffic, should I care ?
b) wait time, while the processor is queuing 10 ppl that wants to have access to the same table stored in ram, the processor will queue the requests and people will have wait time. Now the question being will this be humanly noticeable, Python being fast (milisec). However I don't really know how to stat test 50 ppl connecting to the website at the same time and requesting for the same ressources.
I am open to every feedback, let me know.
if you are going to have such a low traffic + very fast RAM only operations then it seems like it might be worthy option and also easily testable.
import bottle
a = bottle.Bottle()
@a.get('/')
def root():
return {'cheese': '🧀'}
if __name__ == '__main__':
a.run()
and our test_file:
import time
import requests
from concurrent.futures import ThreadPoolExecutor
def test(index):
requests.get('http://localhost:8080/').raise_for_status()
pool = ThreadPoolExecutor(max_workers=10)
for i in (1, 10, 50, 100, 1000):
t = time.time()
pool.map(test, range(i))
print(i, 'took', time.time() - t)
print('🥳')
on my Mac this the output:
1 took 0.00046515464782714844
10 took 0.003888845443725586
50 took 0.0003077983856201172
100 took 0.0006000995635986328
1000 took 0.0058138370513916016
🥳
which is indeed, not noticeable. that said, every IO/CPU/presistancy thing that will be added later will break your assumptions, so with the price of a small overhead it might be better to use a bigger concurrent DB and such. 😀