<p>
But I didn’t ever say that. I tried to explain how complex security measures magnify the impact of server load, because you seemed to think that it was an either/or situation – and I’m saying that’s all part of the same issue. The simpler the web site, the more traffic it can handle. </p>
<p>
That makes sense – for the same reason that if there is a power outage in your neighborhood, it can be a problem if when power is restored, everybody’s appliances all go on at once. So visitors who are just poking around and looking are using up resources and making the experience slower for everybody. </p>
<p>It will be fixed. It’s not an unfixable problem. I think they need a queue and throttle system.</p>
<p>That is, first people would set up an account – the only thing that would happen with account set up is that they would create user name and password, and supply an email address. (That’s easy). </p>
<p>After that was done, when they were ready to apply for insurance, they would fill out a financial form (if they wanted a subsidy), and submit the data-- but they would NOT get an instant response. Instead, they would get a notice that their data was queued for submission, and perhaps a time estimate. They would log off. They could come back later and check to see the status of their application, and they would receive an automated email that would notify them when the status had changed. The system could also be programmed to send repeat notices daily until they did come back-- the nag system would help bring back people who were less motivated on their own to complete the process. </p>
<p>That would mean that people would be logging off the system more quickly, and the system would not be slowed down by the processing tasks. The queues would probably be long during peak hours, but then the system could catch up overnight. </p>
<p>Anyway, just my idea. Probably not particularly easy to build the architecture for that system on top of what they currently have, though I would say that it is really, really, easy to redirect traffic from an old server to a new one. So they could actually start from scratch, build and test a whole new system, and then simply make the “click here” buttons point to the new system when it was ready. If the web pages on the new system were designed to look like the old system, then users would never even know that there was a new backend – they’d just see that things were working a lot faster than before.</p>