Vantage 8.03 Speed Issue

Yahoo Archive
21
Nigel,



In addition to the previous poster's observations, it also appears that you
have no BI buffers allocated and are not using spin lock retries. Also, how
may asynchronous page writers do you have configured? It is entirely
possible that the BI log is simply being overrun with write requests and is
unbuffered placing the entire burden upon your I/O subsystem which, as
others have correctly pointed out, is a highly non-optimal configuration for
write intensive applications. Set you BI Buffers to a minimum of 25 and
start from there. Additionally, make sure your spin lock retries is set to
approximately 20000 per processor or you will be effectively limiting the
database to the resources of a single CPU.



Good Luck,



Michael





Michael Barry
Aspacia Systems Inc
866.566.9600
312.803.0730 fax
<http://www.aspacia.com/> http://www.aspacia.com/

This email, and any attachments thereto, is intended only for use by the
addressee(s) named herein and may contain legally privileged and/or
confidential information. If you are not the intended recipient of this
email, you are hereby notified that any dissemination, distribution or
copying of this email, and any attachments thereto, is strictly prohibited.
If you have received this email in error, please immediately notify me by
telephone and permanently delete the original and any copy of any email and
any printout thereof.





From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf Of
Nigel Kerley
Sent: Friday, July 20, 2007 1:15 PM
To: vantage@yahoogroups.com
Subject: [Vantage] Re: Vantage 8.03 Speed Issue



Hi Stephen,

Answers below.

Nigel.

--- In vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com> , "Stephen
Edginton" <stephene@...>
wrote:
>
> Hi Nigel,
>
>
>
> What patch are you running?
We're on 305H.

>
> Number of users?
Approx 30 users in Europe, 15 in USA. The USA office is 8 hours
behind Europe so the overlap is no more than 2 hours.

>
> What is the speed to retrieve these entries i.e pull up in order
entry,
> po entry?
To pull up SO: 15secs (133 lines), PO: 23secs (112 lines), PO
Receipt: 15secs (112 lines)

>
> Did you experience the same speed during piloting of these larger
> orders?
I suspect we didn't create large enough docs during testing.

>
> What is your disk configuration?
Application, OpenEdge and OS are on a Raid5 array. The DB itself is
on a seperate mirror array.

>
> Can you post your .pf file and how much of the DB are you buffering?
.pf file:
"-Mm 4096 -mmax 65534 -Bt 5000 -s 200 -yy 1970 -stsh 31 -inp 32000 -
tok 4000 -TB 31 -TM 32 -D 500 -l 13000
-T d:\epicor\mfgwrk803
-db f:\epicor\mfgsys803\db\mfgsys
-cpinternal utf-8 -cpstream utf-8 -cprcodein utf-8"

Blocks in DB buffer = 20,000.

>
> Are you running other services on the server?
SQL is running on the same server, but not for any intensive tasks.
It has been configured to only use 1 processor and 1GB of RAM.

>
>
> What is the average speed to add a line initially?
Approx 5 secs per line - entering manually.
Approx 4 secs per line - pasting in.

>
> Is there a point where adding new lines becomes slower?
No, not really. Becomes noticeable after c.15 lines and gets worse
from there.

>
>
>
> Also try the same operations running the client on the server, what
are
> the figures then?
Entering PO (112 lines): 22mins
Entering SO (90 lines): 10 mins
Didn't try a Goods Received - too painful!

>
>
>
> Regards,
>
> Stephen Edginton
>
>
>





[Non-text portions of this message have been removed]
22
Hi Michael,

Your comments are correct....however I have a few
questions....

How did you determine that there were no BI buffers
allocated from only the pf file or the spinlock retires were not set?
These are not parameters of the appservers but the Database itself (the
mfgsys,lg will give us a log of these settings)

Your comments regarding the APW are valid, I would also
add, increasing the blocksize of the BI buffers which helps along with
your APW recommendations.

Lastly the comment regarding limiting the resources to a
single CPU by setting the spin lock retries..... This is just a
mechanism for locking reties not processor affinity unless I am
mistaken..?



Regards,

Stephen Edginton





From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf
Of Michael Barry
Sent: 20 July 2007 22:20
To: vantage@yahoogroups.com
Subject: RE: [Vantage] Re: Vantage 8.03 Speed Issue



Nigel,

In addition to the previous poster's observations, it also appears that
you
have no BI buffers allocated and are not using spin lock retries. Also,
how
may asynchronous page writers do you have configured? It is entirely
possible that the BI log is simply being overrun with write requests and
is
unbuffered placing the entire burden upon your I/O subsystem which, as
others have correctly pointed out, is a highly non-optimal configuration
for
write intensive applications. Set you BI Buffers to a minimum of 25 and
start from there. Additionally, make sure your spin lock retries is set
to
approximately 20000 per processor or you will be effectively limiting
the
database to the resources of a single CPU.

Good Luck,

Michael

Michael Barry
Aspacia Systems Inc
866.566.9600
312.803.0730 fax
<http://www.aspacia.com/> http://www.aspacia.com/

