Performance puzzle on Windows server

#1

Hi

We're experiencing surprisingly low performance on one of our installations.
I guess it's related
to the Windows network, but I'm not sure. I've tried various things to see
if it has any impact on
the issue.

It's a Win2000 SP4 server with P.SQL 2000i SP4.
It has a P4 2.4 GHz processor with 512MB ram.
The disk system is SCSI with RAID 5.

I'm running our application (developed with Visual DataFlex) locally on the
server.

1. When the files are read directly from physical disk, the performance is
acceptable and about
what I expect.
2. When the files are read from \\127.0.0.1\data\.... the performance is
about the same as from
physical disk. I guess this reads the data via the loopback interface.
3. When the files are read from \\servername\data\... (identical to how the
clients read the data),
the performance is drastically degraded.

Has anyone got a checklist of parameters or issues that could be applicable
in this situation?

Next on my list is checking the network adapter.

Regards
--
Sindre Solem
Senior Systems Consultant
Emma EDB AS

#2

The good news is it does not sound like it is server related.

If it is slow to connect check name resolution times.
If it is slow to run, yes check the hardware, but probably more
importantly check routing.
Is the address it connecting to routed through the public side of an
internet router?
Any extra (or slow) hops on tracerte?

Leonard

On Fri, 31 Oct 2003 15:16:16 +0100, "Sindre Solem"
<sindre.solem (AT) emmaedb (DOT) no> wrote:

Quote:

Hi

We're experiencing surprisingly low performance on one of our installations.
I guess it's related
to the Windows network, but I'm not sure. I've tried various things to see
if it has any impact on
the issue.

It's a Win2000 SP4 server with P.SQL 2000i SP4.
It has a P4 2.4 GHz processor with 512MB ram.
The disk system is SCSI with RAID 5.

I'm running our application (developed with Visual DataFlex) locally on the
server.

1. When the files are read directly from physical disk, the performance is
acceptable and about
what I expect.
2. When the files are read from \\127.0.0.1\data\.... the performance is
about the same as from
physical disk. I guess this reads the data via the loopback interface.
3. When the files are read from \\servername\data\... (identical to how the
clients read the data),
the performance is drastically degraded.

Has anyone got a checklist of parameters or issues that could be applicable
in this situation?

Next on my list is checking the network adapter.

Regards

#3

"Leonard" <lharvey (AT) austin (DOT) rr.com> skrev i melding
news:93m6qvoekqd3uv1nluhj5oa0pqibf24nc0 (AT) 4ax (DOT) com...

Quote:

The good news is it does not sound like it is server related.

That's what I figure to. Has to be network related, but I cannot see
where.

Quote:

If it is slow to connect check name resolution times.

I can't see that it's this, either. The application is running locally
(reading data
from a network share on the same server it runs on). I've put the server
name into
the hosts and lmhosts files, just to make sure that name resolution doesn't
delay
the connection.

Quote:

If it is slow to run, yes check the hardware, but probably more
importantly check routing.

Now I've even tried with a new network adapter, with the same results.

Quote:

Is the address it connecting to routed through the public side of an
internet router?

I've tried to disconnect the server entirely from the rest of the network.
And it has no effect on the performance, unfortunately.

Quote:

Any extra (or slow) hops on tracerte?

Nope.

I cannot think of anything else to check/adjust!

--
Sindre

#4

On Mon, 3 Nov 2003 16:03:24 +0100, "Sindre Solem"
<sindre.solem (AT) emmaedb (DOT) no> wrote:

Quote:

"Leonard" <lharvey (AT) austin (DOT) rr.com> skrev i melding
news:93m6qvoekqd3uv1nluhj5oa0pqibf24nc0 (AT) 4ax (DOT) com...
The good news is it does not sound like it is server related.

That's what I figure to. Has to be network related, but I cannot see
where.

If it is slow to connect check name resolution times.

I can't see that it's this, either. The application is running locally
(reading data
from a network share on the same server it runs on).

That just does not make sense to do. It also falls under the not
supported configuration. Why not point it to a local drive (or if the
data is on a data volume, reasign the data volume to the appropriate
drive letter).

Quote:

I've put the server name into
the hosts and lmhosts files, just to make sure that name resolution doesn't
delay the connection.

If it is slow to run, yes check the hardware, but probably more
importantly check routing.

Now I've even tried with a new network adapter, with the same results.

If it is server local it could be the network adapter, but not likely.
New adapter may or may not change routing, but server local is not
likely to have routing issues either.

Quote:

Is the address it connecting to routed through the public side of an
internet router?

I've tried to disconnect the server entirely from the rest of the network.
And it has no effect on the performance, unfortunately.

Any extra (or slow) hops on tracerte?

Nope.

I cannot think of anything else to check/adjust!

Going back to the original post, may just want to configure the
application to run local (local physical drive) instead of UNC. UNC
can force requests to go through the network layer

Leonard

#5

On Tue, 04 Nov 2003 04:37:39 GMT, Leonard <lharvey (AT) austin (DOT) rr.com>
wrote:

<snip>

Quote:

That just does not make sense to do. It also falls under the not
supported configuration. Why not point it to a local drive (or if the
data is on a data volume, reasign the data volume to the appropriate
drive letter).

Actually it makes a whole lot of sense. In the past I've had several
cases where it had to be configured this way to access local files
through the server engine. (no, not with the current releases)

<snip>

Quote:

If it is server local it could be the network adapter, but not likely.
New adapter may or may not change routing, but server local is not
likely to have routing issues either.

The NIC itself won't change much, unless of course it would be a
different brand. It's the driver that will make the difference

<snip>

Quote:

Going back to the original post, may just want to configure the
application to run local (local physical drive) instead of UNC. UNC
can force requests to go through the network layer

On the point of troubleshooting a network problem, that may just be
the intended action.

Gordon Bos
Q-RY Solutions
+31-(0)15-2564035

http://www.q-ry.nl/

#6

You might see something like this if you've renamed the server AFTER
installing Active Directory. Don't remember off hand, but there's a
texttool (runs in DOS box) you need to install from the original
install CD and use this to register the new name, assign the new name
to be the primary and than remove the original name.

Obviously you could also ignore the servername and create IP based
network mappings for your remotes (if it also works from there).

Gordon

On Fri, 31 Oct 2003 15:16:16 +0100, "Sindre Solem"
<sindre.solem (AT) emmaedb (DOT) no> wrote:

Quote:

Hi

We're experiencing surprisingly low performance on one of our installations.
I guess it's related
to the Windows network, but I'm not sure. I've tried various things to see
if it has any impact on
the issue.

It's a Win2000 SP4 server with P.SQL 2000i SP4.
It has a P4 2.4 GHz processor with 512MB ram.
The disk system is SCSI with RAID 5.

I'm running our application (developed with Visual DataFlex) locally on the
server.

1. When the files are read directly from physical disk, the performance is
acceptable and about
what I expect.
2. When the files are read from \\127.0.0.1\data\.... the performance is
about the same as from
physical disk. I guess this reads the data via the loopback interface.
3. When the files are read from \\servername\data\... (identical to how the
clients read the data),
the performance is drastically degraded.

Has anyone got a checklist of parameters or issues that could be applicable
in this situation?

Next on my list is checking the network adapter.

Regards

Gordon Bos
Q-RY Solutions
+31-(0)15-2564035

http://www.q-ry.nl/

#7

"Leonard" <lharvey (AT) austin (DOT) rr.com> skrev i melding
news:iqaeqvce02c8mqql018f8sod420unlqvio (AT) 4ax (DOT) com...

Quote:

If it is slow to connect check name resolution times.

I can't see that it's this, either. The application is running locally
(reading data
from a network share on the same server it runs on).

That just does not make sense to do. It also falls under the not
supported configuration. Why not point it to a local drive (or if the
data is on a data volume, reasign the data volume to the appropriate
drive letter).

It's just to get closer to the issue. The real problem is of course that the
workstations experience the performance issues. I found that the problem is
the same running just locally on the server, which I thought would be easier
to find out of. Is it really not a supported configuration, running off a
"local"
network share?

Quote:

If it is slow to run, yes check the hardware, but probably more
importantly check routing.

Now I've even tried with a new network adapter, with the same results.

If it is server local it could be the network adapter, but not likely.
New adapter may or may not change routing, but server local is not
likely to have routing issues either.

No, the new adapter did not make any difference.

Quote:

Is the address it connecting to routed through the public side of an
internet router?

I've tried to disconnect the server entirely from the rest of the
network.
And it has no effect on the performance, unfortunately.

Any extra (or slow) hops on tracerte?

Nope.

I cannot think of anything else to check/adjust!

Going back to the original post, may just want to configure the
application to run local (local physical drive) instead of UNC. UNC
can force requests to go through the network layer

That would solve the problem for running it on the server, but not on the
workstations.

My assumption was that whether the .btr files was placed on a network share
or
on a physical disk, the data would still be transferred throug tcpip on port
1583.
So the difference between these two scenarios would only be name resolution
at the
file opening.

But perhaps tcpip/1583 is only used with the SQL interface? We only use the
Btrieve
interface. Does the Btrieve interface transfer the data through the Windows
network?

--
Sindre

#8

"Gordon" <grafzerk (AT) bigfoot (DOT) no.spam.please.com> skrev i melding
news:92SnPySoyxAGqZ97zGJOXumG7GtP (AT) 4ax (DOT) com...

Quote:

You might see something like this if you've renamed the server AFTER
installing Active Directory. Don't remember off hand, but there's a
texttool (runs in DOS box) you need to install from the original
install CD and use this to register the new name, assign the new name
to be the primary and than remove the original name.

I will check this.

Quote:

Obviously you could also ignore the servername and create IP based
network mappings for your remotes (if it also works from there).

I've tried this, having no effect on the issue, unfortunately.

Thank you for the tip.

--
Sindre

#9

Karl A. Sørensen wrote:

Quote:

We had similar problems. We could not figure out why our app was so slow. It
turned out to be the RAID5 on the server. We got info that database
applications should NOT run on RAID5. Try inserting an ordinary IDE disk and
compare.

You pays your money and you takes your choice! RAID5 is not very good
at supporting fast writes while it's good for reads. It does have good
levels of fault tolerance. An ordinary IDE disk could well be faster
than a RAID array but it does so at the cost of fault tolerance. Lose
the disk, lose the data.

We run P.SQL on a single RAID5 array on Netware as it is fast enough
for our needs. We do a lot of DB reads and a much smaller number of
writes. A large amount of RAM in the server also helps!

If we needed a really fast disk system we'd look at running multiple
RAID arrays. Striping across mirror disks. If we wanted it to be
really fast we'd make up the following arrays:

Netware Sys 2 disks, RAID 1
P.SQL data volume n * 2 disks, RAID 1+0
P.SQL tx log volume 2 disks, RAID 1
other data n disks, RAID 5

Of course, to do this I'd need to be allowed to spend the money!

Guy
-- --------------------------------------------------------------------
Guy Dawson I.T. Manager Crossflight Ltd
gnues (AT) crossflight (DOT) co.uk

#10

Wouldn't you want "P.SQL tx log volume" to be RAID 0 ?

Your solution / idea seems very costly. I've played with similar
ideas, but stuck with living dangerously: RAID 5 for data that really
matters and RAID 0 for temp stuff, including P.SQL transactional log.

Glad to know I'm not the only freak around here though

Gordon

On Wed, 05 Nov 2003 13:20:41 +0000, Guy Dawson
<gnues (AT) crossflight (DOT) co.uk> wrote:

Quote:

Karl A. Sørensen wrote:
We had similar problems. We could not figure out why our app was so slow. It
turned out to be the RAID5 on the server. We got info that database
applications should NOT run on RAID5. Try inserting an ordinary IDE disk and
compare.

You pays your money and you takes your choice! RAID5 is not very good
at supporting fast writes while it's good for reads. It does have good
levels of fault tolerance. An ordinary IDE disk could well be faster
than a RAID array but it does so at the cost of fault tolerance. Lose
the disk, lose the data.

We run P.SQL on a single RAID5 array on Netware as it is fast enough
for our needs. We do a lot of DB reads and a much smaller number of
writes. A large amount of RAM in the server also helps!

If we needed a really fast disk system we'd look at running multiple
RAID arrays. Striping across mirror disks. If we wanted it to be
really fast we'd make up the following arrays:

Netware Sys 2 disks, RAID 1
P.SQL data volume n * 2 disks, RAID 1+0
P.SQL tx log volume 2 disks, RAID 1
other data n disks, RAID 5

Of course, to do this I'd need to be allowed to spend the money!

Guy
-- --------------------------------------------------------------------
Guy Dawson I.T. Manager Crossflight Ltd
gnues (AT) crossflight (DOT) co.uk

Gordon Bos
Q-RY Solutions
+31-(0)15-2564035

http://www.q-ry.nl/