Hiawatha 7.0 and beyond</h1> <article> <h1>Hiawatha 7.0 and beyond</h1> <p>Sun, 14 Feb 2010 08:10:23 +0100</p> <p>Hiawatha 7.0 has been released! With this version, can you monitor multiple instances of the webserver from a central place. This makes Hiawatha more suitable for large scale deployments and enterprise solutions.</p> <p>There are two features, for which I often recieve a request, which I would like to discuss with you. One is on-the-fly-gzip content encoding and the other is Server Name Indication, which makes it possible to use multiple SSL certificates on one binding.</p> <ul> <li> <p>First, on-the-fly gzip content encoding. The main problem with this one is that it requires Hiawatha to completly buffer the output of a HTTP request. Buffering the output in memory will cause memory problems for busy websites with large files or CGI's that generate large output. Buffering the output to disk will make it significantly slower. For me, both options are unacceptable.</p> <p>Most users of Hiawatha, including me, use PHP. PHP has support for automaticly gzipping the output. Images are hard to compress and CSS files are mostly small and therefor not much is gained by compress those. For all these reasons, I have decided not to implement on-the-fly gzip content encoding support.</p> </li> <li> <p>Second is Server Name Indication, or SNI. I really would like to implement this one, but the OpenSSL documentation is incomplete and horrible. I've tried to understand how SNI works in OpenSSL, but weren't able to figure it out. If any OpenSSL expert out there can explain it to me, I will try again. But until then, I'm not going to waste any more time on this one.</p> <p>My guess is that IPv6, which will make SNI obsolete because every machine will have more than enough IP addresses, will become more mainstream before OpenSSL has some proper documentation.</p> </li> </ul> </article> <article> <h1>Monitoring progress</h1> <p>Sun, 20 Dec 2009 13:50:44 +0100</p> <p>The last two weeks, I've been working on the monitoring feature for 7.0 (see previous weblog). In the used design, Hiawatha would buffer monitoring information and send it to the monitoring server every X seconds. Although it looked like it would be going to work just fine, the more code I wrote, the more it felt like I was going the wrong way. The idea of Hiawatha becoming a HTTP client didn't feel right. All the code for being a HTTP server was already there, so why not turning it all around. Instead of Hiawatha posting data to the monitoring server, the monitoring server should be asking for it.</p> <p>Yesterday, I decided to get rid of the current monitoring code and start all over again. The new design felt right from the start. Of course, it will delay the 7.0 release. But, with this new design, the monitoring feature will be more solid.</p> </article> <article> <h1>Remote webserver monitoring</h1> <p>Fri, 11 Dec 2009 09:49:21 +0100</p> <p>For some time I've been thinking about a new feature which will justify the increase of the major version number from 6 to 7. Yesterday, I've come up with such a feature.</p> <p>Hiawatha version 7 will contain a remote monitoring ability. I will create a tool (probably a website) to which multiple Hiawatha instances can send status information. This tool will be able to show the current status and the history of all Hiawatha instances it is monitoring.</p> <p>The question is: what will the Hiawatha instances send to the monitoring tool? There are several detail levels possible: <ol> <li>Only send errors and other information that require attention from an administrator.</li> <li>Only send general webserver information, such as how many requests resulted in 200 OK, how many in 404 Not Found, etc.</li> <li>Send detailed information for every request.</li> </ol> </p> <p>Reasons to go for option 1 are that it only uses little CPU time and network bandwidth. There are enough monitoring tools like Google Analytics availble, even open source ones. So, there is no need to put heavy monitoring stuff in a webserver.</p> <p>Reasons to go for option 3 are that you have more certainty of the statistics then when using included javascripts, because users cannot change what is sent to the monitoring tool. You can keep the monitoring information to yourself, instead of giving Google more information about your visitors.</p> <p>What is your idea of what this monitoring tool should offer and why do you think so? A tool like Google Analytics would be very cool, but do we really need it to monitor multiple Hiawatha instances? Please, share your thoughts about this one.</p> </article> <article> <h1>Hiawatha weblog</h1> <p>Thu, 10 Dec 2009 09:11:20 +0100</p> <p>To give all Hiawatha users more insight in the development process, I started this weblog. Via this weblog, I will share my thoughts and ideas for Hiawatha's future. Hopefully, I will get some feedback so I can try to take your wishes into account.</p> <p>If you want to keep track of this weblog via a RSS reader, use <a href="/weblog.xml">this link</a>.</p> </article> </main></body></html>