Quote:
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)