Two hundred and fifty percent. Yes, folks, it was Perl.

You have probably seen a résumé number that sounds like somebody personally taught a computer to run faster. Mine is "increased mediation throughput 250%." Sounds pretty damned clever.

I moved files around with Perl[1]Ref. 1Perl perl.org. There was more to it than that, and I am proud of the result, but that is what it was.

The chain fell behind on Monday mornings and caught up on Wednesday. That is a looooong time to wait for Monday to finish.

I wanted more chains. Give me five of the damned things. Except a call has a beginning and an end, and I had to keep those in order.

Records for one call could span files. Long calls generated intermediate records; a call starting at 23:58 and ending at 00:03 showed up in two files with different sequence numbers.

Order mattered per switch, then per file sequence within that switch. A record from the Kansas City[2]Ref. 2Kansas City en.wikipedia.org DMS[3]Ref. 3DMS en.wikipedia.org had no relationship to one from the Fort Worth 5ESS[4]Ref. 45ESS en.wikipedia.org. I was making one wait for the other for no good reason.

We spread files from 130 switches across five chains. Round-robin at the switch level, strict sequence within each switch.

Perl handled distribution. A small Oracle[5]Ref. 5Oracle oracle.com table mapped switches to chains, kept the assignments through restarts, and let us rebalance with an UPDATE instead of changing code.

Throughput came out about 3.5x the old single chain, on the same class of hardware. That is the 250%.

We got there by changing which files had to wait for each other. Monday finished on Monday.