* perf: No need to set expiry for key everytime
* fix: Set expiry on first request and never again
This prevents problem of rate limiter keys growing constantly.
Call it a new year's resolution.
`frappe/__init__.py` has grown crazy big over time and left unattended it will continue to grow.
This new ~test~ tax will require reducing 3 line per day (so ~1000 in a year) from 1st Jan 2025 onwards. I am offering a headstart of 50 days in this PR by moving ~150 lines: #28869
This is middle ground between caching it completely and requiring a
restart/signal to reload vs always reloading it.
I don't know any use cases that can break from this, nowhere in code
configs should be expected to reload instantly.
This change is only applied to requests for now
* perf: reuse current time
now_datetime is site-tz-aware, we don't need it here.
* perf: dont need redis transactions
* perf: use `time.time()` instead of datetime
Using `datetime.timestamp()` is a round-about way to use `time.time()`
with extra cost of dealing with datetime and timezones.
* perf: define slots for rate_limiter
* fix!: Remove used rate limit header
This just shares how much was consumed in current request, people can
just time requests to get an approximation for this, not sure why is this
useful.
* chore: remove verbose output from test runner
This is same output that's shared by test runner in different format?
This makes it annoying to scroll through when just running single test
locally.
* fix: Remove clutter from test output
Test records don't change after first run.
Tests are executed many many times locally
* test: retry flaky postgres backup tests
Python's multithreaded model is _inefficient_ because of Global
Interpreter Lock (GIL). Any one thread of process can run at any given
time. Thus only valid use case for threads in Python are:
1. Hiding I/O latency by switching to a different thread.
2. Using compiled extensions that yield GIL for long enough time to do
meaningful work in other threads.
Both of these are not as frequent as you'd imagine and gthread worker
with multiple threads often just end up contending on lock and waste
useful CPU cycles doing nothing. Pinning worker process to a core nearly
eliminates this contention wastage. This waste can be 5-10% and goes up
sharply with more threads.
E.g. FC typically has maxed out config of 24 workers which allows
"accepting" and working on 24 requests at a time. But that doesn't mean
24 requests are on CPU at any given time, that would require 24 physical
cores.
Why do this?
1. Context switching in threads is faster than switching process - fewer
cache misses, fewer TLB misses etc.
2. The model is simple
True parallelism = count(cores) = count(processes).
Expected concurrency = count(processes) * count(threads).
3. This is far simpler to reason about than something like async
executor model.
4. Ability to queue more requests than what can be handled is already
implemented by `bind(2)` and `accept(2)` in kernel. There is no real
benefit of accepting 1000 requests if you can only work on 20 of them
at a time. This is because we do a lot of "work" in requests, it's
not just issuing an external request and waiting for it.
5. We can achieve practically same concurrency as 24 workers with 4
process x 6 threads. That's a lot of memory saved to run other useful
things.
Caveats:
- This kind of pinning can potentially make Linux scheduler inefficient.
I don't quite think it's going to be a big problem because there are
plenty of other things to run which a core can steal from other core
if it doesn't have enough work.
- Load balancing in single-server multi-bench setup. I *think* by nature
of how `accept(2)` works, load balancing will still happen pretty much
automatically. If certain core is overloaded, naturally other cores
will reach `accept(2)` more frequently and take the load off of that
core. This is something worth validating in practice by creating
skewed affinities.
- This code is not NUMA-aware. None of our machines have NUMA nodes so,
I am ignoring it. Don't use it if you have a NUMA setup.
- If new CPUs are hotplugged or existing ones are disabled then it can
be inefficient (worse than current) until that worker auto-restarts (which
happens after N requests in FC setup).
Ideal solution: We write userspace scheduler to implement
"soft-affinity" using Linux's new eBPF based sched_ext feature. That's
too much extra work but I'll consider this too at some point.
closes https://github.com/frappe/caffeine/issues/13
* chore(typing): type filters
* chore(typing): type filters for get_list et al
* fix: dashboard chart filter expression
* test: fix case with new-style right hand object to equality check
* chore: place new typed filter under typing verification
* chore: remove debug print statment
* chore: inverse logic of type guard
* fix: add float to filter value types
* chore: clarify value naming
* fix: Apply read_only_method decorator to Document methods
* fix: update tests for read-only document context manager
* refactor: place mappers into read-only mode
Reapply "refactor: place mappers into read-only mode"
This reverts commit a8208d57069c63f0982bf2881bcad28a4b349f3c.
read-only mode is now thread safe
* chore: feedback doctype no longer exists
missed from https://github.com/frappe/frappe/pull/17479
* chore: remove unused communication type
This was removed and migrated already in v12:
```
frappe/patches/v12_0/setup_comments_from_communications.py: frappe.db.delete("Communication", {"communication_type": "Comment"})
```
... comming from 41d90fa6d1
which effectively reverted 465318878e
due to circular imports issues and me going out of my way to make it work 'cleanly', the previous backwards compatibility for FrappeTestCase unfortunately did not work on the manual cli test runner 'run-tests'
While not generally not affecting CI (which is precedented by the framwork's best practices to use 'run-parallel-test'), this broke some manual developer workflows
The restauration of FrappeTestCase in these scenario now unfortunately involves a plain copy of almost an entire implementation into the dumpster.
On the one hand, this doesn not accurately reflect the rather minuscule differences between IntegrationTestCase and FrappeTestCase, but on the other hand, it shields and freezes the old api should IntegrationTestCase evolve futher
Because of large common prefix hash naming becomes "too sequential" when
doing a lot of concurrent writes.
I don't know a good tradeoff between both use cases:
1. Lots of reads - prefers large shared prefix.
2. Lots of writes - prefers small shared prefix.
But as of now this punishes writes too badly in form of excessive
locking. Until a better fix is found, it's better to keep it prefix free.
---
A better fix would be a tradeoff of between these two:
1. Reads - temporal locality should result in spatial locality on disk.
2. Writes - temporal locality should NOT result in spatial locality.
temporal locality = data inserted around same time
spatial locality = data sits next to each other in DB pages.
This can be achieved by adding a small request/job specific part to
prefix so each concurrent request has it's own different locality when
writing data.
