Johan; thinking out loud.

Someone Googled for ‘better than logview4net’ and ended up on my blog. It must have been an anticlimax to look for something better and end up on the developers blog.

There is a java application called Chainsaw that is part of the Apace Logging Services. I don’t know about all it’s features but it inspired me to create logview4net.

I know there are some performance issues with some usage patterns. If you think you are on of those users please write a comment and use a WORKING email address so that I can try to fix your issues.

Share This

After some indications from a faithful (thanks Bill) user I found a perceived ‘hang’ in logview4net; If you load two large files (>500 lines) it will hide the progress bar for the second file. I have fixed that so now it doesn’t appear to hang while loading the files. It is still unusable until both files are loaded though.

I have to implement some kind of auto sizing of the buffer and then I’ll do a new release. Probably within a week.

The bigger performance issue is a little harder

I have users that monitor the Windows Event Log and some log files on >50 servers and keep the app running all the time. If I stored all that data their workstations would be out of memory most of the time. So the conflict is between the style of usage where you want to see all data, as in loading a large file, and their style of usage where there is an infinite amount of data. The current solution is to load the large files into memory and just treat it as a large buffer, but it is painfully slow. I would rather just load the data needed on the screen at the moment.

I will keep on tuning it, but implementing a sliding window is almost a new application so it will probably not happen soon. I will keep large file loading in mind though so that it wont get worse. It is the multitude of listeners and the possibility to have more than one listener in a session that makes this hard to solve.

I have previously made the decision to evolve logview4net as a real time log monitor and not a log file parser so I will prioritize new listeners and actions before large file parsing performance.

The application that inspired me to make logview4net is Chainsaw. If logview4net doesn’t fulfill your needs maybe Chainsaw will. I didn’t want to install a Java runtime just to listen to a UDP port so I started writing my own app instead.

Share This

I have changed the license for logview4net from BSD to Artistic License 2.0. As far as I understand these licenses this means that you previously could do just about whatever you wanted with the logview4net and now your freedom is limited to your own organization. That is: You may still freely distribute the unmodified binaries, but you are only allowed to distribute modifications within your organization.

The reason for this change is that I don’t want anyone to repackage my stuff and make a lot of money from it. I also want to have the same license for all my open source software and the BSD was a little bit to loose for my future needs.

If you are in need of any other type of licensing please contact me, I am open for suggestions.

Share This

Wow, the releases are coming fast now.

Today I released a new version of logview4net:

CHANGELOG:
8.02
Request:Show short filename on prefix-filename
Fixed: It is not possible to change the buffersize in the viewer config window.
Fixed: HighlightMatch only formatted the first occurance of the pattern in a message.
Fixed: The textbox reverts to default format when enforcing the buffer size
Added a Play Sound action that will play a PCM Wave File on pattern match.

Share This

Here’s a one week old post I forgot to publish:

I did some performance testing and fixing in logview4net today, but I threw away the baseline performance report. I managed to shave some processing time, but I only kept the previous report so I am not certain how much I saved. It’s a stupid mistake but hopefully I’ll not make it again now that I’ve told you about it. Save your baseline for future comparison when doing performance optimizations.

Almost all processing time is spent on appending and sometimes formatting text to a RichTextBox. It is not as fast as I would like it to be. I could probably write something that does what I want myself, but I guess someone has already done that. All the functionality of the RichTextBox is not needed for logview4net. I only need to change the font and color properties of parts of the text. There are no editing, tables, bullets, images or anything else that I guess is complicated to do.

After some more communicating with a nice user it seems that the performance is mostly annoying when loading a large file. It is a scenario I didn’t build it for at all. It is build to show one message a time and hence has relatively much time to process it.

…anyway; A new release that works a little bit better in this scenario is on the way. I got the load time for this file down from more than one hour (I killed the process after that.) to less than 30 seconds.

Share This

New year, new release.

This release incorporates the performance  fixes that were maid last week after some user feedback.

I still have no intentions to turn logview4net into a full featured log parser, but now it can handle much bigger datasets than before. If I get some bright ideas it might get faster still. The problem is that I load all existing data into the textbox that shows the data. So if you add a file or SQL listener and there is lots of data already there and you choose to show it all; logview4net will treat each row as a separate message and show each message one at a time.

The design decision I’ve made for logview4net is that all listeners are treated as being forward only data. This means that I can’t get past time data from a listener, it will send new data to the part of the program I call the viewer. The viewer is essentially the textbox that shows all formatted data. This decision was made because I’d rather have lots of available datasources than a fast way to look at old data. logview4net was initially and primarily built to be a real time log viewer/monitor, not a log parser to use on historic data.

If I only worked with random access data I could take the same approach as Kiwi Log Viewer and load only the data that the use can see at the moment. I have some ideas on how to merge these worlds and I’ll probably use the blog to make them more tangible for myself.

The changes made to release 8.01 removed lots of processing time when receiving an event but the greediest part is the RichTextBox that comes with the .Net Framework so I’m looking for a replacement for that.

Share This

I recently got a message from a user who had performance issues with logview4net when using the pause function in combination with lots of incoming events. Since pause is probably mostly used in situations when there are lots of events I guess more users than Bill and I have noticed it before. I have two cores on my main machine so I usually just let it be until logview4net has recovered by it self. The problem is that almost all processing of an event takes place when it is time to display it, not when it is received. When running in normal mode this is ok, but when coming back from pause mode this places a big burden on the display thread.

I’ve made a change today so that the application does all processing of an event, except the coloring, before it is sent to the cache when in pause mode. That way the processor utilization should be almost the same when in pause mode as when running normally.

I will make the new release in the first week of January to get the nice version number 8.01

Share This

I am thinking of releasing logview4net under a commercial license as well as the BSD license I am using now. This would enable users in organizations that dislike open source to use the application anyway.

Besides the political issues I need something else to motivate an organization to pay for something that is given away for free. There is at least one new listener coming up and I could definitively release updates earlier to commercial users. I don’t like having to manage two code bases so the compiler savvy could always get the latest version from SourceForge. I guess I could include the source and documentation in the commercial package if someone wants to run the application without internet access. On that note I could offer email notification to commercial customers when there are new updates.

Do you have any thoughts on this?

Share This

Yesterday I slipped out a new version of logview4net. It was just a very small bugfix. I had lost the checkbox for adding a filename to the listener prefix in the settings for the folder listener.

Big ups to Paul who told me about it.

Share This

About a week ago I was offered help to translate logview4net to Russian. The offer came from a gentleman owning an open sourced project for translating .NET applications.

Of course I was thrilled by the offer. I had really thought about localizing it, but since English and Swedish is all I know I haven’t put it on top of my to do list. Most, if not all, Swedish users of logview4net are probably happy using it in English.

Anyway; after looking at the technical solution I decided I didn’t want to use it in my application. I feel a bit bad for letting him do all the work before I looked at his solution. I assumed to much. A bad habit I really need to get rid of. I have localized one large application as an after thought and one as part of the design so my decision is at least based on some experience.

I hope my turn down letter will be regarded as constructive criticism and not a flipped finger.

To any one else wanting to write tools for localizing applications; there a lots of stuff that works in the .NET framework. Try to create tools for all the things that are missing instead of starting from scratch.

Share This