- Thu Jan 13, 2011 12:52 pm
#117342
I elected to take the earned credit because I had a feeling the servers would just not be up to the load. As it turns out, I was right, as it took numerous tries just to log in, get to the page with the button and then many more tries to get the button to register my selection. But, as I do web system programming for a living and I've spent considerable time dealing with high traffic issues, I wanted to offer some observations that might be useful for next year.
First, while I had a hard time connecting, when a request did connect, the response from the server came back very quickly. This tells me that bandwidth to/from the server was probably not an issue. Most of the time, the error was a timeout of some sort. I saw both connection timeouts and what looked like server request overload issues (the funny little "something happened, here's an error code" responses I'm sure many people saw.
Based on what I saw, my suspicion is that the problem this time was more related to connection and request resource starvation than with bandwidth, or server CPU capacity. Both of these things are generally tunable parameters in most HTTP servers, but the default, out of the box settings are usually very low. I'm not familiar with SparkFun's software configuration so I can't make specific recommendations but, typically, inbound connection requests are limited by the number of threads set aside to process them. There are similar issues with incoming connections that relate to the amount of RAM buffer space set aside to manage each connection.
Of course, I could be off base here and perhaps the web staff at SparkFun had already configured all these setting the max possible values. But, in my experience, I've found that it can be fiendishly complex to get this right, as there are numerous interdependencies that have to be balanced out, such as deciding how to budget available RAM (for threads, or for connection buffering?) So, before any of you jump on the poor admins at SparkFun, just realize that what they're trying to pull of with free day is not something I'd relish trying to do.
Wayne
First, while I had a hard time connecting, when a request did connect, the response from the server came back very quickly. This tells me that bandwidth to/from the server was probably not an issue. Most of the time, the error was a timeout of some sort. I saw both connection timeouts and what looked like server request overload issues (the funny little "something happened, here's an error code" responses I'm sure many people saw.
Based on what I saw, my suspicion is that the problem this time was more related to connection and request resource starvation than with bandwidth, or server CPU capacity. Both of these things are generally tunable parameters in most HTTP servers, but the default, out of the box settings are usually very low. I'm not familiar with SparkFun's software configuration so I can't make specific recommendations but, typically, inbound connection requests are limited by the number of threads set aside to process them. There are similar issues with incoming connections that relate to the amount of RAM buffer space set aside to manage each connection.
Of course, I could be off base here and perhaps the web staff at SparkFun had already configured all these setting the max possible values. But, in my experience, I've found that it can be fiendishly complex to get this right, as there are numerous interdependencies that have to be balanced out, such as deciding how to budget available RAM (for threads, or for connection buffering?) So, before any of you jump on the poor admins at SparkFun, just realize that what they're trying to pull of with free day is not something I'd relish trying to do.
Wayne