Skip to main content

Posts

Showing posts from March, 2012

OpenNMS: PostgreSQL 9.1 tuning

I have just completed an upgrade from OpenNMS 1.8.11 to the latest and greatest 1.10. The upgrade in itself is easy and the guides on the OpenNMS wiki will serve you well. Instead in this post I'll describe a couple of other changes that I made which improved very much the overall performance and responsiveness of the system. One is the upgrade from PostgreSQL  8.4 (which came with CentOS) to 9.1 + tuning. The other is switching from apache to nginx. Upgrading postgres is mostly a matter of taking a backup,  pulling in the right repo , running  yum install  and finally importing the database. Tuning postgres I left opennms running on PostgreSQL 9.1 for a while and then I went checking how well postgres was doing. Postgres 9 already performs significantly better that its 8.x predecessors, but I wanted to do better than out-of-the-box. As the postgres user I logged in into the opennms database to install a utility that will help me estimate how much of the database is bein

A case for manipulating the DOM outside the Sproutcore RunLoop

KVO is one of Sproutcore coolest features. At the core of it there is the RunLoop in which events and notifications are efficiently processed, dispatched to their destination(s) and views modify the DOM to reflect the new application state. Sproutcore developers are consequently told not to manipulate directly the DOM. When out-of-band events, like an ajax call returning from a third-party library or a WebSocket receiving a new message happen it is possible to trigger the RunLoop manually by calling  SC.RunLoop.begin() ... SC.RunLoop.end() . Sometimes though it is not only necessary, but recommended, to bypass the RunLoop and manipulate directly the DOM to either provide UI refreshes as fast as the browser allows or avoid the expensive computations implicated in the RunLoop. These concepts were incidentally discussed on IRC just when I needed to implement a progress bar to provide feedback on the loading state of a particularly slow datasource and I am writing them down here so that

Tweak OpenLayers to get parse GetCapabilities working in IE

It happened to me recently that I needed OpenLayers (version 2.11) to parse a GetCapabilities response from Geoserver to present the user a list of layers to pick from. The capabilites request is made through a Sproutcore request, which is basically a jQuery ajax object in disguise. This of course works beautifully in every browser with the notable execption of ... IE (IE9 included). The cause is that IE will helpfully xml-parse a response whose content-type is text/xml , but will refuse to parse a document whose content-type is  application/vnd.ogc.request+xml . To add comedy to the drama the responseXML attribute of response is not null, as one would expect, but is instead set to reference an empty dom. The workaround is to put a giant browser-sniffing if in your javascript to handle IE differently. The code is like the following and please note that it is Sproutcore code, so browser sniffing and other amenities are peculiar to Sproutcore: // God mess IE if(SC.$.browser