|
DMI News |
Previous Entry.. Next Entry.. Various Things
September 12, 2002 11:35 The hits continue. I've fallen off the front page of bluesnews.com, so most of the hits from that site have fallen off, but the residual sites still remain, and I expect a huge swarm of hits tonight when TechTV does a feature on this site. On the 10th, I had over 8500 hits total, and that was right about the point of saturation. However, it wasn't a bandwidth issue so much as an internal issue. I have ineffiency in my controlling structure. Problems that don't show up when I get only 1000 hits a day are major issues when I get 8K/day. The primary problem rests with the doorbell server, which does all the appliance controlling. That program is a simple tcp/ip server loop that accepts a connection, processes it, and closes the connection. This works well for light loads, but when its getting hammered 10-20 times per second, especially when some of the commands take over a second to process, problems develop, mostly when it segfaults on a connect. I'm therefore taking a number of precautions to prevent this problem. First off, about 90% of the requests to the server aren't for an appliance action, but to update or obtain the current insanity level, or to obtain the current lamp status. The insanity level is requested on every page load. I've fixed this so it gets requested once per minute, then updates a local file on the webserver for the page to display. In addition, lamp requests can determine the current state before they do any hardware activity, and simply ignore the request if the lamp is already in the desired state. X10 commands take 1 second to process. The server also needs to be multithreaded. Allow the main thread to handle the connection, and spawn a thread to handle the request. This way, 1 second actions will not hold up the server from handling other requests. In addition, any incoming requests could be compared to the current request queue and simply ignore any duplicate requests. Placing requests in a queue and having a thread handle the requests one at a time is also an option, for those requests that don't require a return value. However, right now, turning on lamp requires two connections, one to turn the lamp on, and another to get the new state. This could easily be handled in the same connection.
|