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.
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.
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.
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?
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.
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.
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.
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?
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.
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?
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.
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.
is working on a reply...