Quantcast
Viewing all articles
Browse latest Browse all 3587

Re: Effective Logging in ASE

I would expect some level of contention/performance hit for syb_sendmsg ...

 

- the dataserver has to make a remote call (small performance hit); probably not something you'll want to do in a high-volume logging situation; and if the syb_sendmsg call moves your spid/process off the run queue while waiting for an OS response ... you could see a substantial drop off in performance for large volumes of syb_sendmsg calls, ymmv

 

- what happens if the 'listener' is down (syb_sendmsg either errors out or hangs?)

 

- does the 'listener' serialize its incoming messages (eg, what happens if multiple dataserver processes are sending a (relatively) large volume of messages in a short period of time => lengthy delays as messages queue up for the 'listener'?

 

--------------

 

Of the 3 I personally like the print command.

 

As you mention it handles all datatypes (unless you want numeric/date/time data formatted differently).

 

Easy to enable/disable (via an input parameter and if/then testing).

 

Should be no contention issues with other dataserver process/threads.

 

Could add some performance hit for the extra network traffic (especially if running 'set flushmessage on').

 

One downside would be that each client would have its own log file so you'll need the ability to process/search multiple logs ... possibly on different machines?  Though you could have all clients write to a common log file, but then you end up with contention on the log file, not to mention the very real chance of garbling/mixing the output messages from different clients.

 

--------------

 

All of the above assumes the logging will be used primarily for troubleshooting (and possibly some reporting) purposes.

 

The print command minimizes runtime performance & contention issues (vs syb_sendmsg; vs log tables), and eliminates potential space issues in the database (vs log tables).

 

The 'downside' for the print command is that you need a method for searching (and culling older) log files ... though I consider this to be a minor issue if you've got a good design/standard in place (eg, log file naming standard, log file location standard, log file content/format standard, etc).  Writing an OS-level process (eg, shell script) to process the log files should be trivial.


Viewing all articles
Browse latest Browse all 3587

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>