|
|
Post by chris on Oct 12, 2015 13:08:27 GMT
Edit: It's also actually quite slow to compute. You can see that in the roughly two second load time it takes to fully resolve the queue positions. Perhaps it would be a bit quicker if adjacent queue entries from the same customer didn't take up multiple queue slots? Right now, I've got every single queue position from 4989 to 5021 as the result of a single sale of loan units that occurred within a single second... apparently the MLIA needs to enqueue the funds within the same nanosecond that the sale occurs, rather than noting the total value of all simultaneous sales and combining this into a single record giving the funds queued. On the plus side, if you optimise these kind of things, at least you've already done the stress test for how the system can perform when AC has an order of magnitude more customers! There's a bigger problem with recursive locks that slows the queue resolution down that upping the limit has highlighted for me. I've thought about joining adjacent queue positions, it would make it slower at write time to do the additional checking and would introduce a potential race condition, but it would allow a small increase in read performance. I'll benchmark it but I think the performance benefit is small overall so it's not a priority to improve, perhaps if I do look at it we'll just run a merge once per hour or something.
|
|
|
|
Post by andrewholgate on Oct 12, 2015 14:23:38 GMT
Well thats bl***y annoying. No warning, several days earlier than even their most optimistic estimates.  Your self-control is truly admirable. One is more than just a tad miffed! *%!?*<$  My initial reaction on finding my MLIA void of 'readies' was that my internet connection was stuttering and the page was only partially displayed. No, a refresh, produced the same result. In that case it must be an AC platform malfunction. But I'd been perusing loan details only seconds previously, hadn't I? Well, It can't possilbly be a loan going 'live', can it? I'd checked specifically only a couple of hours before. To see loan drawdowns retreating like vampires fleeing the rising sun is truly irritating, but we understand there can be reasons beyond AC's control. In my current mood I will feel it would not go amiss if we received an explanation from chris, andrewholgate, anyone, as to why no warning can be given if estimates move the other way! End of rant Edit: Now, if there had been room in the QAA....... Further edit: Or if we were able to ringfence cash in the MLIA...... Mea culpa. Poor comms again. Typical though...we get a complaint for beating a target date rather than MISSING it. I can't win!
|
|
sl75
Posts: 2,092 
Likes: 1,245
|
Post by sl75 on Oct 12, 2015 14:51:12 GMT
There's a bigger problem with recursive locks that slows the queue resolution down that upping the limit has highlighted for me. I've thought about joining adjacent queue positions, it would make it slower at write time to do the additional checking and would introduce a potential race condition, but it would allow a small increase in read performance. I'll benchmark it but I think the performance benefit is small overall so it's not a priority to improve, perhaps if I do look at it we'll just run a merge once per hour or something. Rather than joining adjacent queue positions, wouldn't it be better not to create them in the first place? The system is performing a potentially large number of sales and purchases as a batch, all of which are effectively treated as "simultaneous". Rather than creating a queue entry for the proceeds of each individual sale, it need only note that lenders X, Y and Z need to have funds enqueued, and perform all the enqueuing operations at the end of the batch. Further, given that it can often be the case that one sale triggers another purchase, etc. the system could further defer enqueuing the funds until all possible sales and purchases have been processed. In some cases the proceeds of the sale will be immediately re-invested in another loan, so that lender's funds need never enter the queue in the first place. In other more common cases, such as the example I highlighted above, sales triggered by a single lender selling off a chunk of a popular loan will result in only a single queue entry rather than potentially dozens or even hundreds.
|
|
SteveT
Member of DD Central
Posts: 6,875
Likes: 7,924
|
Post by SteveT on Oct 12, 2015 14:55:09 GMT
Mea culpa. Poor comms again. Typical though...we get a complaint for beating a target date rather than MISSING it. I can't win! Not so much "beating" it as missing it but in the other direction 
|
|
|
|
Post by chris on Oct 12, 2015 14:58:50 GMT
Rather than joining adjacent queue positions, wouldn't it be better not to create them in the first place? The system is performing a potentially large number of sales and purchases as a batch, all of which are effectively treated as "simultaneous". Rather than creating a queue entry for the proceeds of each individual sale, it need only not that lenders X, Y and Z need to have funds enqueued, and perform all the enqueuing operations at the end of the batch. Further, given that it can often be the case that one sale triggers another purchase, etc. the system could further defer enqueuing the funds until all possible sales and purchases have been processed. In some cases the proceeds of the sale will be immediately re-invested in another loan, so that lender's funds need never enter the queue in the first place. In other more common cases, such as the example I highlighted above, sales triggered by a single lender selling off a chunk of a popular loan will result in only a single queue entry rather than potentially dozens or even hundreds. The code runs much lower down than that, at the virtual banking system level, so we can't do that logical grouping. They're treated as separate transactions not simultaneous. So to group them would mean another select to look up what's already in the queue and the race condition and locking conflict that can create.
|
|
|
|
Post by pepperpot on Oct 12, 2015 15:15:18 GMT
Mea culpa. Poor comms again. Typical though...we get a complaint for beating a target date rather than MISSING it. I can't win! Not so much "beating" it as missing it but in the other direction Unfortunately I have to agree. If I free up a day to sit around waiting for a parcel to be delivered, it's just as annoying to find out that they rang the bell the day before than if it'd been put back till tomorrows delivery round. Possibly more so, but at least I can re-arrange delivery in that instance...
|
|
|
|
Post by Deleted on Oct 12, 2015 16:10:00 GMT
I think we should thank Andrew for beating a time target.
In time I'm sure things will get tighter as AC gets more controlled.
|
|
|
|
Post by andrewholgate on Oct 13, 2015 8:02:54 GMT
I think we should thank Andrew for beating a time target. In time I'm sure things will get tighter as AC gets more controlled. Thanks, I've had words that we should give investors notice if we are drawing early. I'll get back to the 75 Hail Mary's and the 4 hours of flagellation with brambles.
|
|
ianj
Member of DD Central
Posts: 656
Likes: 520
|
Post by ianj on Oct 13, 2015 8:06:20 GMT
Mea culpa. Poor comms again. Typical though...we get a complaint for beating a target date rather than MISSING it. I can't win! Its only good news if you're ready! I was once informed by a BA captain that a pilot could have his ‘wrists slapped’, and there might be financial consequences for an airline, if a flight arrives too far ahead of schedule. The airport does at least receive warning of an early approach and makes the necessary adjustments! We all need our expectations to be managed appropriately. Edit: Crossed with the previous post. Thank you, andrewholgate, much appreciated.
|
|
|
|
Post by Ton ⓉⓞⓃ on Oct 13, 2015 8:34:05 GMT
I think we should thank Andrew for beating a time target. In time I'm sure things will get tighter as AC gets more controlled. Thanks, I've had words that we should give investors notice if we are drawing early. I'll get back to the 75 Hail Mary's and the 4 hours of flagellation with brambles. What you do in your private life is no concern of ours.
|
|
unmadem
Member of DD Central
Posts: 377
Likes: 181
|
Post by unmadem on Oct 13, 2015 8:55:18 GMT
191 Scottish pub moved back from 14th to 30th oct.
|
|
star dust
Member of DD Central
Posts: 2,998
Likes: 3,531
|
Post by star dust on Oct 13, 2015 9:29:17 GMT
191 Scottish pub moved back from 14th to 30th oct. Ooh, so glad I removed my 'readies' (and haven't replaced them) after the previous delayed drawdown. Bet the underwriters are a bit annoyed.
|
|
tonyr
Member of DD Central
Posts: 477
Likes: 258
|
Post by tonyr on Oct 13, 2015 10:23:28 GMT
191 Scottish pub moved back from 14th to 30th oct. Ooh, so glad I removed my 'readies' (and haven't replaced them) after the previous delayed drawdown. Bet the underwriters are a bit annoyed. The underwriters are bored - there's nothing to do.
|
|
bigfoot12
Member of DD Central
Posts: 1,817
Likes: 816
|
Post by bigfoot12 on Oct 13, 2015 10:49:51 GMT
... we should give investors notice if we are drawing early. I'd encourage AC to drawdown as soon as possible always.  I agree with paul123, please don't delay a drawdown in order to give notice.
|
|
SteveT
Member of DD Central
Posts: 6,875
Likes: 7,924
|
Post by SteveT on Oct 13, 2015 11:15:31 GMT
... we should give investors notice if we are drawing early. I'd encourage AC to drawdown as soon as possible always. I agree with paul123, please don't delay a drawdown in order to give notice. Even an email on the day and a post on here would give lenders a few hours notice to transfer some money. No-one's asking for anything to be delayed, just told with some degree of accuracy what is going on.
|
|