This email, and any attachments thereto, is intended only for use by the
addressee(s) named herein and may contain legally privileged and/or
confidential information. If you are not the intended recipient of this
email, you are hereby notified that any dissemination, distribution or
copying of this email, and any attachments thereto, is strictly
prohibited.
If you have received this email in error, please immediately notify me
by
telephone and permanently delete the original and any copy of any email
and
any printout thereof.

From: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
[mailto:vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com> ] On
Behalf Of
Nigel Kerley
Sent: Friday, July 20, 2007 1:15 PM
To: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
Subject: [Vantage] Re: Vantage 8.03 Speed Issue

Hi Stephen,

Answers below.

Nigel.

--- In vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
<mailto:vantage%40yahoogroups.com> , "Stephen
Edginton" <stephene@...>
wrote:
>
> Hi Nigel,
>
>
>
> What patch are you running?
We're on 305H.

>
> Number of users?
Approx 30 users in Europe, 15 in USA. The USA office is 8 hours
behind Europe so the overlap is no more than 2 hours.

>
> What is the speed to retrieve these entries i.e pull up in order
entry,
> po entry?
To pull up SO: 15secs (133 lines), PO: 23secs (112 lines), PO
Receipt: 15secs (112 lines)

>
> Did you experience the same speed during piloting of these larger
> orders?
I suspect we didn't create large enough docs during testing.

>
> What is your disk configuration?
Application, OpenEdge and OS are on a Raid5 array. The DB itself is
on a seperate mirror array.

>
> Can you post your .pf file and how much of the DB are you buffering?
.pf file:
"-Mm 4096 -mmax 65534 -Bt 5000 -s 200 -yy 1970 -stsh 31 -inp 32000 -
tok 4000 -TB 31 -TM 32 -D 500 -l 13000
-T d:\epicor\mfgwrk803
-db f:\epicor\mfgsys803\db\mfgsys
-cpinternal utf-8 -cpstream utf-8 -cprcodein utf-8"

Blocks in DB buffer = 20,000.

>
> Are you running other services on the server?
SQL is running on the same server, but not for any intensive tasks.
It has been configured to only use 1 processor and 1GB of RAM.

>
>
> What is the average speed to add a line initially?
Approx 5 secs per line - entering manually.
Approx 4 secs per line - pasting in.

>
> Is there a point where adding new lines becomes slower?
No, not really. Becomes noticeable after c.15 lines and gets worse
from there.

>
>
>
> Also try the same operations running the client on the server, what
are
> the figures then?
Entering PO (112 lines): 22mins
Entering SO (90 lines): 10 mins
Didn't try a Goods Received - too painful!

>
>
>
> Regards,
>
> Stephen Edginton
>
>
>





[Non-text portions of this message have been removed]
23
Hello Stephen,



You are correct concerning the .pf and .lg files. I had assumed the latter
since the file followed your question concerning DB buffers. Yes, spin
lock retries are a system of semaphores and queues used to manage access to
shared memory data structures. Setting the value too low results in stalled
processes the net effect of which is to reduce or even eliminate the
effectiveness of multiple processor resources. You are correct, it is not
a processor affinity parameter.



Regards,



Michael





Michael Barry
Aspacia Systems Inc
866.566.9600
312.803.0730 fax
<http://www.aspacia.com/> http://www.aspacia.com/






From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf Of
Stephen Edginton
Sent: Friday, July 20, 2007 2:36 PM
To: vantage@yahoogroups.com
Subject: RE: [Vantage] Re: Vantage 8.03 Speed Issue



Hi Michael,

Your comments are correct....however I have a few
questions....

How did you determine that there were no BI buffers
allocated from only the pf file or the spinlock retires were not set?
These are not parameters of the appservers but the Database itself (the
mfgsys,lg will give us a log of these settings)

Your comments regarding the APW are valid, I would also
add, increasing the blocksize of the BI buffers which helps along with
your APW recommendations.

Lastly the comment regarding limiting the resources to a
single CPU by setting the spin lock retries..... This is just a
mechanism for locking reties not processor affinity unless I am
mistaken..?

Regards,

Stephen Edginton

From: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
[mailto:vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com> ] On
Behalf
Of Michael Barry
Sent: 20 July 2007 22:20
To: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
Subject: RE: [Vantage] Re: Vantage 8.03 Speed Issue

Nigel,

In addition to the previous poster's observations, it also appears that
you
have no BI buffers allocated and are not using spin lock retries. Also,
how
may asynchronous page writers do you have configured? It is entirely
possible that the BI log is simply being overrun with write requests and
is
unbuffered placing the entire burden upon your I/O subsystem which, as
others have correctly pointed out, is a highly non-optimal configuration
for
write intensive applications. Set you BI Buffers to a minimum of 25 and
start from there. Additionally, make sure your spin lock retries is set
to
approximately 20000 per processor or you will be effectively limiting
the
database to the resources of a single CPU.

Good Luck,

Michael

Michael Barry
Aspacia Systems Inc
866.566.9600
312.803.0730 fax
<http://www.aspacia.com/> http://www.aspacia.com/

This email, and any attachments thereto, is intended only for use by the
addressee(s) named herein and may contain legally privileged and/or
confidential information. If you are not the intended recipient of this
email, you are hereby notified that any dissemination, distribution or
copying of this email, and any attachments thereto, is strictly
prohibited.
If you have received this email in error, please immediately notify me
by
telephone and permanently delete the original and any copy of any email
and
any printout thereof.

From: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
<mailto:vantage%40yahoogroups.com>
[mailto:vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
<mailto:vantage%40yahoogroups.com> ] On
Behalf Of
Nigel Kerley
Sent: Friday, July 20, 2007 1:15 PM
To: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
<mailto:vantage%40yahoogroups.com>
Subject: [Vantage] Re: Vantage 8.03 Speed Issue

Hi Stephen,

Answers below.

Nigel.

--- In vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
<mailto:vantage%40yahoogroups.com>
<mailto:vantage%40yahoogroups.com> , "Stephen
Edginton" <stephene@...>
wrote:
>
> Hi Nigel,
>
>
>
> What patch are you running?
We're on 305H.

>
> Number of users?
Approx 30 users in Europe, 15 in USA. The USA office is 8 hours
behind Europe so the overlap is no more than 2 hours.

>
> What is the speed to retrieve these entries i.e pull up in order
entry,
> po entry?
To pull up SO: 15secs (133 lines), PO: 23secs (112 lines), PO
Receipt: 15secs (112 lines)

>
> Did you experience the same speed during piloting of these larger
> orders?
I suspect we didn't create large enough docs during testing.

>
> What is your disk configuration?
Application, OpenEdge and OS are on a Raid5 array. The DB itself is
on a seperate mirror array.

>
> Can you post your .pf file and how much of the DB are you buffering?
.pf file:
"-Mm 4096 -mmax 65534 -Bt 5000 -s 200 -yy 1970 -stsh 31 -inp 32000 -
tok 4000 -TB 31 -TM 32 -D 500 -l 13000
-T d:\epicor\mfgwrk803
-db f:\epicor\mfgsys803\db\mfgsys
-cpinternal utf-8 -cpstream utf-8 -cprcodein utf-8"

Blocks in DB buffer = 20,000.

>
> Are you running other services on the server?
SQL is running on the same server, but not for any intensive tasks.
It has been configured to only use 1 processor and 1GB of RAM.

>
>
> What is the average speed to add a line initially?
Approx 5 secs per line - entering manually.
Approx 4 secs per line - pasting in.

>
> Is there a point where adding new lines becomes slower?
No, not really. Becomes noticeable after c.15 lines and gets worse
from there.

>
>
>
> Also try the same operations running the client on the server, what
are
> the figures then?
Entering PO (112 lines): 22mins
Entering SO (90 lines): 10 mins
Didn't try a Goods Received - too painful!

>
>
>
> Regards,
>
> Stephen Edginton
>
>
>

[Non-text portions of this message have been removed]





