•
|
Current. The current number of actual remote sessions operating.
|
•
|
Peak. The highest number of actual remote sessions that have been used since the engine was started.
|
•
|
Maximum. The maximum number of remote sessions allowed.
|
4
|
•
|
Known communications protocol. You do not want the client or server to spend additional time trying to connect via protocols that are not supported in your environment. By removing client/server support for unavailable protocols, you prevent the networking components from trying to use them.
|
•
|
Known location of database engine. You do not want the client to attempt to connect to an engine that does not exist. By specifying Workgroup-only or Server-only support, as appropriate, you prevent the client from timing out while attempting non-existent connections. In environments where you have both unshared and shared databases, you can use Gateway Durability to force the database engine to keep track of machines where no database engine is running, so that it never attempts to connect to an engine on these machines, but uses another method to access the data.
|
•
|
Database engine ready to execute. When a sleeping engine receives a new connection request, it takes time to re-allocate resources and return to a runtime state. If connection speed is more important than resource usage on the server, you can prevent the server engine from sleeping when it is not in use.
|
1
|
In PSQL Explorer, expand the Local Client node in the tree (click the expand icon to the left of the node).
|
2
|
Right-click MicroKernel Router.
|
3
|
Click Properties.
|
4
|
Click Communication Protocols in the tree.
|
5
|
For Supported Protocols, ensure that the desired protocols are selected (check marked) and the protocols not being used are not check marked.
|
6
|
Click Apply.
|
7
|
Click Access in the Properties tree.
|
8
|
If you are using only a remote Server or remote Workgroup engine, ensure that Use Local MicroKernel Engine is not check marked. (That is, it is set it to Off.)
|
9
|
Click OK.
|
1
|
In PSQL Explorer, expand the Engines node in the tree (click the expand icon to the left of the node).
|
3
|
Click Properties.
|
4
|
For Supported Protocols, ensure that the desired protocols are selected (check marked) and the protocols not being used are not check marked.
|
5
|
Click Apply.
|
6
|
Click Memory Usage in the Properties tree.
|
7
|
8
|
9
|
Click OK.
|
10
|
Click Yes to restart the engine for these changes to take effect.
|
•
|
Adequate physical memory. If your host system has too little RAM, the system spends most of its time and CPU cycles swapping memory to disk and back, as different users and processes compete for limited resources.
|
•
|
Adequate CPU capacity. If your CPU cannot keep up with the inflow of data processing requests, application performance suffers.
|
•
|
Adequate network bandwidth. If your network is slow or suffers from a high collision rate, the database engine may sit idle between data access requests, while each client seems to display poor performance.
|
•
|
Minimal disk I/O. Disk I/O is significantly slower than memory
I/O. You want to avoid accessing the disk as much as possible, by having sufficient cache. |
•
|
Adequate resource allocations. Even with massive physical memory available, database performance may suffer if database engine configuration parameters are set artificially low.
|
•
|
The L1 cache is a fixed size based on Cache Allocation Size. It does not expand or contract based on database operations. If your application performs numerous WRITE operations, increase the L1 cache as much as possible.
|
•
|
The greatest performance is obtained if all of the data can fit into the L1 cache. If all of the data will not fit into the L1 cache, adjust Cache Allocation Size and Max MicroKernel Memory Usage to use a reasonable amount of system memory.
|
1
|
As discussed in the previous sub-section, Ensuring Adequate Physical Memory and Database Cache, one of the most important considerations is to ensure you have enough database memory cache to avoid frequently swapping data pages between disk and cache. See that section for details.
|
6
|
If your application usage is weighted heavily in favor of database read operations, you can increase performance by turning on Index Balancing. (Click Performance Tuning on the server Properties tree.) Over time, index balancing increases the number of nodes on the average index page, allowing read operations to occur faster. However, for insert, update, and delete operations, additional time and disk I/O may be required because the engine balances the index nodes across adjacent pages.
|
1
|
The setting Number of Input/Output Threads allows you to specify how many threads are available to handle file operations. (Click Performance Tuning on the server Properties tree.)
|