Great feedback Dick. You bring up one of my long time bugaboos: I believe that ALL log submissions should be submitted directly into LoTW once accepted for credit in a contest. I’d love to speak with your member. The notion to move into the cloud and utilizing variable horsepower (AWS or whatever) is exactly what we are thinking. Please shoot me an email. Thanks! David From: arrl-odv <arrl-odv-bounces@reflector.arrl.org> On Behalf Of Richard Norton via arrl-odv Sent: Thursday, December 3, 2020 2:08 PM To: arrl-odv <arrl-odv@arrl.org> Subject: [arrl-odv:31433] LOTW Delays After CQWW CW Asked a number of my contesting friends about the LOTW delays after CQWW CW. None of them are upset about it. The delay is not unexpected. One comment was that it isn't unusual for there to be longer lines at the post office in mid-December. A suggestion was to notify users, and possibly ask them to space out their submissions. If LOTW can be improved for very little money, that would certainly be good. There is no need to invest significant funds to fix something that happens a couple times a year. If money is to be put into LOTW, I would hope it would result in some benefit to users, such as only needing a single log upload for contests, rather than the present two uploads, one for the contest and one for LOTW. Note also that one friend works in a closely related field, and sent the following: 1) As long as the LoTW system doesn't crumple on itself under load, I see these delays as "a good problem to have" because they show high usage, which means LoTW is successful (duh). CQWW is probably the only time of year when the system is really taxed, though there may be other windows when it is as well. It seems that this delay issue has been a problem for years, and unless there are heroics I don't know about to keep the system running during and after these events, I'm not sure it needs a solution currently. 2) I don't know how the system is architected today, or where it lives, but I know how I would design it to run on AWS. A lot of the "getting from here to there" would depend on how it's designed today. This is an ideal application for auto-scaling, as others have observed. AWS can do auto-scaling on a schedule or based on load. Either would work in this case, as long as LoTW is not running on Windows (too slow to scale). If it is on Windows (shudder), then scheduled scaling would be better. Moving the parts to AWS and implementing auto-scaling requires that the servers are stateless (don't store any state information on the servers--only in the database), and that is often not the case for old designs. I would be happy to have a design discussion with anyone who might be interested. This is the type of thing I do as part of my job as a solutions architect at AWS. I don't know who runs IT (and/or LoTW) at HQ, or on behalf of ARRL, but I'd be happy to be part of the solution if one is deemed necessary. If anyone connected with staff is interested, I'll be happy to connect him with you. He has a strong connection to ARRL, before anyone on this reflector was involved with ARRL management or direction. LOTW delays are not a critical problem. 73, Dick, N6AA