RE: [OT] log4j to file or db -- which will be faster
Howdy, I'd prefer the file usually, to avoid any transactional and translational overhead associated with SQL calls. Of course, the best thing to do is for you to try it out and convince yourself. Yoav Shapira Millennium ChemInformatics >-Original Message- >From: Prabhat Kumar (IT) [mailto:[EMAIL PROTECTED] >Sent: Wednesday, October 22, 2003 4:09 PM >To: [EMAIL PROTECTED] >Subject: [OT] log4j to file or db -- which will be faster > > >I know that this is too generic a question, but we have a requirement to >log informational messages in our application about why certain actions >were performed or not. We are considering using either a FileAppender or a >JDBCAppender. Which one do you think will be a faster operation under load? >I guess one way to find out would be to actually try it out, but was >wondering if you guys had thoughts about it. > >Thanks, > >Prabhat. This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] log4j to file or db -- which will be faster
thanks, would simple time calculations using Sytem.currentTimeMills() be a reliable way to calculate durations? -Original Message- From: Shapira, Yoav [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 22, 2003 4:23 PM To: Tomcat Users List Subject: RE: [OT] log4j to file or db -- which will be faster Howdy, I'd prefer the file usually, to avoid any transactional and translational overhead associated with SQL calls. Of course, the best thing to do is for you to try it out and convince yourself. Yoav Shapira Millennium ChemInformatics >-Original Message- >From: Prabhat Kumar (IT) [mailto:[EMAIL PROTECTED] >Sent: Wednesday, October 22, 2003 4:09 PM >To: [EMAIL PROTECTED] >Subject: [OT] log4j to file or db -- which will be faster > > >I know that this is too generic a question, but we have a requirement to >log informational messages in our application about why certain actions >were performed or not. We are considering using either a FileAppender or a >JDBCAppender. Which one do you think will be a faster operation under load? >I guess one way to find out would be to actually try it out, but was >wondering if you guys had thoughts about it. > >Thanks, > >Prabhat. This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] log4j to file or db -- which will be faster
A file will be faster unless your file system is really crappy or you are writing to a nfs mounted or other remote filesystem. (Even then it will still probably faster). IIRC, there is an ASyncronous appender which is a layer between your logging code and the real logger. What it does is queue up all writes so your application code can execute as quickly as possible. But it can only be configured via an XML file, not via properties files. -Tim Prabhat Kumar (IT) wrote: I know that this is too generic a question, but we have a requirement to log informational messages in our application about why certain actions were performed or not. We are considering using either a FileAppender or a JDBCAppender. Which one do you think will be a faster operation under load? I guess one way to find out would be to actually try it out, but was wondering if you guys had thoughts about it. Thanks, Prabhat. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] log4j to file or db -- which will be faster
Howdy, System.currentTimeMillis() is good enough for the time of performance assessment you're doing. Yoav Shapira Millennium ChemInformatics >-Original Message- >From: Prabhat Kumar (IT) [mailto:[EMAIL PROTECTED] >Sent: Wednesday, October 22, 2003 4:19 PM >To: Tomcat Users List >Subject: RE: [OT] log4j to file or db -- which will be faster > >thanks, > >would simple time calculations using Sytem.currentTimeMills() be a reliable >way to calculate durations? > >-Original Message- >From: Shapira, Yoav [mailto:[EMAIL PROTECTED] >Sent: Wednesday, October 22, 2003 4:23 PM >To: Tomcat Users List >Subject: RE: [OT] log4j to file or db -- which will be faster > > > >Howdy, >I'd prefer the file usually, to avoid any transactional and >translational overhead associated with SQL calls. Of course, the best >thing to do is for you to try it out and convince yourself. > >Yoav Shapira >Millennium ChemInformatics > > >>-Original Message- >>From: Prabhat Kumar (IT) [mailto:[EMAIL PROTECTED] >>Sent: Wednesday, October 22, 2003 4:09 PM >>To: [EMAIL PROTECTED] >>Subject: [OT] log4j to file or db -- which will be faster >> >> >>I know that this is too generic a question, but we have a requirement >to >>log informational messages in our application about why certain actions >>were performed or not. We are considering using either a FileAppender >or a >>JDBCAppender. Which one do you think will be a faster operation under >load? >>I guess one way to find out would be to actually try it out, but was >>wondering if you guys had thoughts about it. >> >>Thanks, >> >>Prabhat. > > > >This e-mail, including any attachments, is a confidential business >communication, and may contain information that is confidential, >proprietary and/or privileged. This e-mail is intended only for the >individual(s) to whom it is addressed, and may not be saved, copied, >printed, disclosed or used by anyone else. If you are not the(an) intended >recipient, please immediately delete this e-mail from your computer system >and notify the sender. Thank you. > > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]