Hi Dick, The delays in my opinion aren’t the problem, so I agree there. The problems I see are: Visible end user facing errors. It’s a negative feedback loop where (some) users will continue to pound away because they think hitting refresh (or equivalent action) will “fix” the problem. Loss of trust that the data was actually uploaded if they experience errors or delays. That said, I’m a believer in “buy once, cry once” and while a robust system will cost us money, it will pay dividends in terms of user trust and reputation of our brand. 73 Ria N2RJ On Thu, Dec 3, 2020 at 2:08 PM Richard Norton via arrl-odv < arrl-odv@reflector.arrl.org> wrote:
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
_______________________________________________ arrl-odv mailing list arrl-odv@reflector.arrl.org https://reflector.arrl.org/mailman/listinfo/arrl-odv