Are you running a Progress application with good performance results with the following configuration? Does anything jump out as a gotcha to watch out for? I would call this a simple VM configuration.
Vmware Esxi6
Standalone host with local store
Windows server 2012 R2
OpenEdge 11.5.1 64-bit server
OpenEdge 11.5.1 32-bit
No SAN
No NAS
You don't offer that much information so the only "gotcha" I see is that you are choosing to run Windows instead of Linux. Make sure to use a vmxnet3 NIC and not an E1000. 11.5.1 32 and 64 bit cannot both be installed on thee same box. [EDIT: THIS IS WRONG: That is only supported as of 11.6.]
Tell us more about the architecture and maybe we'll have more to say.
Paul
A little bit more description as to what are you plan on running there configuration wise and number of users/database size wise would be good. Since you mentioned 2 versions of OE, I am going to assume client server would be involved here, in this case make sure your NIC adapter is not E1000, but vmxnet3. Proper CPU and memory allocation goes without saying, but again not knowing what do you plan on running there, hard to say.
Also 'standalone host' - what's going to happen when this server 'catches fire'? What I am trying to ask - what is your HA/DR solution.
To answer your original question - I am aware of customers running the above config with a good performance
send more data !!!
From experience the only gotcha is having 32 ad 64 bit on the same machine. It works in theory but getting the admin server etc configured with different ports etc is a pain in the butt. You have to do it if you are planning on using the admin server for anything so that you have the correct admin server running the relevant processes.
I agree. It would be really nice if the install had a port offset option.
Thank you for input. My intent was to isolate the question to the specific item. We have customers with various deployment configurations of our application. We have a couple sites reporting sluggish response time after moving to a new server. Our staff could not think of any reason that a standalone VM host with local storage would be the cause. Yet we thought it would be good to ask of the community if there are others using the same setup with success.
At this point the primary symptom is slow through put with TCP/IP communication. At this time the network folks are reviewing the situation for unintended setup values.
The issue is that the application is slower after migrating to a new server. Many functions are reporting to be taking twice as long to complete as they did on the old server. Running the same application function in a session on the server connected to the DB via TCP/ip is fast compared to Run the same test on a client PC running Windows 10. We are going through the process of isolating the various changes that have come into play. Old and new servers are VM’s. Old server VM is on an old host hardware and Esxi5. The new VM is on a new host with Eszi6.
I have seen this a few times with an E1000 instead of a vmxnet3.
I am waiting for a reply on the E1000 instead of a vmxnet3 topic.
Thank you.
Thank you Libor and Paul !!!! In this case the switch from E1000 to vmxnet3 was the ticket. Much better.
Glad to be of help. Which reminds me Paul still owes me a bottle of my choosing :)
Just one Libor?
what will you choose?
In regard to the topic of "E1000 instead of a vmxnet3" with Vmware Esxi6; is there an equivalent issue with the VM is configured with Hyper-V ?
I don't know if I would call it an equivalent, also depends on the host OS. There is legacy network adapter and (dynamic/no-legacy) network adapter. The latter should be used at all times, although on some hosted OS it does require Integration services (formerly synthetic drivers) to be installed. You can check what adapter is in use under the VM settings in Hyper-V manager.