Measuring TCP round-trip times, part 4: plotting the data

I added a new plot to the Site Traffic page. This is just another Wt widget in my existing Wt application that displays the traffic chart. Since Wt does not have a box plot, I’m displaying the data as a simple point/line chart. There’s a data series for each of the minimum, 25th percentile, median, 75th percentile and 95th percentile. These are global round-trip time measurements across all hosts that accessed my web site. In a very rough sense, they represent the network distance of the clients of my web site. It’s worth noting that the minimum line typically represents my own traffic, since my workstation shares an ethernet connection with my web server.

Clicking on the chart will display the values (in a table below the chart) for the time that was clicked. I added the same function to the traffic chart while I was in the code. I also started playing with mouse drag tracking so I can later add zooming.

Site content calendar work started

This weekend I started working on a simple page to allow browsing content on my site by last modification date. I don’t expect this to be very useful to visitors. Its main intent is to let me keep track of what I’ve worked on recently.

has a WCalendar widget that I’m using as a base class for the calendar. I extend the WCalendar class and add my own loading (in the constructor), cell rendering to highlight dates on which content was modified, and of course I connect selection signals to my own slots. When a date is selected, a WTable below the calendar will display links to the content that was modified on that date.

I save a cookie holding the last date selected, so that when a user returns to the same page within 24 hours, the calendar will load the month of the last date selected and will select the last date selected. The WTable will be updated appropriately.

Since my indexing code already saves a last modified time as a document value when I’m indexing the web site, and I already had C++ code to pluck document data from the database, it was not difficult to have my application load the data that’s behind the calendar. I spent a great deal more time getting the calendar to look the way I want than I spent writing functional code.

You can see the new calendar here. It’s not finished, but it’s functional.

web site health monitoring: part 2

Last weekend I finished implementing the CPU temperature and filesystem utilization graphs. They work fine, though I may change the filesystem utilization graphs to just be category charts with a single set; filesystem utilization doesn’t change frequently. The latest can be seen here.

I deployed the health monitoring on the new spcarsplus.com web site for Randy. That host doesn’t have CPU temperature reporting, so I made changes to the code to not display that graph if CPU temperatures are not available.

There’s a problem with the BIOS on rfdm.com: the CPU temperatures are incorrect. I have newer BIOS to load, I just haven’t gotten around to it yet.

web site health monitoring: part 1

This past weekend I finished the data collector for web site health. I keep track of CPU temperatures, CPU utilization and filesystem utilization.

The CPU utilization graph is done. The others are in the works. Like my traffic graphs, the user interface is a Wt application.

web site traffic monitoring: part 2

I’m done with the first pass of traffic monitoring. The traffic page can show graps of web site traffic on port 80 for the current day, current week, previous week, current month, previous month, current year and previous year. Good enough for now.

web site traffic monitoring: part 1

Last weekend I wrote a simple program to store traffic statistics (packets and bytes for both input and output) for port 80 of my new web server. Actually, any pcap filter expression can be used, I just happen to only be tracking port 80 at the moment. I save data every 5 minutes.

This weekend I spent a little time writing an application using Wt to graph the traffic data. The graph works, but it needs some cleanup. In the process, I wound up making some changes to the Wt::Chart classes because it didn’t let me use the desired colors for axis labels, titles and legend text. I’ll have to check these changes into my repository so I can diff them and send a patch to the Wt author.

I now just need some utility classes and functions to allow graphing various time periods of interest.

sitemap deployed

I’ve deployed my web site map. This is the result of the work discussed in my post on Using Wt (C++ Web Toolkit) for a web site map. The original application mentioned in that post can now run as a WidgetSet application, and is now embedded in my php page wrappers.

I’m starting to think that it’d be nice to play with replacing my search page with a Wt application. Not because there’s anything wrong with the existing search, but because I’d like to free myself from maintaining the javascript. The javascript for my search page isn’t large nor terrible since I’m using jQuery, but replacing it with Wt would permit graceful degradation. And while javascript is handy, I’m still a non-expert in it.

Using Wt (C++ Web Toolkit) for a web site map

It had been many years since I had looked at Wt, a C++ library for developing interactive web applications. Last weekend, I started using it again for a simple site map that’s automatically generated so I don’t have to manually update the map.

The first pass resulted in sitemap. I’m using a TreeView with Wt::WStandardItem objects.

The sitemap application initially generated the TreeView on the fly by traversing the filesystem under my document root, using my existing SiteIndexConfig class (used by my menu generators and my site indexer) for configuration. I knew from the start that this wouldn’t work for deployment, since it’d be too slow with all of the content from my old web server. But I already had classes to traverse the filesystem and pluck out web pages, find their titles (already stored in Xapian by my indexer), etc. It worked for a throwaway prototype.

I then wrote a new application to generate the data for sitemap, which I named (with no originality) mksitemap. It dumps a small binary file from a class named Dwm::WWW:DirectoryTree (derived from Dwm::DirectoryEntry), which can be directly read to populate a Dwm::WWW::SiteMap::DirectoryTree. From the instance of Dwm::WWW::SiteMap::DirectoryTree, I directly create Wt::WStandardItem objects for the Wt::TreeView.

The sitemap application itself is fairly small in terms of lines-of-code:


dwm@www2:/home/dwm/src/dwm/www/apps/sitemap% mcloc .
54 ./DwmWWWSiteMapApp.cc
22 ./DwmWWWSiteMapApp.hh
43 ./DwmWWWSiteMapDirectoryTree.cc
28 ./DwmWWWSiteMapDirectoryTree.hh
20 ./sitemap.cc
167 TOTAL

Obviously this isn’t counting the more general-purpose classes used by sitemap:


dwm@www2:/home/dwm/src/dwm/www/classes% mcloc src include
14 include/DwmWWW.hh
27 include/DwmWWWDirectoryTree.hh
41 include/DwmWWWSiteIndexConfig.hh
17 include/DwmWWWUtils.hh
97 src/DwmWWWDirectoryTree.cc
243 src/DwmWWWSiteIndexConfig.ll
130 src/DwmWWWUtils.cc
569 TOTAL

I’m not going to count the lines of code from libDwm; it’s a significant library, I’m only using a small part of it in this application, and it’s no effort to use it since I’ve been working on it for a decade. I’m using the Dwm::IO templates, the Dwm::SysLogger class, the Dwm::StringUtils templates, the Dwm::DirectoryEntry class and the Dwm::Signal class since I’m running under mod_fastcgi.