Click here to view and discuss this page in DocCommentXchange. In the future, you will be sent there automatically.

SQL Anywhere 11.0.1 (Français) » SQL Remote » SQL Remote Deployment and Administration » SQL Remote Administration » Improving SQL Remote performance » Improving performance when receiving messages

 

Adjusting the number of worker threads

The following steps describe how the Message Agent (dbremote) applies incoming messages:

  1. It reads the messages. Messages are read and the header information is examined (to determine the correct order of application). Reading messages from the message system is single-threaded.

  2. It applies the messages. Read messages are passed off to database worker threads to be applied.

    On remote databases, the messages are usually applied serially. In a multi-tier system, a remote database can also be a consolidated database for other remotes. On this type of a remote database, the messages are applied as on a consolidated database.

    On the consolidated database, the default is to apply the messages serially. You can use additional database worker threads to apply incoming messages from remote users in parallel. See the -w option in Message Agent (dbremote).

    When database worker threads are used on a consolidated database:

    • Messages from different remote users are applied in parallel.

    • Messages from a single remote user are applied serially.

      For example, ten messages from a single remote user are applied by a single worker thread in the correct order.

Advantages of using database worker threads

Using database worker threads on the consolidated database can improve throughput by allowing messages to be applied in parallel rather than serially. The performance advantage is significant when the database server is on a system with a striped drive array.

Disadvantages of using database worker threads

Using database worker threads on the consolidated database, can decrease throughput if they cause a lot of locking between users.

A deadlock is handled by re-applying the rolled-back transaction later.

♦  To set the number of database worker threads
See also