Matching turnaround performance

Support
, ,
1

What Wildbook are you working in?ACW

What is the entire URL out of the browser, exactly where the error occurred?

Can you describe what the issue is you’re experiencing?

Turnaround for ID was 59 mins

ID turnaround time
ID turnaround time1903×880 57.8 KB

Now at 18 mins

Matching turnaround - 18 mins
Matching turnaround - 18 mins1903×937 68.9 KB

Can this be improved?

Thanks
Paul

CC @ACWadmin1
@jason

2

Hi @PaulK

Do you mean can the turnaround time itself be improved? It is a reflection of the time per job and the time it takes to work through the queue to get to each job. This new estimate i an attempt to help users understand how busy the ML server is right now and how long they might need to wait to begin to expect to see results. How would you see this improved?

Thanks,
Jason

3

Hi Jason

I think providing this information is a good thing - so no change.

Question is - Can performance be improved? Processing 200 or more media assets at a time is now normal for us and if it is taking 59 minute… or even 18 minutes per encounter to find and present match results then that is many days of processing before the overall import job is complete and all proposed matches are available for review.

The other issue that I may be seeing is sluggish performance elsewhere on system (working on other jobs) while this is going on - causing hiccups like what I have just posted re Matching workflow inconsistencies.

Thanks

Paul

4

Hi @PaulK

ACW’s instance of WBIA is on a physical server in our data center cabinet with access to four GPUs on the machine (though WBIA only takes advantage of one). It has a fair amount of power behind it, and WBIA runs on a different server than Wildbook entirely. That said, bulk import absolutely does a lot of work on both sides.

The next major step up in performance would be load balancing with multiple WBIA servers able to handle increased workloads, which we do plan on working on. That work has been recently funded, but it is currently scheduled.

One thing to keep in mind with the time estimate: it is a reflection of past work only and doesn’t make a prediction. The last job may have taken 18 minutes to turnaround, but if the queue is empty, it may not take 18 minutes for a new job. Currently, the time estimate is noting that the turaround time is about 15 minutes, but in fact there is nothing in the queue, so a single ID job is likely to complete much, much faster than that. I’ll look to see if we can age out our better qualify that estimate when the queue becomes empty and the estimate no longer applies.

Thanks,
Jason

5

We already had a ticket for this too: WB-1943