Prev: using schema in security mode
Next: Float Types Used as Primary Key on SQL 2005
From: --CELKO-- on 21 Jul 2010 09:48
>> So, when are we going to see YOUR numbers from YOUR testing? <<

I never test my own stuff; this is what Wes has done for years as part
of his jobs with various third party tools companies. My home machine
should have been replaced three years ago and I have no set up for
testing. Most of my clients are bigger than anything I woudl ever keep
at home

>> So - post them or shut up and stop advocating something based on what you "feel" may be correct! <<

I know that this is a wild idea for a cowboy coder like yourself, but
some of us design test scripts. I know that taking the extra time is
not as much fun as your "git'er done!" approach to programming, but we
just feel better about it.

A more professional approach would have been to propose things that
ought to be in the test suite, but that is just not your style ..
From: Tony Rogerson on 21 Jul 2010 10:21


"--CELKO--" <jcelko212(a)earthlink.net> wrote in message
news:a7762bc0-d7d3-4270-8ed7-a697df5ac610(a)i28g2000yqa.googlegroups.com...
>>> So, when are we going to see YOUR numbers from YOUR testing? <<
>
> I never test my own stuff; this is what Wes has done for years as part
> of his jobs with various third party tools companies. My home machine
> should have been replaced three years ago and I have no set up for
> testing. Most of my clients are bigger than anything I woudl ever keep
> at home
>

Thought as much.

>>> So - post them or shut up and stop advocating something based on what
>>> you "feel" may be correct! <<
>
> I know that this is a wild idea for a cowboy coder like yourself, but
> some of us design test scripts. I know that taking the extra time is
> not as much fun as your "git'er done!" approach to programming, but we
> just feel better about it.
>
> A more professional approach would have been to propose things that
> ought to be in the test suite, but that is just not your style ..

Lol, in my 24 years as an IT professional with a solid foundation in terms
of training I am fully aware of the life cycle and believe me I'd never take
lessons from you on that one!

Frankly all this work has already been done in depth by Erland, his work is
recognized throughout the community and his articles are the definitive
point of reference on this matter.

I'd suspect you've not even read his work because you are too dam arrogant
to accept when you are wrong.

And no - what works on DB2 or MySQL (btw a product people are leaving in
droves in favor of one of the NoSQL ones because it won't scale) does not
mean you can shoe horn it onto this product.

Like I've said - do post your article and I'll make sure it gets ripped to
shreds.

--ROGGIE--



From: Thomas on 21 Jul 2010 11:20
I thought Wes Brown plays for Manchester United? I didn't know he
moonlights as a geek!!
From: Erland Sommarskog on 21 Jul 2010 17:58
--CELKO-- (jcelko212(a)earthlink.net) writes:
> I gave him your rough numbers from your blog and he did not feel they
> were right. His quick guess was that the front end was converting each
> parameter, then passing it along the DB for a redundant conversion in
> some loop. This is based on a wild guess on his way out of the
> building and a few decades of prior tuning experience with my
> narrative. He has passed a lot more data to SQL Server procedures with
> MUCH better numbers.

The main bulk of the test suite runs with Win32::SqlServer a Perl API
of my own making. I found that table-valued parameters had lousy
performance, so I wrote simplifed version of the test for SqlClient and
ADO .Net. Which performed a lot better.

Since it could be a similar issue with many parameters, I wrote an
ADO .Net client for this test as well. This too outperformed my Perl
module, but not as radically as with TVPs. And performance was still
far from acceptable.


--
Erland Sommarskog, SQL Server MVP, esquel(a)sommarskog.se

Links for SQL Server Books Online:
SQL 2008: http://msdn.microsoft.com/en-us/sqlserver/cc514207.aspx
SQL 2005: http://msdn.microsoft.com/en-us/sqlserver/bb895970.aspx
SQL 2000: http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx

From: m on 23 Jul 2010 20:21
Although I have not reviewed your findings I am stunned that you wasted your
time performance testing with Perl? I suppose that this might be okay for
_comparative_ testing as long as DB operations were long enough, but if you
want to test performance, then try the SQLNCLI C API. Don't get me wrong,
..NET is great and I use it every day - just not for things that are supposed
to be fast - and Perl will perform badly under the best circumstances. But
perhaps I am out of the ordinary because I work with applications that
perform millions of updates in a day to tables with billions of rows and
therefore my standards are skewed.

"Erland Sommarskog" <esquel(a)sommarskog.se> wrote in message
news:Xns9DBCF3DBBAD40Yazorman(a)127.0.0.1...
> --CELKO-- (jcelko212(a)earthlink.net) writes:
>> I gave him your rough numbers from your blog and he did not feel they
>> were right. His quick guess was that the front end was converting each
>> parameter, then passing it along the DB for a redundant conversion in
>> some loop. This is based on a wild guess on his way out of the
>> building and a few decades of prior tuning experience with my
>> narrative. He has passed a lot more data to SQL Server procedures with
>> MUCH better numbers.
>
> The main bulk of the test suite runs with Win32::SqlServer a Perl API
> of my own making. I found that table-valued parameters had lousy
> performance, so I wrote simplifed version of the test for SqlClient and
> ADO .Net. Which performed a lot better.
>
> Since it could be a similar issue with many parameters, I wrote an
> ADO .Net client for this test as well. This too outperformed my Perl
> module, but not as radically as with TVPs. And performance was still
> far from acceptable.
>
>
> --
> Erland Sommarskog, SQL Server MVP, esquel(a)sommarskog.se
>
> Links for SQL Server Books Online:
> SQL 2008: http://msdn.microsoft.com/en-us/sqlserver/cc514207.aspx
> SQL 2005: http://msdn.microsoft.com/en-us/sqlserver/bb895970.aspx
> SQL 2000:
> http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx
>
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: using schema in security mode
Next: Float Types Used as Primary Key on SQL 2005