Open that1guy opened 9 years ago
Just adding a little more info here.
Descriptions of each request from top to bottom.
1). GET all offers and questions associated with posting - https://production-posting-api.hashtagsell.com/v1/postings/0b6bb82b957a4accbf53aa343df47f53?postingId=0b6bb82b957a4accbf53aa343df47f53&questions=true&offers=true&count=100
2). GET all of a user's posts - https://production-posting-api.hashtagsell.com/v1/postings/?filters[mandatory][exact][username]=bradprodtest
3) DELETE a specific posting ID - https://production-posting-api.hashtagsell.com/v1/postings/0b6bb82b957a4accbf53aa343df47f53
4) GET all of a user's posts - https://production-posting-api.hashtagsell.com/v1/postings/?filters[mandatory][exact][username]=bradprodtest
Hi Josh, if you can get these requests using elasticsearch to get response times down I can handle everything else with buy/sell 360.
@that1guy - I've upgraded the MongoDB version and storage engine for the staging environment to 3.0 and wiredTiger (respectively). The wiredtiger storage engine supports a more granular level of locking at the document level (instead of collection) which should dramatically enhance read/write performance - it's quite new and wasn't readily available when we built the DBs, originally.
To do this, I had to take the staging environment down for a short period (it took approximately 1 hour). These changes are only in staging for the purposes of testing and verification... I believe this is the lowest hanging fruit for immediate performance enhancement.
Assigning to @that1guy to evaluate and see if this will work near term...
Interesting. Okay, I'll read up on 3.0 and do some performance testing tonight.
Hi Josh, this doesn't seem to be resolving the issue. Believe the problem is the slower queries need to go through ES. Let discuss in meeting.
1). GET all offers and questions associated with posting - NOT YET ADDRESSED
2). GET all of a user's posts - USE THE FOLLOWING RESOURCE - https://staging-posting-api.hashtagsell.com/v1/users/bradprodtest/postings
3) DELETE a specific posting ID - See updated documentation - delete returns immediately while actual removal occurs in the background for quick UI responses
Assigning to @that1guy for review
@brozeph I can confirm that number 2 & 3 from above are working much quicker.
Number one, as expected, is now our bottleneck. See screenshot.
All interactions with posting api are very slooww during while ingest agent is running. This occurs in staging env and posting env.