Shape the future of IBM!
We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:
Post your ideas
IBM is transforming its request for enhancement (RFE) process. The purpose of the transformation is to provide a more consistent experience for you to submit requests and to enable IBM product owners to respond to your requests more quickly. For more information click here.
Start by posting ideas and requests to enhance a product or service. Take a look at ideas others have posted and upvote them if they matter to you,
1. Post an idea
2. Upvote ideas that matter most to you
3. Get feedback from the IBM team to refine your idea
Help IBM prioritize your ideas and requests
The IBM team may need your help to refine the ideas so they may ask for more information or feedback. The offering manager team will then decide if they can begin working on your idea. If they can start during the next development cycle, they will put the idea on the priority list. Each team at IBM works on a different schedule, where some ideas can be implemented right away, others may be placed on a different schedule.
Receive notifications on the decision
Some ideas can be implemented at IBM, while others may not fit within the development plans for the product. In either case, the team will let you know as soon as possible. In some cases, we may be able to find alternatives for ideas which cannot be implemented in a reasonable time.
Split the SEQ_YFS_TABLE_KEY sequence into potentially each table having its own sequence to use and remove performance bottleneck
SEQ_YFS_TABLE_KEY sequence provides a value for each new record created in the OMS universe. A simplest one-line order being created will insert at least 100 records into various OOB and custom tables. In the peak time when 2k orders being created every minute the next sequence value will be requested 200,000 per minute and this accounts for 3.3k next sequence value requests per second. On top of that there are various processes like payment collection, payment execution, sourcing, HD order scheduling, store and WMS systems, invoice creation and many others create new records at the same time.
|
What is your industry?
|
Retail
|
|
How will this idea be used?
It will remove bottleneck on using a single SEQ_YFS_TABLE_KEY
|
By clicking the "Post Comment" or "Submit Idea" button, you are agreeing to the IBM Ideas Portal Terms of Use.
Do not place IBM confidential, company confidential, or personal information into any field.
Guest
Hi Boris, I have been discussing the request with engineering and their feedback is that such an enhancement would not lead to meaningful performance gains. Engineering would like to get more details on the underlying issues you are facing that led to the request to split the sequence generation, so I will put you in contact with our performance lead to discuss further.
Hi Aaron, I like to know the progress on this request.
My performance team had another test recently and i have attached a fresh AWR
Thank you for providing the AWR Boris. I'm discussing with engineering and will get back to you as soon as I can.
Hi Aaron, Thanks for getting back to me. Here is the message from my performance engineer:
Attached is the AWS when we increased our cache from 50k to 1 million for the sequence and it did not make any difference.
Please add a note along with the AWR that “Cache helps reducing contention if there is any at disk level. The contention reported here seems to be happening at cache level and that is possible. Its not the cache size but it is the TPS which can be served by oracle from the cache. The load generated by all sterling agent is around 13k hits per second to this sequence (AWR attached) and even 13k seems to be even too high for cache to return fast. If we have multiple sequence, we can use multiple cache and that’s how we are expecting to reduce the contention”
I hope this helps.
I would appreciate if you expedite this issue as having this performance bottleneck puts our next holiday into a risk.
Let me know if you have more questions.
Thanks
Boris
Hello Boris, I have discussed this request with engineering. Their initial feedback is similar to what looks like where the PMR left off - they would expect that increasing the cache size should have provided meaningful improvement and wanted further data on why that did not provide improvement, which I do not see posted to the PMR.
We have not seen this as a common issue among our customers, so any data you can share to help illustrate the issue and why the suggested optimizations were not sufficient will help us prioritize this.