Skip to Content
avatar image
Former Member

any improvement if client on same host that the dataserver?

Hi community,

May I ask your feedback on whether you notice any improvements when the client side is executed on the same server than the dataserver?

To give you more context, our application is usually deployed on a different server than the dataserver. The upgrade is mainly taking place on the dataserver.

So we have a client process that connects to the dataserver and executes some SQL statements.

Now discussing with some colleagues they noticed some improvements in the upgrade process when our application is deployed on the same server hosting the dataserver.

So I'm just wondering what could the reason of such improvement (I'll run a test to see by myself): less usage of the network stack maybe?

Have you noticed similar improvement?

Thanks in advance

Simon

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

2 Answers

  • Feb 03 at 03:56 AM

    As Mariano has pointed out, introducing a network connection can add some extra time, though obviously how much time will depend on the quality of the network and the volume of (network) activity you're processing. "Duh, Mark!" ?

    When running your tests you may want to see what happens if you bring up a localhost listener on ASE, then have the local app use the localhost address (eg, you'll likely need to list the localhost entry first in the interfaces file, or possibly have the app use it's own interfaces file with the local host entry in it). [It's always been my (mis?)understanding that the localhost connection introduces a lighter performance hit because you're not going through a full network stack.]

    Add comment
    10|10000 characters needed characters exceeded

  • Feb 02 at 02:13 PM

    Four years ago we split our server, which initially hosted both the ASE server and the app, into two different machines, both high end Unix servers linked by a high quality LAN. Our tests revealed that the overhead for splitting machines was 130 microseconds per round trip from the app to Sybase ASE.

    That overhead was unnoticeable for most programs. Only a handful of ESQL batch programs that opened some huge cursors shown a delay of several minutes, as each of its 50 million SQL FETCH statements made a round trip from the program to ASE. The programmer had better batched cursor rows in order to get more than one row per trip.

    Add comment
    10|10000 characters needed characters exceeded