Question Deployment issues

[Paul Pichette]

I have installed a small Progress database running on 9.1D on a Windows 7 Ultimate PC it runs fine locally.

I setup a database server running with TCPIP & service.

-B is set to 200000
-spin 50000
BI Cluster size 524288
BI Block Size 8192
DB Block Size is 4096

I setup the same 9.1D on a Windows 8 PC, connecting to the server and the performance to fetch data is horrible. It's a small application with little data being transferred at all.

Stating the obvious, 9.1D is quite obsolete, but are there some key things to do to make 9.1 systems run under newer versions of Windows?

 

[Rob Fitzpatrick]

Some questions/observations:

• What is the size of your "small" database?
• Is there a reason why you're using an ancient, buggy, unsupported version of Progress on new(ish) operating systems?
• What is the database license in use: Personal, Workgroup, or Enterprise?
• Which DB background processes are in use, if any?
  
• What are the rest of the database startup parameters you have specified, in each database? Are they set at the defaults?
  
• When you say "it runs fine locally" on Windows 7, does that mean your clients are connecting self-service rather than via TCP?
• Are the Windows 8 client connections TCP?
• Where do the clients run in each case?
• If across a network, what is the network bandwidth?
• What kind of storage is in use in each case?
• Are these machines physical or virtual?
  
• What can you tell us about the hardware? (RAM, cores, etc.)
• You have allocated roughly 840 MB of shared memory; is your RAM overcommitted? Is there excessive paging?
• What do you see on Windows 8 in perfmon when your I/O is "horrible"?
• What other application or I/O workload is on each of the systems?
• Do they run scheduled tasks that may impact your application?
• Do they run a virus scanner?
  
• You are running server software on a PC, and old software at that. That's always going to be non-optimal.
• What type of application workload are you running? Is it read-heavy? Write-heavy?
  
• Is the code "pure" 4GL or does it interact with the OS? (e.g. referencing DLL functions, COM interop, OS-COMMAND, etc.)

 

[Paul Pichette]

• What is the size of your "small" database?
  • roughly 20MB
• Is there a reason why you're using an ancient, buggy, unsupported version of Progress on new(ish) operating systems?
  • Yes. it doesn't cost anything.
• What is the database license in use: Personal, Workgroup, or Enterprise?
  • I think it's workgroup
• Which DB background processes are in use, if any?
  • None
• What are the rest of the database startup parameters you have specified, in each database? Are they set at the defaults?
  • Yes, defaults
• When you say "it runs fine locally" on Windows 7, does that mean your clients are connecting self-service rather than via TCP?
  • No, it runs locally in TCP
• Are the Windows 8 client connections TCP?
  • Yes. I tried with another PC running on Vista, and it is MUCH faster but it's wired ethernet, with the same connection parameters.
• Where do the clients run in each case?
  • There's only 2 PCs connected now, that and the main Windows 7 server PC.
• If across a network, what is the network bandwidth?
  • If i check the network wireless, it is running at about
• What kind of storage is in use in each case?
  • variable extent storage
• Are these machines physical or virtual?
  • physical
• What can you tell us about the hardware? (RAM, cores, etc.)
  • Server is a windows 7 ultimate, running on a 2x 2.40Ghz 32 bit OS,
  • PC is running on windows 8.1 Intel i5-3210 CPU 2.50GHz, 64 bit OS.
• You have allocated roughly 840 MB of shared memory; is your RAM overcommitted? Is there excessive paging?
  • Not sure what you mean by overcommitted, paging.
• What do you see on Windows 8 in perfmon when your I/O is "horrible"?
  • It's more a reflexion of running the Application, navigating on data is slow.
  • I haven't run the perfmon or dont know what to look for.
• What other application or I/O workload is on each of the systems?
  • The PC isn't running anything but the bare windows 8 stuff, the server is running only the server & a local tcp connection, running the application (prowin32.exe).
• Do they run scheduled tasks that may impact your application?
  • no
• Do they run a virus scanner?
  • I deactivated all virus scanning on the PC.
• You are running server software on a PC, and old software at that. That's always going to be non-optimal.
• What type of application workload are you running? Is it read-heavy? Write-heavy?
  • It's basically less than I would say a read on a few records, no more than 100, consisting of a day sheet of appointments, loaded into a temp table that is feeding a browser.
• Is the code "pure" 4GL or does it interact with the OS? (e.g. referencing DLL functions, COM interop, OS-COMMAND, etc.)
  • Yes, it's pure.

 

[TomBascom]

• Is there a reason why you're using an ancient, buggy, unsupported version of Progress on new(ish) operating systems?
  • Yes. it doesn't cost anything.

That is unlikely to be true. I think you're probably saying that you prefer copying an old license to paying for a new one.

• What is the database license in use: Personal, Workgroup, or Enterprise?
  • I think it's workgroup

-spin 50000 suggests that it is Enterprise

 

[Rob Fitzpatrick]

-spin 50000 suggests that it is Enterprise

Good point. With -spin 50000 the broker would shut down immediately after proserve if it were Workgroup or Personal.

 

[Paul Pichette]

I had no -spin before, in fact when I was researching performance issues, I fell on this and tried it out, but it didnt seem to help with anything...

 

[Rob Fitzpatrick]

