Copied to clipboard

Flag this post as spam?

This post will be reported to the moderators as potential spam to be looked at

  • Steven Lemmens 30 posts 71 karma points
    Jan 31, 2013 @ 13:54
    Steven Lemmens

    Umbraco Logging (or 'time travelling' as I'd like to call it)

    Hello everyone

    I happened to see that v6.0 was released today. And saw this in the "what's new"-section:

    "All logging now goes to a text file, so your log table won't grow so much any more"

    This kind of feels like whe've gone back in time. An IO operation is expensive and Umbraco already isn't the fastest CMS out there with bigger websites. A huge table is still faster than opening and appending to a huge file every time something has to get logged.

    I think a log table that grows too big is a developers problem. You can turn logging off, trim a table regularly, use "disabledLogTypes" (umbracosettings.config) to make sure certain types of errors aren't logged when the site goes live, ... Or heck, just make sure the errors that get logged get solved asap.

    So I'd like to know what your feelings are about this? Can I change the logging back to the database logging if I want to through the config, or do I have to turn it off completely to avoid the IO-operations? I couldn't find anything about this, so I hope this gets documented.

    Thanks for your input.

  • Grant Thomas 291 posts 324 karma points
    Jan 31, 2013 @ 15:16
    Grant Thomas

    Was there any research done into whether or not this would be for the best, not only right now, but in the future? I sincerely hope it wasn't a case of the table becoming problematic so much so that a mitigation measure was grasped at without rigorous comparative testing going on side-by-side with the two mechanisms on a large scale.

    Also, where is this text file stored?


  • E.J. Brennan 73 posts 114 karma points
    Feb 07, 2013 @ 13:53
    E.J. Brennan

    Looking in the config\log4net.config file, it looks like the file is stored in the app_data\logs\umbracotracelog.txt file. Personally I am in favor of the text file, but I don't think it would be that hard to add some code to direct the log entries to a database instead if that is what you prefer.

  • Steven Lemmens 30 posts 71 karma points
    Feb 07, 2013 @ 14:00
    Steven Lemmens

    Hey E.J. Brennan,

    thanks for your response.

    I just think it odd that they decided to go from database to text-file. Opening and appending to a text file (which will probably become quite large) is slower than just doing an insert into a LOG table. I keep wondering what's the reasoning behind this.

    is there any reason you prefer text files specifically?

  • E.J. Brennan 73 posts 114 karma points
    Feb 07, 2013 @ 14:37
    E.J. Brennan

    Just a preference - I don't like 'polluting' my production databases with temporary logging information that needs to be purged on a regular basis; plus I like to be able to open up a log file with notepad for quick checks if I have something going on. Also, a lot of my clients are using the free version of sql server, so logging to the database, especially if you are getting a lot of entries, over time will increase the size of the DB and possibly push a DB over the limit that is allowed without moving upto a paid license.

    While its true there is overhead to write to a text file, there is also overhead writing to a database. I'd rather take the performance hit (if there is one), when logging something that went wrong, than possibly slow down the non-logging operations that might take place if the DB size keeps getting bigger in an unchcked fashion.

    Just my two cents.

  • Steven Lemmens 30 posts 71 karma points
    Feb 07, 2013 @ 16:01
    Steven Lemmens

    Thanks for your insights, E.J. Brennan.

    I think that the same can be said for logging to a text file - that is to say, the file can increase exponentially and leave you without any free diskspace.

    I suppose it comes down to what gets logged in the end. You should only log real problems and no "information"-type loggings to keep the performance hit as low as possible.

    This is the list of everything that gets logged:

    new = when a new node is created in the database
    system = application events such as restart
    debug = debug information such as node name changes, xml save times
    login = information regarding Admin user login
    error = .net error logging of errors in the backoffice as well as website
    save = node is saved to the database
    delete = node is deleted from the database
    publish = node is published
    notfound = node not found
    open = recorded when a node is opened

    Safe to say, some of these should be turned off for a production website and I'm currently thinking that Async logging should be on by default, to make sure the performance hit is as little as possible.


Please Sign in or register to post replies

Write your reply to: