Chris Angelico wrote:
> I'm still curious as to the workload (requests per second), as it might still
> be worth going for the feeder model. But if your current system works, then
> it may be simplest to debug that rather than change.
It is by all accounts a low-traffic situation, maybe one
On Sat, 26 Feb 2022 at 05:16, Robert Latest via Python-list
wrote:
>
> Chris Angelico wrote:
> > Depending on your database, this might be counter-productive. A
> > PostgreSQL database running on localhost, for instance, has its own
> > caching, and data transfers between two apps running on the
Greg Ewing wrote:
> * If more than one thread calls get_data() during the initial
> cache filling, it looks like only one of them will wait for
> the thread -- the others will skip waiting altogether and
> immediately return None.
Right. But that needs to be dealt with somehow. No data is no
Chris Angelico wrote:
> Depending on your database, this might be counter-productive. A
> PostgreSQL database running on localhost, for instance, has its own
> caching, and data transfers between two apps running on the same
> computer can be pretty fast. The complexity you add in order to do
>
On 25/02/22 1:08 am, Robert Latest wrote:
My question is: Is this a solid approach? Am I forgetting something?
I can see a few of problems:
* If more than one thread calls get_data() during the initial
cache filling, it looks like only one of them will wait for
the thread -- the others will
On Fri, 25 Feb 2022 at 06:54, Robert Latest via Python-list
wrote:
>
> I have a multi-threaded application (a web service) where several threads need
> data from an external database. That data is quite a lot, but it is almost
> always the same. Between incoming requests, timestamped records get
I have a multi-threaded application (a web service) where several threads need
data from an external database. That data is quite a lot, but it is almost
always the same. Between incoming requests, timestamped records get added to
the DB.
So I decided to keep an in-memory cache of the DB records
