Hi Harry, It's ok, I didn't need any disclamer. :) For sure, I'll run different task on each workstation. Thanks for the tip.
Steeve... --- In Axapta-Knowledge-Village@yahoogroups.com, Harry Deshpande <[EMAIL PROTECTED]> wrote: > > However, I must tell you that I am not an expert on bench-marking > > Regards > > Harry > Ps: and I forgot to include the disclaimer in my last email*s* > > This posting is provided "AS IS" with no warranties, and confers no > rights. Use of included script samples are subject to the terms > specified at http://www.microsoft.com/info/cpyright.htm" > The code provided (if any) may be written from the point of view of a > third party and the programming style/development standards may suit > such a point of view. > > From: Harry Deshpande > Sent: Tuesday, January 08, 2008 9:13 AM > To: 'Axapta-Knowledge-Village@yahoogroups.com' > Subject: RE: [Axapta-Knowledge-Village] Re: Axapta slower on SQL Server 2005 then SQL Server 2000? > > Hi > > Are you planning to use the same task for all the clients? May be that is not a good idea since they will end up locking each other. > > I would say one client can do sales order, another can do gl posting, another can do something in projects and so on. > > Regards > > harry > > > From: Axapta-Knowledge-Village@yahoogroups.com [mailto:Axapta- [EMAIL PROTECTED] On Behalf Of Steeve Gilbert > Sent: Tuesday, January 08, 2008 7:15 AM > To: Axapta-Knowledge-Village@yahoogroups.com > Subject: [Axapta-Knowledge-Village] Re: Axapta slower on SQL Server 2005 then SQL Server 2000? > > > Hi Harry, > > Can you give me tips on how to build a good multi-user benchmark? I > have a few long running db intensive task in Axapta that I was > thinking of running. I can probably test it with 4 or maybe 5 client > at time, do you think that will be multi-user enough? > > regards, > > Steeve... > > --- In Axapta-Knowledge-Village@yahoogroups.com<mailto:Axapta- Knowledge-Village%40yahoogroups.com>, Harry Deshpande > <harryd@> wrote: > > > > Hi > > > > Another thing to note is if you are running benchmarks then please > run the benchmarks in multi-user environment. SQL Server 2005 is much > better than '2000' in handling multi-user environment. (After all > your live system works multi-user) > > > > You will get 100% advantage once you upgrade to 4.0+ version since > concurrency has even been introduced in the AX application. > > > > Regards > > > > Harry > > > > > > This posting is provided "AS IS" with no warranties, and confers no > > rights. Use of included script samples are subject to the terms > > specified at http://www.microsoft.com/info/cpyright.htm" > > The code provided (if any) may be written from the point of view of > a > > third party and the programming style/development standards may suit > > such a point of view. > > > > From: Harry Deshpande > > Sent: Tuesday, December 18, 2007 11:15 AM > > To: Axapta-Knowledge-Village@yahoogroups.com<mailto:Axapta- Knowledge-Village%40yahoogroups.com> > > Subject: RE: [Axapta-Knowledge-Village] Axapta slower on SQL Server > 2005 then SQL Server 2000? > > > > Hi > > > > As per my experience SQL Server 2005 performance is much better > than '2000'. > > > > > > 1. Please check whether the SQL Server setup is in line with > Microsoft recommendations. > > > > 2. Go further and check things like disc-alignment. Take a > look at > http://sqlblogcasts.com/blogs/christian/archive/2007/10/09/disk- > sector-alignment.aspx > > > > 3. SQL Server 2005 engine is heavily optimized towards > cluster indexes. You will see a lot of cluster indexes introduced > from V4.0 onwards. Please back-port them. However, please note that > there is a small chance that the cluster indexes for some tables in > standard Ax may not be appropriate with your data usage pattern. In > this case you will have to figure out the best fit cluster index > yourself. > > > > 4. Last but not the least make sure you are running the > database with compatibility mode 90. (It is easy to forget this). > > > > I must say I am a very happy camper since I started using SQL > Server 2005. > > > > Regards > > > > Harry > > > > > > > > This posting is provided "AS IS" with no warranties, and confers no > > rights. Use of included script samples are subject to the terms > > specified at http://www.microsoft.com/info/cpyright.htm" > > The code provided (if any) may be written from the point of view of > a > > third party and the programming style/development standards may suit > > such a point of view. > > > > From: Axapta-Knowledge-Village@yahoogroups.com<mailto:Axapta- Knowledge-Village%40yahoogroups.com> [mailto:Axapta- > [EMAIL PROTECTED]<mailto:Knowledge-Village% 40yahoogroups.com>] On Behalf Of Steeve Gilbert > > Sent: Tuesday, December 18, 2007 10:51 AM > > To: Axapta-Knowledge-Village@yahoogroups.com<mailto:Axapta- Knowledge-Village%40yahoogroups.com> > > Subject: [Axapta-Knowledge-Village] Axapta slower on SQL Server > 2005 then SQL Server 2000? > > > > > > I read a couple of post here and there about Axapta being slower on > SQL > > Server 2005 then 2000. I thought that people that have problem post > > messages and those who don't stays quiet. That's why I was only > seeing > > post about SQL 2005 being slower. But then I stubble on a post on > MBS > > forum > > > (http://www.microsoft.com/Businesssolutions/Community/Newsgroups/dgbro > ws > > er/en-us/default.mspx? > > > query=sql+2005&dg=microsoft.public.axapta.database&cat=&lang=en&cr=US& > pt > > =&catlist=8d3f188d-a0E9-40e4-86e2- > > 46508a35c759&dglist=&ptlist=&exp=&sloc=en-us). And the quote is : > > "First of all Ax database runing on same hardware with SQL2005 is > ~20% > > slower than SQL200 database (tested)." > > > > I can't find something clearer that this. So, does my friends of the > > Axapta Knowledge Village acknowledge this statement? > > > > I'm gonna test this in our dev environment and if it turns out true, > > then it's gonna be the end of our SQL Server 2005 migration I guess. > > Btw, we are staying at Ax3.0 SP3 even if we migrate to SQL 2005. > > > > > > > > [Non-text portions of this message have been removed] > > > > > > [Non-text portions of this message have been removed] >