Chief Delphi - [FRC Blog] Regional Registration Issues

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)

- General Forum (http://www.chiefdelphi.com/forums/forumdisplay.php?f=16)

- - [FRC Blog] Regional Registration Issues (http://www.chiefdelphi.com/forums/showthread.php?t=151762)

Re: [FRC Blog] Regional Registration Issues

Quote:

Originally Posted by JesseK (Post 1610866)

Meh. Sure, there's more they could have done. Here's the thing about "software", coming from someone who's done "it" and only "it" for 14 years professionally.

snip

I can't agree more with this post. It reminds me of a good article I saw last week about the idea of "<thing> is nowhere near that hard, I could do it myself!": http://danluu.com/sounds-easy/

Scalability problems also are rarely solved by throwing more resources at it. In fact, often, application performance can often decreases when more cores are added due to the increased need for synchronization and hammering of shared cache lines in a write heavy workload (plus added network latency in distributed systems). There is a huge amount of coordination required to make sure the database status stays in sync across all the machines involved. If people are interested, PM me and I can link you to some papers on the subject. These kinds of challenges take lots of time and engineering effort and like Peter said above, FIRST has limited engineering resources available (including writing all the software for next year's game).

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).

At the end of the day, FIRST just realized they have to iterate their system. They employ engineers just like the rest of us who work incredibly hard to build and maintain their tools. Sure, not everything will work 100% of the time, but that's why we iterate and make things better. And it seems like a priority-based approach will make the entire process a lot less stressful for everyone involved.

Re: [FRC Blog] Regional Registration Issues

Quote:

Originally Posted by plnyyanks (Post 1610891)

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)

Re: [FRC Blog] Regional Registration Issues

Quote:

Originally Posted by waialua359 (Post 1610814)

Sorry FIRST, but I'm with weberr here. We really need the old website back. I cant imagine what its like for new teams, when I at least know what I am looking for by my previous experiences using the site.

The best registration system was the one that had all of the events listed on one set of pages (iirc). 2 categories in boxes. Event capacity, no. of slots left. The box was color coded. It turned a certain color once no. of slots left became low or another color when event was full.
In a snapshot, you could see all the information you needed without having to navigate endlessly just to find out 1 piece of information.
You could click on links to see who was registered for the event and not have to use the search bar everytime you needed to find something.

I agree with Glenn and weberr, having been around for a long time, I found the flaws with the old website something I could work around. The layout for the new one is not user friendly for FIRST teams. I tried for 30 minutes the other day to find the "What is FIRST" video ... I could only find it in Spanish. I ended up going to You Tube to find it. It is a great video and it should be EASY to find on the website.

We will continue to send in our comments regarding website use. I feel that perhaps the website was designed more for people learning about FIRST than the FIRST community itself.