raymond_b_jime...@yahoo.com a écrit :
> I've seen a dump of the TDS traffic going from my webserver to the SQL
> Server database and it seems encoded in Unicode (it has two bytes per
> char). Seems it would have a huge impact on performance if it
> travelled in one byte. Why might this be?
>
> rj

Hi,
I've exactly the same trouble ... My apps is responding fine on a LAN
but when I goes on a WAN, getting horrible !

>From 5 sec to 7 min ... When I look SQL Time is the same so I look
network usage with network analyser and find the same result a you !

Something strange : in some case when string are in parameter it using
only one byte instead of two !

I'm wondering, if you find any solution ...

bzh_29 (xiii29@free.Fr) writes:
> I've exactly the same trouble ... My apps is responding fine on a LAN
> but when I goes on a WAN, getting horrible !

If you run your application on a WAN, you need to be more considerate
with your design. Make sure you don't return unneeded columns in your
result set (no SELECT *!). Also make sure that you don't have a lot of
extra network roundtrips. If you need to find data for ten orders, run
one query not ten.

> Something strange : in some case when string are in parameter it using
> only one byte instead of two !

varchar data, I assume. Query text is sent as Unicode. Parameter values
in RPC calls are sent in their native format. So nvarchar will be Unicode,
varchar will be 8-bit chars, and an integer will be 4 bytes.


--
Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se

Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pro...ads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinf...ons/books.mspx

> If you run your application on a WAN, you need to be more considerate
> with your design.
Excatly. We're working since a long time to avoid any unneccessary
table or column.

> Make sure you don't return unneeded columns in your result set (no SELECT *!). Also make sure that you don't have a lot of extra network roundtrips. If you need to find data for ten orders, run one query not ten.

Request are build to return only needed columns and we use a package
analyser to see what's going on on network to optimize network
traffic.

It's with this analyser I see that when I send one byte in fact I send
two ... I understand the reason you explain before but as my apps will
never feet for japanese ou chinese needs, I'm a little sad to not be
able to avoir such things ...

Need to continue optimize every char I send ...

bzh_29 wrote:
>> If you run your application on a WAN, you need to be more considerate
>> with your design.
> Excatly. We're working since a long time to avoid any unneccessary
> table or column.
>
>> Make sure you don't return unneeded columns in your result set (no
>> SELECT *!). Also make sure that you don't have a lot of extra
>> network roundtrips. If you need to find data for ten orders, run one
>> query not ten.
>
> Request are build to return only needed columns and we use a package
> analyser to see what's going on on network to optimize network
> traffic.
>
> It's with this analyser I see that when I send one byte in fact I send
> two ... I understand the reason you explain before but as my apps will
> never feet for japanese ou chinese needs, I'm a little sad to not be
> able to avoir such things ...
>
> Need to continue optimize every char I send ...

Ummm ... there is obviously something else going on here. You're trying to
tell us that sending two bites instead of one results in 84X (5 sec to 7
min) slower performance??? I don't think so. At worst, there would be a 2X
drop in performance, and even that is not likely (please, someone step in
and correct me if I'm wrong). My guess is an overloaded network or perhaps a
defective router or switch somewhere.

--
Microsoft MVP - ASP/ASP.NET
Please reply to the newsgroup. This email account is my spam trap so I
don't check it very often. If you must reply off-line, then remove the
"NO SPAM"

bzh_29 (xiii29@free.Fr) writes:
> It's with this analyser I see that when I send one byte in fact I send
> two ... I understand the reason you explain before but as my apps will
> never feet for japanese ou chinese needs, I'm a little sad to not be
> able to avoir such things ...

But maybe you need the oe digraph? Or the euro character? Those characters
are not on in Latin-1.

I don't know your business, but even if you are not aiming at the Far
Eastern market, you may expand into Poland or Hungary one day. That's
enough reason to use Unicode.

Developing for Unicode from the start is cheap. Changing to Unicode after
the fact is expensive.

And if you use varchar in your application, what is really your problem?
The only Unicode you need to send is the name of the stored procedures you
call? Or are you sending query batches from the application? Now, if you
do that, there are some bytes you can save by using stored procedures
instead.




--
Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se

Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pro...ads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinf...ons/books.mspx

On Thu, 27 Sep 2007 08:54:30 -0700, bzh_29 <xiii29@free.Fr> wrote:

>I've exactly the same trouble ... My apps is responding fine on a LAN
>but when I goes on a WAN, getting horrible !
>
>>From 5 sec to 7 min ... When I look SQL Time is the same so I look
>network usage with network analyser and find the same result a you !

Just to make sure one basic point is covered, do all the stored
procedures have SET NOCOUNT ON right at the beginning? Leaving that
out can magnify network issues.

Roy Harvey
Beacon Falls, CT