[Non-text portions of this message have been removed]
24
Over the weekend, when no-one else was logged on, I timed the
creation of a Sales Order (11mins) and Purchases Order 27(mins) -
each with 112 lines. (The SO time matches Stephen's reference time.)

I changed the database config:
Blocks in DB buffer - changed from 20,000 to 200,000 (we use 8k
blocks)
Moved temp directory to Raid1 array
(Stopped/started DB and Appservers)

Re-tested - absolutely no change in times.

Made more adjustments:
Changed -Mm back to 1024
Changed Spin Lock Retries from 4,000 to 40,000
(Stopped/started DB and Appservers)

Re-tested - absolutely no change in times.

BI Buffers are already at 25 and APWs are set to 6.

I'll get the US office to re-test during the day with these new
settings and see if it makes any difference to them.

Apart from that, I guess I'll just have to wait for Epicor's comments.

Many thanks for all your suggestions.

Regards,

Nigel.
25
One thing that we tried in our Vantage 8 implementation that made a
massive difference, was dumping and loading our database. It had been
in existance since the year 2000 and never had any maintenance done
to it.

It did make a big difference, but it was still far slower than our
Vantage 4.0 installation. However, our company was bought out a few
months ago so no more Vantage. Got to look forward to BAAN now...

Jonathan


--- In vantage@yahoogroups.com, "Nigel Kerley" <nkerley@...> wrote:
>
> I know that the speed issue has come up a number of times before,
but
> we are starting to have really serious issues with it. So much so
> that if they aren't solved we may have to drop Vantage.
>
> We are a group of 4 companies. As we rolled out each company we
knew
> that speed was going to be a issue, but we thought we could live
with
> it. Earlier this year we rolled out to the final company. This
> company has the largest number of transactions per document, and
> overall, within the group which is why the problem has now come to
a
> head.
>
> We are recording the following data entry times:
> Sales Order entry: average 6 mins for 42 lines (up to 16 mins for
112
> lines)
> Purchase Order entry: 20 mins for 112 lines
> Good Received entry: 31 mins for 112 lines (one user recorded a
time
> of 3 HOURS for 192 lines)
>
> Our Vantage server is well speced: dual Xeon 3.2Ghz, 8GB Ram,
> 15000rpm HD, Win 2003. We are running on Progress.
>
> Is anyone else out there having anywhere near the problem we are?
>
> Thanks in advance,
>
> Nigel Kerley
> The Hinde Group
>
26
With all due respect to the DBAs & 'hardware heads' out there, the speed issue is likely NOT a db/server issue. (Heck - B-treive, Foxpro or D-base db's running on late 1980's hardware gave sufficient performance to outperform what your timings indicate - and what our piloting is revealing.)

It is the poorly speed (& memory) optimized UI entry applications and/or the tranlsation layer apps responsible for triggering the db updates...

I suspect Vantage programmers were under EXTREME pressure just to get sufficiently functional/acceptably bug-free V8 .NET code out by deadline... No WAY they had time to memory/speed optimize all of the code objects being called.

My gut tells me the "any day now'" 8.04 release won't address the performance issues (except perhaps in the most blatantly complained about apps). From what I've experienced so far with Vantage 'corporate think', 8.04 is likely just intended to put to rest the nagging bugs still in 8.03.

Maybe V9 (after it goes thru a few dot releases to fix the slew of bugs any major rewrite will have)...

You get what you pay for - and if you are on this forum - you 'got' Vantage (and likely got it because it is comparatively cheap).

Rob Brown
Versa Products


Nigel Kerley <nigel.kerley@...> wrote:
Over the weekend, when no-one else was logged on, I timed the
creation of a Sales Order (11mins) and Purchases Order 27(mins) -
each with 112 lines. (The SO time matches Stephen's reference time.)

I changed the database config:
Blocks in DB buffer - changed from 20,000 to 200,000 (we use 8k
blocks)
Moved temp directory to Raid1 array
(Stopped/started DB and Appservers)

Re-tested - absolutely no change in times.

Made more adjustments:
Changed -Mm back to 1024
Changed Spin Lock Retries from 4,000 to 40,000
(Stopped/started DB and Appservers)

Re-tested - absolutely no change in times.

BI Buffers are already at 25 and APWs are set to 6.

I'll get the US office to re-test during the day with these new
settings and see if it makes any difference to them.

Apart from that, I guess I'll just have to wait for Epicor's comments.

Many thanks for all your suggestions.

Regards,

Nigel.






---------------------------------
Moody friends. Drama queens. Your life? Nope! - their life, your story.
Play Sims Stories at Yahoo! Games.

[Non-text portions of this message have been removed]
27
I would agree that it is not completely a server/db issue. But judging
by the set-up recommendations people have made it would help a little.
There is no question that code isn't optimized.



I don't know of the "any day now 8.04" release you're talking about.
The next release is going to be 8.03.40X, probably in September. This
release will upgrade to OpenEdge 10.1 and .Net 3.0, which still might
have optimized code for the processes discussed in this thread, but it
is quicker.



From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf
Of Robert Brown
Sent: Monday, July 23, 2007 10:45 AM
To: vantage@yahoogroups.com
Subject: Re: [Vantage] Re: Vantage 8.03 Speed Issue



With all due respect to the DBAs & 'hardware heads' out there, the speed
issue is likely NOT a db/server issue. (Heck - B-treive, Foxpro or
D-base db's running on late 1980's hardware gave sufficient performance
to outperform what your timings indicate - and what our piloting is
revealing.)

It is the poorly speed (& memory) optimized UI entry applications and/or
the tranlsation layer apps responsible for triggering the db updates...

I suspect Vantage programmers were under EXTREME pressure just to get
sufficiently functional/acceptably bug-free V8 .NET code out by
deadline... No WAY they had time to memory/speed optimize all of the
code objects being called.

My gut tells me the "any day now'" 8.04 release won't address the
performance issues (except perhaps in the most blatantly complained
about apps). From what I've experienced so far with Vantage 'corporate
think', 8.04 is likely just intended to put to rest the nagging bugs
still in 8.03.

Maybe V9 (after it goes thru a few dot releases to fix the slew of bugs
any major rewrite will have)...

You get what you pay for - and if you are on this forum - you 'got'
Vantage (and likely got it because it is comparatively cheap).

Rob Brown
Versa Products


Nigel Kerley <nigel.kerley@...
<mailto:nigel.kerley%40johnhinde.com> > wrote:
Over the weekend, when no-one else was logged on, I timed the
creation of a Sales Order (11mins) and Purchases Order 27(mins) -
each with 112 lines. (The SO time matches Stephen's reference time.)

I changed the database config:
Blocks in DB buffer - changed from 20,000 to 200,000 (we use 8k
blocks)
Moved temp directory to Raid1 array
(Stopped/started DB and Appservers)

Re-tested - absolutely no change in times.

Made more adjustments:
Changed -Mm back to 1024
Changed Spin Lock Retries from 4,000 to 40,000
(Stopped/started DB and Appservers)

Re-tested - absolutely no change in times.

BI Buffers are already at 25 and APWs are set to 6.

I'll get the US office to re-test during the day with these new
settings and see if it makes any difference to them.

Apart from that, I guess I'll just have to wait for Epicor's comments.

Many thanks for all your suggestions.

Regards,

Nigel.

---------------------------------
Moody friends. Drama queens. Your life? Nope! - their life, your story.
Play Sims Stories at Yahoo! Games.

[Non-text portions of this message have been removed]





[Non-text portions of this message have been removed]
28
Nigel,

Did you see any differences in the Day when there was
some load on the system?

In your previous post you mentioned some users had to wait elongated
periods of time was there any noticeable improvements in your
configuration with these changes?



Regards,

Stephen



From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf
Of Nigel Kerley
Sent: 23 July 2007 09:16
To: vantage@yahoogroups.com
Subject: [Vantage] Re: Vantage 8.03 Speed Issue



Over the weekend, when no-one else was logged on, I timed the
creation of a Sales Order (11mins) and Purchases Order 27(mins) -
each with 112 lines. (The SO time matches Stephen's reference time.)

I changed the database config:
Blocks in DB buffer - changed from 20,000 to 200,000 (we use 8k
blocks)
Moved temp directory to Raid1 array
(Stopped/started DB and Appservers)

Re-tested - absolutely no change in times.

Made more adjustments:
Changed -Mm back to 1024
Changed Spin Lock Retries from 4,000 to 40,000
(Stopped/started DB and Appservers)

Re-tested - absolutely no change in times.

BI Buffers are already at 25 and APWs are set to 6.

I'll get the US office to re-test during the day with these new
settings and see if it makes any difference to them.

Apart from that, I guess I'll just have to wait for Epicor's comments.

Many thanks for all your suggestions.

Regards,

Nigel.



[Non-text portions of this message have been removed]
29
I've never timed it but yeah, anything with more than 20+ lines takes forever. It has nothing to do with retrieving the information either. It all has to do with the "Saving" portion of it. It's like it wants to write to 30 different tables for each line item each time something changes. Good luck getting support, they just want you send in all your data. How hard can it be to duplicate this obvious problem?


----- Original Message ----
From: Nigel Kerley <nkerley@...>
To: vantage@yahoogroups.com
Sent: Friday, July 20, 2007 12:12:57 PM
Subject: [Vantage] Vantage 8.03 Speed Issue

I know that the speed issue has come up a number of times before, but
we are starting to have really serious issues with it. So much so
that if they aren't solved we may have to drop Vantage.

We are a group of 4 companies. As we rolled out each company we knew
that speed was going to be a issue, but we thought we could live with
it. Earlier this year we rolled out to the final company. This
company has the largest number of transactions per document, and
overall, within the group which is why the problem has now come to a
head.

We are recording the following data entry times:
Sales Order entry: average 6 mins for 42 lines (up to 16 mins for 112
lines)
Purchase Order entry: 20 mins for 112 lines
Good Received entry: 31 mins for 112 lines (one user recorded a time
of 3 HOURS for 192 lines)

Our Vantage server is well speced: dual Xeon 3.2Ghz, 8GB Ram,
15000rpm HD, Win 2003. We are running on Progress.

Is anyone else out there having anywhere near the problem we are?

Thanks in advance,

Nigel Kerley
The Hinde Group






____________________________________________________________________________________
Pinpoint customers who are looking for what you sell.
http://searchmarketing.yahoo.com/

[Non-text portions of this message have been removed]
30
Hi Stephen,

There was an improvement in the times. They vary but, on average,
seemed closed to the 10 lines per minute I got on testing. However
one of the things I'm looking into is whether our Terminal Server has
sufficient resources - Vantage being the memory hog that it is. I'm
wondering if some of the poorer results occur when the TS is under
pressure.

On a related point, our CAM had a response from one of the head
developers in the US re SP400. It's out mid-August and "features
significant technology upgrades". This will mean that "Cut and paste
for 100 lines goes from 20mins to under 3 mins". No mention of other
general speed increases.

We live in hope!

Regards,

Nigel.




--- In vantage@yahoogroups.com, "Stephen Edginton" <stephene@...>
wrote:
>
> Nigel,
>
> Did you see any differences in the Day when there
was
> some load on the system?
>
> In your previous post you mentioned some users had to wait elongated
> periods of time was there any noticeable improvements in your
> configuration with these changes?
>
>
>
> Regards,
>
> Stephen
>
>
>
> From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On
Behalf
> Of Nigel Kerley
> Sent: 23 July 2007 09:16
> To: vantage@yahoogroups.com
> Subject: [Vantage] Re: Vantage 8.03 Speed Issue
>
>
>
> Over the weekend, when no-one else was logged on, I timed the
> creation of a Sales Order (11mins) and Purchases Order 27(mins) -
> each with 112 lines. (The SO time matches Stephen's reference time.)
>
> I changed the database config:
> Blocks in DB buffer - changed from 20,000 to 200,000 (we use 8k
> blocks)
> Moved temp directory to Raid1 array
> (Stopped/started DB and Appservers)
>
> Re-tested - absolutely no change in times.
>
> Made more adjustments:
> Changed -Mm back to 1024
> Changed Spin Lock Retries from 4,000 to 40,000
> (Stopped/started DB and Appservers)
>
> Re-tested - absolutely no change in times.
>
> BI Buffers are already at 25 and APWs are set to 6.
>
> I'll get the US office to re-test during the day with these new
> settings and see if it makes any difference to them.
>
> Apart from that, I guess I'll just have to wait for Epicor's
comments.
>
> Many thanks for all your suggestions.
>
> Regards,
>
> Nigel.
>
>
>
> [Non-text portions of this message have been removed]
>
31
What is the specification of your Terminal server?

You may find it's a result of paging on the server.

Can any beta testers confirm the copy and paste speed improvements
mentioned...



From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf
Of Nigel Kerley
Sent: 25 July 2007 09:47
To: vantage@yahoogroups.com
Subject: [Vantage] Re: Vantage 8.03 Speed Issue



Hi Stephen,

There was an improvement in the times. They vary but, on average,
seemed closed to the 10 lines per minute I got on testing. However
one of the things I'm looking into is whether our Terminal Server has
sufficient resources - Vantage being the memory hog that it is. I'm
wondering if some of the poorer results occur when the TS is under
pressure.

On a related point, our CAM had a response from one of the head
developers in the US re SP400. It's out mid-August and "features
significant technology upgrades". This will mean that "Cut and paste
for 100 lines goes from 20mins to under 3 mins". No mention of other
general speed increases.

We live in hope!

Regards,

Nigel.

--- In vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com> ,
"Stephen Edginton" <stephene@...>
wrote:
>
> Nigel,
>
> Did you see any differences in the Day when there
was
> some load on the system?
>
> In your previous post you mentioned some users had to wait elongated
> periods of time was there any noticeable improvements in your
> configuration with these changes?
>
>
>
> Regards,
>
> Stephen
>
>
>
> From: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
[mailto:vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com> ] On
Behalf
> Of Nigel Kerley
> Sent: 23 July 2007 09:16
> To: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
> Subject: [Vantage] Re: Vantage 8.03 Speed Issue
>
>
>
> Over the weekend, when no-one else was logged on, I timed the
> creation of a Sales Order (11mins) and Purchases Order 27(mins) -
> each with 112 lines. (The SO time matches Stephen's reference time.)
>
> I changed the database config:
> Blocks in DB buffer - changed from 20,000 to 200,000 (we use 8k
> blocks)
> Moved temp directory to Raid1 array
> (Stopped/started DB and Appservers)
>
> Re-tested - absolutely no change in times.
>
> Made more adjustments:
> Changed -Mm back to 1024
> Changed Spin Lock Retries from 4,000 to 40,000
> (Stopped/started DB and Appservers)
>
> Re-tested - absolutely no change in times.
>
> BI Buffers are already at 25 and APWs are set to 6.
>
> I'll get the US office to re-test during the day with these new
> settings and see if it makes any difference to them.
>
> Apart from that, I guess I'll just have to wait for Epicor's
comments.
>
> Many thanks for all your suggestions.
>
> Regards,
>
> Nigel.
>
>
>
> [Non-text portions of this message have been removed]
>



[Non-text portions of this message have been removed]
32
Hi Stephen,

The TS has Dual Xeon 2.8GHz, 4GB RAM, Win Server 2003 Std, RAID5
array partitioned into C: & D: with a paging file on each 2Gb-4GB.

Nigel.


--- In vantage@yahoogroups.com, "Stephen Edginton" <stephene@...>
wrote:
>
> What is the specification of your Terminal server?
>
> You may find it's a result of paging on the server.
>
> Can any beta testers confirm the copy and paste speed improvements
> mentioned...
>
>
>
> From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On
Behalf
> Of Nigel Kerley
> Sent: 25 July 2007 09:47
> To: vantage@yahoogroups.com
> Subject: [Vantage] Re: Vantage 8.03 Speed Issue
>
>
>
> Hi Stephen,
>
> There was an improvement in the times. They vary but, on average,
> seemed closed to the 10 lines per minute I got on testing. However
> one of the things I'm looking into is whether our Terminal Server
has
> sufficient resources - Vantage being the memory hog that it is. I'm
> wondering if some of the poorer results occur when the TS is under
> pressure.
>
> On a related point, our CAM had a response from one of the head
> developers in the US re SP400. It's out mid-August and "features
> significant technology upgrades". This will mean that "Cut and
paste
> for 100 lines goes from 20mins to under 3 mins". No mention of
other
> general speed increases.
>
> We live in hope!
>
> Regards,
>
> Nigel.
>
> --- In vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com> ,
> "Stephen Edginton" <stephene@>
> wrote:
> >
> > Nigel,
> >
> > Did you see any differences in the Day when there
> was
> > some load on the system?
> >
> > In your previous post you mentioned some users had to wait
elongated
> > periods of time was there any noticeable improvements in your
> > configuration with these changes?
> >
> >
> >
> > Regards,
> >
> > Stephen
> >
33
Again,

I would not recommend Raid 5, having the C and D volume
with two page files would not provide any performance gains.



From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf
Of Nigel Kerley
Sent: 25 July 2007 10:42
To: vantage@yahoogroups.com
Subject: [Vantage] Re: Vantage 8.03 Speed Issue



Hi Stephen,

The TS has Dual Xeon 2.8GHz, 4GB RAM, Win Server 2003 Std, RAID5
array partitioned into C: & D: with a paging file on each 2Gb-4GB.

Nigel.

--- In vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com> ,
"Stephen Edginton" <stephene@...>
wrote:
>
> What is the specification of your Terminal server?
>
> You may find it's a result of paging on the server.
>
> Can any beta testers confirm the copy and paste speed improvements
> mentioned...
>
>
>
> From: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
[mailto:vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com> ] On
Behalf
> Of Nigel Kerley
> Sent: 25 July 2007 09:47
> To: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
> Subject: [Vantage] Re: Vantage 8.03 Speed Issue
>
>
>
> Hi Stephen,
>
> There was an improvement in the times. They vary but, on average,
> seemed closed to the 10 lines per minute I got on testing. However
> one of the things I'm looking into is whether our Terminal Server
has
> sufficient resources - Vantage being the memory hog that it is. I'm
> wondering if some of the poorer results occur when the TS is under
> pressure.
>
> On a related point, our CAM had a response from one of the head
> developers in the US re SP400. It's out mid-August and "features
> significant technology upgrades". This will mean that "Cut and
paste
> for 100 lines goes from 20mins to under 3 mins". No mention of
other
> general speed increases.
>
> We live in hope!
>
> Regards,
>
> Nigel.
>
> --- In vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
<mailto:vantage%40yahoogroups.com> ,
> "Stephen Edginton" <stephene@>
> wrote:
> >
> > Nigel,
> >
> > Did you see any differences in the Day when there
> was
> > some load on the system?
> >
> > In your previous post you mentioned some users had to wait
elongated
> > periods of time was there any noticeable improvements in your
> > configuration with these changes?
> >
> >
> >
> > Regards,
> >
> > Stephen
> >





[Non-text portions of this message have been removed]
34
When pasting large journal entries (100 lines or more) we noticed
that the paste slowed down as more lines were entered. If we then
entered another large JE, it started as the same slow pace that the
prior one ended on, and then slowed from there, until it locked up.
If we exited Vantage, and then started pasting a new journal, it
started out fast again. We found that after each large paste, we
needed to exit and then come back in again. Is this related and any
idea why exiting would speed up the process?

--- In vantage@yahoogroups.com, "Stephen Edginton" <stephene@...>
wrote:
>
> Nigel,
>
> Did you see any differences in the Day when there
was
> some load on the system?
>
> In your previous post you mentioned some users had to wait elongated
> periods of time was there any noticeable improvements in your
> configuration with these changes?
>
>
>
> Regards,
>
> Stephen
>
>
>
> From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On
Behalf
> Of Nigel Kerley
> Sent: 23 July 2007 09:16
> To: vantage@yahoogroups.com
> Subject: [Vantage] Re: Vantage 8.03 Speed Issue
>
>
>
> Over the weekend, when no-one else was logged on, I timed the
> creation of a Sales Order (11mins) and Purchases Order 27(mins) -
> each with 112 lines. (The SO time matches Stephen's reference time.)
>
> I changed the database config:
> Blocks in DB buffer - changed from 20,000 to 200,000 (we use 8k
> blocks)
> Moved temp directory to Raid1 array
> (Stopped/started DB and Appservers)
>
> Re-tested - absolutely no change in times.
>
> Made more adjustments:
> Changed -Mm back to 1024
> Changed Spin Lock Retries from 4,000 to 40,000
> (Stopped/started DB and Appservers)
>
> Re-tested - absolutely no change in times.
>
> BI Buffers are already at 25 and APWs are set to 6.
>
> I'll get the US office to re-test during the day with these new
> settings and see if it makes any difference to them.
>
> Apart from that, I guess I'll just have to wait for Epicor's
comments.
>
> Many thanks for all your suggestions.
>
> Regards,
>
> Nigel.
>
>
>
> [Non-text portions of this message have been removed]
>
35
FYI - Just pasted inserted 112 lines in 8.03.401 it took 3 min. It
takes 4 sec to load the SO and 5 sec to save it. The server was a
3.4 with 2 gig. Server 2003, Progress.

--- In vantage@yahoogroups.com, "Stephen Edginton" <stephene@...>
wrote:
>
> For Reference,
>
> On a Test 8.00 server (4GB ram Dual core Xeons) I
got
> the following results for sales order entry
>
> Note the CPU usage and Ram usage on the client was quite high - a
> terminal server, 1GB network
>
>
>
> Time (minutes) Lines
>
> 1 19
>
> 2 34
>
> 3 48
>
> 4 60
>
> 5 70
>
> 6 80
>
> 7 88
>
> 8 96
>
> 9 103
>
> 10 110
>
> 11 117
>
> 12 122
>
> 13 128
>
> 14 131
>
>
>
> This was through paste insert
>
> To load the order up again took 6 seconds
>
> Modifying and saving another item took 5 seconds.
>
>
>
>
>
> Regards,
>
> Stephen Edginton
>
>
>
>
>
> From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On
Behalf
> Of Paul V. Blais
> Sent: 20 July 2007 18:23
> To: vantage@yahoogroups.com
> Subject: RE: [Vantage] Vantage 8.03 Speed Issue
>
>
>
> From my experience it is much quicker but we do nowhere as many
lines on
> orders as the original poster. I would contact my CAM and try and
get
> in touch with Ben Nixon from Epicor to resolve any speed issues.
>
> From: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
> [mailto:vantage@yahoogroups.com <mailto:vantage%
40yahoogroups.com> ] On
> Behalf
> Of Chris Robisch
> Sent: Friday, July 20, 2007 1:13 PM
> To: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
> Subject: Re: [Vantage] Vantage 8.03 Speed Issue
>
> I'd especially like to hear from the 8.03.400 beta clients on
speed...
>
> ----- Original Message -----
> From: "Nigel Kerley" <nkerley@... <mailto:nkerley%40iol.ie>
> <mailto:nkerley%40iol.ie> >
> To: <vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
> <mailto:vantage%40yahoogroups.com> >
> Sent: Friday, July 20, 2007 9:12 AM
> Subject: [Vantage] Vantage 8.03 Speed Issue
>
> I know that the speed issue has come up a number of times before,
but we
> are starting to have really serious issues with it. So much so that
if
> they aren't solved we may have to drop Vantage.
>
> We are a group of 4 companies. As we rolled out each company we knew
> that speed was going to be a issue, but we thought we could live
with
> it. Earlier this year we rolled out to the final company. This
company
> has the largest number of transactions per document, and overall,
within
> the group which is why the problem has now come to a
> head.
>
> We are recording the following data entry times:
> Sales Order entry: average 6 mins for 42 lines (up to 16 mins for
112
> lines)
> Purchase Order entry: 20 mins for 112 lines
> Good Received entry: 31 mins for 112 lines (one user recorded a
time of
> 3 HOURS for 192 lines)
>
> Our Vantage server is well speced: dual Xeon 3.2Ghz, 8GB Ram,
15000rpm
> HD, Win 2003. We are running on Progress.
>
> Is anyone else out there having anywhere near the problem we are?
>
>
>
>
>
>
>
> [Non-text portions of this message have been removed]
>
36
Nice,

That seems a bit better!



From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf
Of cbamancov
Sent: 25 July 2007 16:04
To: vantage@yahoogroups.com
Subject: [Vantage] Re: Vantage 8.03 Speed Issue



FYI - Just pasted inserted 112 lines in 8.03.401 it took 3 min. It
takes 4 sec to load the SO and 5 sec to save it. The server was a
3.4 with 2 gig. Server 2003, Progress.

--- In vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com> ,
"Stephen Edginton" <stephene@...>
wrote:
>
> For Reference,
>
> On a Test 8.00 server (4GB ram Dual core Xeons) I
got
> the following results for sales order entry
>
> Note the CPU usage and Ram usage on the client was quite high - a
> terminal server, 1GB network
>
>
>
> Time (minutes) Lines
>
> 1 19
>
> 2 34
>
> 3 48
>
> 4 60
>
> 5 70
>
> 6 80
>
> 7 88
>
> 8 96
>
> 9 103
>
> 10 110
>
> 11 117
>
> 12 122
>
> 13 128
>
> 14 131
>
>
>
> This was through paste insert
>
> To load the order up again took 6 seconds
>
> Modifying and saving another item took 5 seconds.
>
>
>
>
>
> Regards,
>
> Stephen Edginton
>
>
>
>
>
> From: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
[mailto:vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com> ] On
Behalf
> Of Paul V. Blais
> Sent: 20 July 2007 18:23
> To: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
> Subject: RE: [Vantage] Vantage 8.03 Speed Issue
>
>
>
> From my experience it is much quicker but we do nowhere as many
lines on
> orders as the original poster. I would contact my CAM and try and
get
> in touch with Ben Nixon from Epicor to resolve any speed issues.
>
> From: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
<mailto:vantage%40yahoogroups.com>
> [mailto:vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
<mailto:vantage%
40yahoogroups.com> ] On
> Behalf
> Of Chris Robisch
> Sent: Friday, July 20, 2007 1:13 PM
> To: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
<mailto:vantage%40yahoogroups.com>
> Subject: Re: [Vantage] Vantage 8.03 Speed Issue
>
> I'd especially like to hear from the 8.03.400 beta clients on
speed...
>
> ----- Original Message -----
> From: "Nigel Kerley" <nkerley@... <mailto:nkerley%40iol.ie>
> <mailto:nkerley%40iol.ie> >
> To: <vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
<mailto:vantage%40yahoogroups.com>
> <mailto:vantage%40yahoogroups.com> >
> Sent: Friday, July 20, 2007 9:12 AM
> Subject: [Vantage] Vantage 8.03 Speed Issue
>
> I know that the speed issue has come up a number of times before,
but we
> are starting to have really serious issues with it. So much so that
if
> they aren't solved we may have to drop Vantage.
>
> We are a group of 4 companies. As we rolled out each company we knew
> that speed was going to be a issue, but we thought we could live
with
> it. Earlier this year we rolled out to the final company. This
company
> has the largest number of transactions per document, and overall,
within
> the group which is why the problem has now come to a
> head.
>
> We are recording the following data entry times:
> Sales Order entry: average 6 mins for 42 lines (up to 16 mins for
112
> lines)
> Purchase Order entry: 20 mins for 112 lines
> Good Received entry: 31 mins for 112 lines (one user recorded a
time of
> 3 HOURS for 192 lines)
>
> Our Vantage server is well speced: dual Xeon 3.2Ghz, 8GB Ram,
15000rpm
> HD, Win 2003. We are running on Progress.
>
> Is anyone else out there having anywhere near the problem we are?
>
>
>






[Non-text portions of this message have been removed]