Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

threading #5

Open
elcolumbio opened this issue Jun 5, 2018 · 8 comments
Open

threading #5

elcolumbio opened this issue Jun 5, 2018 · 8 comments

Comments

@elcolumbio
Copy link
Owner

This is my first time using threading.
So lot's of space to improve.

I try to set up what seems plausible for me.

@elcolumbio
Copy link
Owner Author

Also concurrency with asynco sounds very interesting.
It's a really interesting new problem field to tackle.

@Bobspadger
Copy link

I've got something like this working in production now, I have 4000+ products using this. I have not seen a need for threading / async yet. You may just over-complicate the system needlessly.

@elcolumbio
Copy link
Owner Author

Yeah i don't know what i am doing yet :).

I just found out it's quite convenient to use threads from a jupyter notebook.
You don't block your notebook.
That's the only use case right now.
Later i can maybe use it to monitor threads.

I also don't plan to do parallelism ever.

Right now it's 5 lines of boilerplate you can ignore and call direct the function.

@elcolumbio
Copy link
Owner Author

elcolumbio commented Jun 18, 2018

@Bobspadger Are you allowed to share code?

I still miss the complete price updating part for example.

@Bobspadger
Copy link

I'm not sure - it drives our Amazon strategy so don't know how much of it I can share.

The overview is really that we wait for an SQS message , analyse the contents, and decide to either raise or lower our price based on if we have the buy box.

My products team set min / max prices for a product, then I operate within those windows to get the buy box.

@Bobspadger
Copy link

What I'd be doing (and its kind of how I have it running at present) is I have a redis db of unique ID's actioned, to make sure we've not already processed the message, and one of SKU codes and last actions to make sure we're not acting on an older message.

The SQS message can be out of order and duplicated so the Redis system works really well.

Then, If I needed more throughput, I'd just start another instance of the app, as the safeguards in the redis db stop me from processing duplicate or old messages

@elcolumbio
Copy link
Owner Author

Thank you. Will look into redis 5.0 right away.
I tried to store everything i get from the amazon apis in sql. But they use NoSQL themselves?

It's ok i appreciate your comments. Personally i believe a good strategy is to contribute and leverage the open source stack as strong foundation. Pricing is a commodity, the marketplaces offer for free.

@elcolumbio
Copy link
Owner Author

elcolumbio commented Jun 21, 2018

I have found what i think is a good redis structure?
Sorted sets for each asin.

zadd asin1 1 message
zadd asin2 2 message
zadd aisn3 3 message

where the format is
key: asin
score: timestamp
value: message

then i can do this:
r.zrevrangebyscore('asin1', "inf", "-inf", start=0, num=1)
one guy said it's fast: "It's O(log(N)), so for 1 billion entries it's about 20 comparisons"

you store the message in xml format or parse it first?

If i dont want to parse every asin i need a set where i put in names of asins.
And a worker can pop the set.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants