[AccessD] A 2003 on VM Ware

Max Wanadoo max.wanadoo at gmail.com
Fri Mar 5 11:23:15 CST 2010


Jurgen, just a WAG:

In Tools/Options/Advanced Tab there are some refresh options. If these are
set very low it may be that the system is refreshing itself too often/too
soon.

Maybe?

Max
 

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jurgen Welz
Sent: Friday, March 05, 2010 4:30 PM
To: accessd at databaseadvisors.com
Subject: Re: [AccessD] A 2003 on VM Ware


John/Drew:  Thanks for the comments.  For the most part, a great deal of
common sense has been applied.  Currently their web site says they have 180
job sites and about 20 offices in Omaha, Nebraska, Washington and most of
the provinces in Canada.  Their servers in Calgary, Alberta support over
1500 users, all using the same basic environment that runs our system.  The
basic setup is well thought out now that they have a team of over 30 full
time professionals and consultants on staff.  Our 65 odd users now have a
disproportioanately high percentage of the CPU, memory and bandwidth
resources and it appears that reliance on Access and the Pervasive data
services for our estimating system are the only differences between their
1500 and our 65.  Their management interfaces are built in Powerbuilder and
ours are in Access.  We use their stuff for payroll and a good deal of the
project controls.  Everyones' data is hosted in SQL Server.  The IT
reporting tools they have tell us that Access is the problem.  Our fo rmer
environment was 4 VMWare servers for over 60 users and is now 7 servers on
better physical hardware.  As far as I know, the only real changes are that
we have upgraded estimating (Sage) a couple of versions, we have a bunch of
new Windows service packs installed (without a bank of servers to test live
they were very leery of messing with a working system so they never got
service packs) and we now have access to some applications that we haven't
started using such as P3 and P6 (Primavera).

 

We deployed to the new environment 3 weeks ago and there is no going back as
I had to upgrade over 200,000 estimate files and the downgrade path is ugly.
We have been ironing out a few loose ends, shadow copy, anti-virus, load
balancer optimization, time zone awareness...  For the most part, things are
very nice.  Nearly all our users are running Wyse thin client terminals with
dual screens via Cisco AnyConnect VPN Client and Remote Desktop.  Division
and company wide, they are making record profits in the North American
construction market notwithstanding the economy.  They had a bunch of
hardware and support dollars to throw at our issues now and fingers are
being pointed at Access as the likely culprit.

 

My philosophy has aways been that a parent form be populated by a single
record recordset and that sub forms fill on demand (John calls it Just in
Time) as a sub form takes focus.  It is exceedingly rare that a continuous
sub form contain more than 20 records and I will frequently use single
recordset non-continous sub forms to limit memory and bandwidth
requirements.  I can't imagine why a form that is open on static data while
they are writing an email and working on an Excel workbook in a person's
session would pin the CPU at 100%.  No one at their end cares to know much
about our application so they don't really understand the measures I went to
in order to make this work with mdb data.  The mdb limitations went away 1.5
years ago.  Much of the tiny data is cached in memory and displayed via
callback so the server never gets hit for tiny lookups and even so, we know
that memory is not the bottleneck.

 

I'm told that they have enough MSDN licensing to give me access to the works
so if I want to rewrite the whole shooting match, I can choose my weapon.
Also, for the first time since Access 97 was brand new, I have Admin rights
on our servers.  I also have SQL Server tools so I no longer have to make
data structure changes via DDL using MSQuery via Excel.  Unfortunately, my
title has been Safety Manager for the last few years and that role means
that Access is more and more a part time amusement.  I was pulled off other
duties to coordinate migration to the new environment and build a few new
enhancements.

Ciao Jürgen Welz 

Edmonton, Alberta jwelz at hotmail.com


 

> Date: Thu, 4 Mar 2010 20:33:57 -0500
> From: jwcolby at colbyconsulting.com
> To: accessd at databaseadvisors.com
> Subject: Re: [AccessD] A 2003 on VM Ware
> 
> Jurgen,
> 
> I think Drew might be right in that Access is supposed to sense "other 
> applications" wanting the processor and releasing the cycles. If 
> Access is all that is running inside of that VM, then it never senses 
> "other applications" wanting the cycles because those other 
> applications are isolated by the walls of the VM. Thus the VM ends up
requesting real cpu cycles to service the Access FE and essentially tying up
an entire core per FE.


> ....Snipped
> 
> John W. Colby
> www.ColbyConsulting.com
> 
>snipped


Drew Wutka wrote:
> > <soap box>
> > Virtual machines are great. It's a great way to have multiple
'computers' running without having to have hardware for each one. HOWEVER, a
virtual machine is going to inherently run slower then it's host, even with
just one VM running on the host. Each VM added to the host is going to divvy
up the already 'limited' resources. For single purpose machines, this isn't
a problem, on hefty hardware. But the key is 'single purpose'. Terminal
services, by their very nature are not 'single purpose'. And even some items
that may seem single purposes, are really too large and complex to truly
host inside a VM. Exchange servers, DB servers, etc, all can require massive
resources, so putting them on anything but a capable box by themselves can
be detrimental. The real confusion lies in the lack of understanding of what
many 'server' roles require. Plus there is the inherent 'coolness' of
virtualization.
> > 
> > But there has to be some common sense applied. I'd say the best rule of
thumb would be to ask yourself if what you want to do would work with a
server that is 5 years old. If not, it won't work well in a virtual
environment, and should be put on it's own server.
> > </soap box>
> > 
> > ;)
> > 
> > Drew

 
 		 	   		  
_________________________________________________________________
Live connected with Messenger on your phone
http://go.microsoft.com/?linkid=9712958
--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com





More information about the AccessD mailing list