David Woo (Customer) asked a question.

January 18, 2024 at 2:47 AM
How to connect OpenEdge Windows appserver to a Linux database?

I have a working 11.7 openedge database on a Windows server. There is an appserver on the Windows server that connects to the Windows database that is working perfectly.

 

For "mostly political reasons", I am tasked with moving the Windows database from the Windows server to a Linux server.

 

So is this a "legitimate configuration"? 

 

I plan on dumping the Windows data and definitions and load it into a Linux database.

 

I will start the Linux database with -S -N tcp, etc.

 

I will change the Windows appserver to point to the Linux server with -H <ip-address> -S <tcp/socket> .

 

So will the Windows appserver connect and execute code on the Linux database with just these modifications? - ie. no need to recompile the code that the Windows appserver is using to connect to the LINUX database whereas before it was connecting to a Windows database? 

 

Will there be CRC errors or any other complications?

 

Help, I'm clueless...

  • 9 answers
  • 434 views
Srinivasarao Kommineny, Tom Bascom, and Peter Judge like this.

  • Peter Judge (Consultingwerk)

    You should be just fine with your plan. The schema is not changing, by the sounds of things, and that is what will mess up CRCs and the like.

     

    Windows clients (GUI/batch/AppServer) to Linux databases is a common configuration.

     

    As for "other complications" ... performance will most likely be an issue after moving from a shared-memory DB connection to a networked DB connection. There are things you can do to help improve this, but you are very unlikely to have the same performance as before. If you can, run a performance test on the existing configuration, and then on the new configuration to see what the impact of the move is. If for no other reason than it may provide "political cover".

     

    "Things you can do" include startup parameters (on the db and the appserver client), as well as code changes (eg things like FIELDS lists on queries). There's unfortunately no simple answer/solution to this.

  • David Woo (Customer)

    Thank you for that QUICK ANSWER!

     

    One other consideration: What if the Windows Progress version does not match - ie. the Windows Progress is 11.6 or 11.5 whereas the Linux Progress version is 11.7? There are a number of these database moves and I'm not 100% all of them have Progress 11.7 - ie. there may be one or two 11.6 or 11.5s.

     

    Since it is a network connection, I thought it shouldn't matter (major version?), but I can't remember the "rules of versions"...

     

    Will it help to use the -Mm 8192 parameter on the database startup to increase the packet size? or does that have any effect at all on appserver connections?

    • Mike Fechner (Consultingwerk)

      The 11.5 or 11.6 AppServer will be able to connect to an 11.7 database - it's still the same major DB.

  • Mike Fechner (Consultingwerk)

    You should consider updating to OpenEdge 12.2 or 12.8 (release just now) and leverage the improvements in the client-server protocol (server-side joins and multi-threaded DB server processes). Although that may involve switching from classic AppServer to PASOE though.

     

    On this statement:

     

    "So will the Windows appserver connect and execute code on the Linux database with just these modifications? "

     

    Code will still be executed on the Windows machine where the AppServer resides. But queries and DB updates will happen to the DB on Linux.

  • Tom Bascom (White Star Software LLC)

    @David Woo (Customer)

     

    ​ 

    -Mm 8192 is a "good start" but there is no downside to using something larger like 16384. The maximum is 32,600. It is a maximum message size, not a fixed buffer that is always set to that size.

     

    However - there isn't much benefit unless you also change the -prefetch* parameters. I suggest:

    1. -prefetchDelay # do not immediately send the first record -- wait to see if the query returns more than one
    2. -prefetchFactor 100 # attempt to fill messages 100% or until NumRecs is reached
    3. -prefetchNumRecs 4000 # attempt to put X records n a message, use a large number -- FIELDS phrases can leverage that; max value is 32766
    4. -prefetchPriority 100 # aka "pollskip", check for messages (poll) from client every X records
    5. -Nmsgwait 1 # the number of seconds a server waits for a remote network message before checking for other events such as a database shutdown
    6. or forced disconnect of a remote client

    (In OpenEdge 10.2 and 11.* these all have default values that might have been appropriate when ARCNET crawled out of the swamps... OE12 increases the defaults to much more reasonable values.)

  • David Woo (Customer)

    Thank you all for the answers to my questions.

     

    I migrated the Windows database to the Linux server successfully.

     

    I used the -Mm 8192, and will try out the prefetch parameter suggestions from Tom.

     

    Performance appears to be OK/acceptable at this point.

     

  • George Potemkin (Customer)

    Best record reads per sec in readprobe tests (DB Size: 7.8 GB):

    1. 6,300,000 WHERE FALSE, LOCAL
    2. 5,540,000 WHERE TRUE, LOCAL
    3. 5,220,000 WHERE TRUE, TCP: -Mn=-n -Ma=1 -Mm 32600
    4. 4,499,297 WHERE TRUE, TCP: -Mn=-n -Ma=1 -threadedServer 0
    5. 2,707,809 WHERE TRUE, TCP: -Mn=1 -Ma=-n

     

    • David Woo (Customer)

      Thanks George!

       

      Is this a network connection on a LAN or a connection across the Internet?

       

      It looks very fast with the -Mm 32600 you used.