Ron,
We've been doing some thinking about things that will help optimize the auction clock, especially at the end of auctions, and wanted to run some stuff by you. Because all client browsers and computers are different, we need a way to make sure that all clients are keeping the correct time based on the server. To achieve this, we have historically been sending down a message from the server to all clients with the current time on the server.
A few problems have occurred with this approach. One is that, since we moved you from a custom web sockets implementation to Pusher, you are now being charged based on the number of messages sent to the clients. This means that our messages to each connected client will add up very quickly, and we want to avoid that for you. The second problem is that the constant pusshing of information can be a drain on resources for the server, especially when it is unnecessary for the auction to be updating so frequently when the auction is weeks, days, even hours, away from expiring. The client clocks do not need to be so precise during these times.
To address both of these problems, we recommend taking the following actions:
Remove the web socket approach to keeping the auction time up to date.
Instead of the server pushing auction clock data down to the client, favor a "polling" approach, where the client asks the server for its time as a solicited request. This will remove the web socket messages to keep the clients up-to-date with the server clock, and thus remove all associated costs, while still achieving the same functionality.
Prescribe a polling schedule for different "phases" of the countdown clock for a given auction.
We recommend changing the frequency at which the client asks the server for the correct time based on how critical it is that the client clock is perfectly synchronized with the sever. The schedule we propose is as follows:
- From the time the auction opens to 1 day left: Every minute
- 1 day left - 1 hour left: Every 30 seconds
- 1 Hour left - clock reset threshold: Every 10 seconds
The "threshold" is the maximum time until expiration in which a bid will reset the clock back to the threshold time. This is almost always 10 seconds, but is configurable.
We don't plan on polling the server during the threshold period, since the server will be sending down notifications for the client clocks to reset to the threshold time, and we don't forsee an opportunity for significant separation between clients within a 10 second period.
These two steps should alleviate the clock disparities between clients that we experienced with the first auction. We want to get your feedback on this before we implement any of these refactorings, and also wanted to field any questions you might have on the implementations.