ADSM-L

Performance tracing

2006-04-12 09:36:39
Subject: Performance tracing
From: "Loon, E.J. van - SPLXM" <Eric-van.Loon AT KLM DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 12 Apr 2006 15:29:50 +0200
Hi *SM-ers!
One of my customers is complaining about the backup performance of the
daily DP for SQL Server. The tdpsql.log shows that performance is 15
Mb/sec. which looks very fine to me for a host which is connected to a
100 MB LAN, but the customer showed me the TDP log from December last
year which shows a daily throughput of 25 Mb/sec and more!!!
My only guess is that this was caused by compression (how else can you
get more than 10 Mb/sec through such a connection) but I would like to
see what the client is doing.
I was thinking about starting a client trace (at the DP level or at the
API level?) to find this answer.
What tracing parameters should I specify to see the time it takes for
the client to get the data, compress it and send it over the network? I
do not want to much detail, since the backup runs during the night for
several hours, so a too detailed trace will grow very large...
Thank you very much for  any hints or tips in advance!
Kindest regards,
Eric van Loon
KLM Royal Dutch Airlines


**********************************************************************
For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), 
its subsidiaries and/or its employees shall not be liable for the incorrect or 
incomplete transmission of this e-mail or any attachments, nor responsible for 
any delay in receipt.
**********************************************************************

<Prev in Thread] Current Thread [Next in Thread>