[FRC Blog] Regional Registration Issues

[bdaroz]

Originally Posted by plnyyanks

There are also a couple of comparisons to TBA in the thread and I'd like to point out it's not an apt comparison to make in this case. TBA, as a system, has the benefit of an almost exclusively read-based workload and can do all writes asynchronously. TBA is cached very heavily, but that means latency of updates is scarified (that's why it's often a little out of date in the offseason). These assumptions would fail miserably in a registration environment, since you need up to the second information about event status (whereas a TBA page can be from anywhere between 1 minute and 1 day old).

The TBA caching I'm preferring to is more the memcache caching, and less the content cache (ala Cloudflare). Properly cached, event data is always served from the cache, and registration data is until it is changed and invalidated. For many of these pages (eg every dashboard page load once you register) this would reduce the number of DB calls dramatically, for a normalized schema.

Frank has stated they believe the issue to be with their MySQL database (sorry I can't find which blog of his said it recently) and it's responsiveness under load. Having worked w/ MySQL databases that serve far more simultaneous read/write requests, it's highly likely the problem lies between design, and cache. (Or a *really* poorly configured DB server)

[alectronic]

Originally Posted by bdaroz

I just want to throw an idea out for a second.... Just let me know where this falls on the spectrum of Great Idea <--> Bat #$% Crazy....

Why not open source TIMS/STIMS and the FMS Web Backend/API and let the teams hack* on it?

Maybe I'm missing something here, but what does the "FMS Web Backend/API" have to do with registration/the website?

[topgun]

I think they can do better.

Migrating the application to Amazon Web Services would be a start. AWS has the services in place to auto-scale and to auto-descale based on the load. So FIRST would pay when the scaling is needed, and not pay when the scaling is no longer needed. AWS is one example of several cloud services available.

Scale testing is easily doable, both from a software and a money standpoint. I was using JMeter years ago to do load testing on my websites. JMeter is still used, and I would bet several others are available as well (both commercial and opensource). It is not hard to do load testing.