• What is the size of your "small" database?
  • roughly 20MB
  You have 781 MB of buffer pool, for a 20 MB database. Until your database grows, you need at most 20 MB. So most of that RAM is doing nothing useful for you. You would be better to let the OS use most of it for file cache.
  
  
• What are the rest of the database startup parameters you have specified, in each database? Are they set at the defaults?
  • Yes, defaults
  It would be helpful to see, within CODE tags, the portion of your database log from the last database startup. That will provide the startup parameter values. I'm not familiar with all the defaults from 9.1D.
  
  Undoubtedly you have many non-optimal settings, but it seems that is the case on your Windows 7 PC where you say you have no complaints about performance. So rather than change more settings on the Windows 8 client it is probably best to focus on the differences between the systems.
  
  
• When you say "it runs fine locally" on Windows 7, does that mean your clients are connecting self-service rather than via TCP?
  • No, it runs locally in TCP
  How many clients connect concurrently to the database via TCP?
  
  
• Are the Windows 8 client connections TCP?
  • Yes. I tried with another PC running on Vista, and it is MUCH faster but it's wired ethernet, with the same connection parameters.
  OK, this sounds like an area you should explore. The further away you are from best practices, the less expectation you should have of good performance. As I've said, running an old database server on PC hardware won't yield optimal results. Making your application client/server, even when run locally, and running remote clients on a wireless network gives you even less reason to expect good performance.
  
  Have you tested your network? Do you know what kind of real performance your wireless network is giving you in terms of throughput and packet loss? (As opposed to what it is rated for theoretically.) What kind of throughput do you get on file transfers between the client PC and the "server"?
  
  Wireless network performance can vary significantly based on a lot of factors, including adapter type and feature set, driver quality, distance from AP, number and strength of competing signals at the same frequency (other WiFi networks, cordless phones, microwave ovens, etc.), and other connecting devices on the network (e.g. bridges, routers, hubs, switches, firewalls, etc.). WiFi is probably a poor choice for consistent performance if wired networking is also available.
  
• If across a network, what is the network bandwidth?
  • If i check the network wireless, it is running at about
  About... ?
  
  
• What kind of storage is in use in each case?
  • variable extent storage
  I meant physical storage; disks. What kind? What RAID level, if any?
  
  
• What can you tell us about the hardware? (RAM, cores, etc.)
  • Server is a windows 7 ultimate, running on a 2x 2.40Ghz 32 bit OS,
  • PC is running on windows 8.1 Intel i5-3210 CPU 2.50GHz, 64 bit OS.
  This sounds like more than enough for the application workload you describe, although you didn't answer my question about RAM.

• You have allocated roughly 840 MB of shared memory; is your RAM overcommitted? Is there excessive paging?
  • Not sure what you mean by overcommitted, paging.
  In other words: do you have a shortage of RAM? Out-paging will occur when your applications' demand for virtual memory exceeds the amount of physical memory available. In this case the OS memory manager will trim the working sets of processes, i.e. reducing their footprint in physical memory. It writes private modified process data to the operating system's paging file. If you are in this situation, application performance can suffer greatly due to increased disk I/O that might otherwise have been memory I/O.
  
• What do you see on Windows 8 in perfmon when your I/O is "horrible"?
  • It's more a reflexion of running the Application, navigating on data is slow.
  • I haven't run the perfmon or dont know what to look for.
  Run Resource Monitor (perfmon /res) or Process Explorer while your application is idle to get an idea of baseline performance. Then compare that performance to what you see during application load. On the client side, is your 4GL client process spiking the CPU? Is it doing a lot of disk I/O? Is it doing a lot of network I/O? Is the disk queue length growing substantially? Is there network packet loss? Perfmon will show you these metrics and more.
  
  Is this just a toy application you're experimenting with? Something non-critical? Then maybe you can continue with this "spare parts" approach and get it working slightly better than it is today. But it will never be great, and it will always be brittle.
  
  On the other hand, if it is a line-of-business application with value and importance to the business (and where you'd care if you lost all your data) then you should start from scratch. You get what you pay for and from what I see so far you haven't paid much if anything for the hardware, the OS, or the application licenses to make this work the way it should.
  
  Get buy-in from the business that this application and data have value, and get budget. Then spend some of it talking to a reputable consultant so you don't waste the rest of it. And worry first about getting good hardware and software and protecting your data with a good backup strategy, after imaging, and redundant storage. Then worry about performance. That's my 2 cents.

 

[Paul Pichette]

I adjusted the -B to 20000, and it seems counter-intuitive, but I will see how the system reacts to this.

I have setup 2 other PCs to the Windows 7 server.

I agree with what you mention, as this place is open to Wireless access to other people, I will need to review this thoroughly.

The wireless is running at about 144,4 Mbits/s

The disk is a Western Digital Raptor 150GB, no RAID configured.

The system is running on 2 GB of RAM.

If I run the performance monitor, there's always free memory. The system is not paging.Wireless activity is the main culprit, I can see it from the performance monitor on the Windows 8 PC. I will review the code to make sure I am sending just the bare bones data that I need.
You are completely right on all that you wrote. This is a non-critical experiment I am running, but there's real useful data, but still testing stage at this point. I guess this is going to bring me to also review how the application was developed, because I definitely see spikes whenever I simply navigate between one day of appointments to the next. thanks for your time.

 

[Cringer]

The long and the short of it is that you are using software that was designed for use in the 90's on an OS that was designed for use today. You are almost guaranteed to have issues like this.