Introducing proCube Server

Introducing proCube Server

proCube™ Server enables multiple users to share and analyze data concurrently across an intranet or the Internet. proCube Server is typically installed on a shared network server, providing proCube functionality to multiple users of the proCube client—the workstation application—and managing shared access to the proCube database. It also coordinates functions from other modules such as Xchange.

proCube Server includes two parts:

  • Behind-the-scenes software, called services, that are the engine of proCube.

  • The Server View, a program running within proCube Management Studio, that administrators use to monitor and manage the system. An important example of a process performed by proCube Server is recalculation; when users change data in a cube and recalculate, the process occurs at the server.

The following figure shows proCube Server with several concurrent proCube clients.

procubeserverillustration.png

Figure 1.    proCube Server with Multiple  Users

proCube Server works on any machine using single or multiple CPUs running Windows 2003 Server and above. With the proper hardware and software requirements fulfilled, proCube Server can be installed on a workstation for a self-sufficient, standalone system. Although the service itself has no visible interface when it runs, the Server Control Program has an extensive user interface with point-and-click functionality.

The proCube Server application allows multiple concurrent proCube client applications to read and write proCube data. In contrast to a local database, meaning a standalone database opened on a workstation, the server database is maintained on the server machine and only the requested data is transferred to the proCube client application. The data is maintained in the memory of the server machine to provide quick access.

Since multiple clients have access to the database, the server component must enforce the necessary data integrity. Therefore, only one user at a time is allowed to modifymetadata (except slices). Fact data modification is based on a “last in wins” scenario.

From a technical perspective, the networking portion of the server is a scalable, protocol-independent communication class application utilizing multiple threads over TCP/IP and the Winsock 2.0 specification.

Server Features

Multi-threading of concurrent user operations

proCube supports multi-threading for concurrent users, thereby ensuring that a lengthy calculation request by one user does not stall calculation requests by other users. By eliminating processing delays of concurrent users, proCube improves both employee productivity and the workflow of planning processes.

proCube’s multi-threading technology enables multiple concurrent users of proCube to recalculate data simultaneously, even while another user is entering new data at the same time. As a result, concurrent users can simultaneously perform:

  • server operations (e.g., Open/Close Database, Get List Of Databases, etc.)

  • metadata read operations (e.g., obtain a list of dimensions, cubes, members of a dimension, etc.)

  • metadata write operations (e.g., add/delete a cube, dimension, or member, etc.)

  • fact data read operations (e.g., recalculate a slice by hitting F9, etc.)

  • fact data write operations (e.g., when a user types a value into a slice cell, etc.)

Multi-threading technology

To enable these and other concurrent user operations, proCube includes one thread pool for each proCube database. A database thread pool consists of a dispatcher thread and several worker threads. Database operations are queued to the dispatcher thread of that database and then executed on one of the worker threads of that database. In this design, operations belonging to different databases do not interfere with each other at all (i.e., a metadata write operation on one database will not block a metadata write operation on another thread). Multi-threading also enables the following additional capabilities:

  • proCube supports parallel fact data reads because synchronization objects, such as critical sections and reader/writer locks, are introduced into the calculation engines to serialize access to the aggregate cache and the formula cache of each cube. This allows safe execution of multiple fact data read operations at the same time.

  • proCube also includes deferred fact data write operations for improved performance; when the server receives a fact data write operation, it queues the operation to the dispatcher thread of the corresponding database and then immediately writes a response back to the client without waiting for the operation to be executed. This improvement allows data entry users to continuously enter data without being blocked by the operations of another User.

  • In addition to the thread pool threads of each database, in proCube, the server maintains 1) one listener thread that “listens” for all incoming client connection requests and 2) one thread, called a session thread, per client TCP connection. All server operations are executed directly on the session thread, and all database operations are queued to the dispatcher thread of the corresponding database thread pool. Except for the deferred fact data write operations, all other database operations wait for the execution results from one of the worker threads before sending responses back to the client.

Supported Combinations of Operations

The dispatch algorithm of each database thread pool is designed to maximize the number of concurrent executions of database operations. The table below lists the allowed combinations of various database operations. (Pass thru operations are not included because they are not affected by other types of database operations except metadata write operations, which always execute one at a time and block all other types of database operations.)

Concurrent Database Operations

Previous Model

Current Model

Multiple meta reads

Yes

Yes

Multiple meta writes

No

No

Multiple fact reads

No

Yes

Multiple fact writes

No

No

Multiple meta reads and one meta write

No

No

Multiple meta reads and multiple fact reads

No

Yes

Multiple meta reads and one fact write

Yes

Yes

Multiple fact reads and one meta write

No

No

One meta write and one fact write

No

No

Multiple fact reads and one fact write

No

No

Note that under certain circumstances, the multi-thread dispatcher will proactively and logically move select database operations to the front of the queue instead of executing all operations in the order in which they are queued. For example, if the first three operations in a queue are a fact data write operation, a fact data read operation, and a metadata read operation—and the current executing operation is a lengthy fact data read operation—the dispatcher will dispatch the third operation right away while keeping the first and the second operations in the queue.

Support for Multi Processing 

If you have multiple processors, proCube automatically scales to the number of processors available in order to maximize application performance. To take advantage of this feature, you need either a single processor machine that supports hyperthreading or a multiple processor machine. In addition, during installation of the server application, when you are prompted with the following screen, select proCube Advanced.

procubeadvanced.png

Figure 2.    proCube Advanced

Selecting proCube Advanced allows proCube to take advantage of up to any number of processors. The performance improvements made possible via multi processing support can, in some cases, cut processing times in half.

Adding multiple instances

Multiple instances of proCube Server can be installed and run on each physical server. Multiple instances are used to increase performance across different databases. Each instance operates in its own memory space, meaning that each process is independent of the other, resulting in greater performance for functions that are processor intensive on the server. This includes functions such as recalculations and data loading.

The instances can be created both during the installation process and later through use of the Instance Manager, which also provides you with control of the instances,  You can utilize the Instance Manager to add or delete a server, modify a server name, set up start types and login info, etc.

To use the Instance Manager, perform these steps:

  1. Right-click on Start.

  2. Open Windows Explorer.

  3. Select program files/satori/bin.

  4. Double-click on INSTMGR.exe. The following screen displays:

multiinstanceserversettings1.png

Figure 3.    Instance Manager - Add/Remove Servers

  1. Click on Default Server to Modify any settings

multiinstanceserversettings2.png

Figure 4.    Instance Manager - Add/Remove Servers 2

  1. Right click on Server to add another instance:

multiinstanceserversettings3.png

Figure 5.    Instance Manager - Add/Remove Servers 3

  1. Enter the Server name. You can modify configuration of the instance as necessary, change the startup type and user information, control the password, etc.

  2. Click Next to continue. The following screen displays:

multiinstanceserversettings4.png

Figure 6.    Instance Manager - Add/Remove Servers 4

  1. Review your changes and click Next.

commitchanges.png

Figure 7.    Commit Changes

  1. Click Finish to complete and close the Instance Manager.

viewerrors.png

Figure 8.    View Errors

3GB memory support for 32-bit OS

9Dots recommends using Windows x64 Editions for proCube Server.  When running a 32-bit application (proCube version 7) in Windows x64, Windows using a tool called Wow64 to run the 32-bit application.  Since it does not require memory for the kernel, Windows x64 can give the 32-bit application the full 4 GB of memory in which to operate.

If you must use a 32-bit OS, Windows by default gives 4 GB of memory space to the application.  However, that memory is split.  2 GB goes to the kernel and 2GB goes to the application itself.  Because applications became increasingly memory hungry, Microsoft developed a switch to reduce the amount of memory going to the kernel so the application can have more of it.  This switch is called the 3 GB Switch.  When the 3 GB Switch is used, the Kernel gets 1 GB and the Application gets 3 GB. 

To implement the 3GB Switch, you must modify the boot.ini.

The following is an example of a Windows 2003 Enterprise Edition (32-bit) System with a modified boot.ini.

[boot loader]

timeout=30

default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS

[operating systems]

multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows Server 2003, Enterprise" /noexecute=optout /fastdetect /PAE /3GB

Note the /PAE Switch.  PAE stands for Physical Address Extension.  If your server has more than 4 GB of Physical RAM in it, Windows will not be able to see the RAM past 4 GB without this switch.  If your proCube Database’s size is requiring you to enable the /3 GB Switch, and you don’t have more than 4 GB of Physical RAM in your Server, it is time to buy new hardware.

Additional Info about Windows Memory Support:

  • Windows 2003 Standard (32-bit) can only support a maximum of 4 GB of Physical RAM

  • Windows 2003 Enterprise (32-bit) can support up to 64 GB (with PAE enabled)

  • Windows 2003 Standard R2 (64-bit) can support up to 64 GB

  • Windows 2008 Enterprise R2 (64-bit) can support up to 2 TB

Windows 2008

For more info, go to:

http://msdn.microsoft.com/en-us/library/aa366778.aspx#physical_memory_limits_windows_server_2008

Windows 2003

For more info, go to:

http://msdn.microsoft.com/en-us/library/aa366778.aspx#physical_memory_limits_windows_server_2003

Networking Considerations

proCube clients connect to the server via TCP/IP: both the clients and the server must be configured for TCP/IP. The user can connect to the server using either the server name, which is the actual name of the Windows 2003 Server, or the TCP/IP address.  If using the server name, the server name must be registered with a Domain Name System (DNS) in order for clients to be able to resolve the IP address from the server name; alternatively, an entry can be added to the client’s local HOSTS file. Go to Working with a Server Database from Workstations for more information about connecting to a proCube server from a client.

Accessing proCube server over the Internet

There are two ways to access proCube Server over the Internet. The first is with the optional proCube Web application. The second is by using your Windows applications— the proCube client and Microsoft Excel—directly through a TCP/IP connection. This topic provides advanced technical information for administrators who will be setting up direct TCP/IP connections.

You can connect to a proCube server over the Internet using proCube and Excel, just as if you are working on a local network. Your performance, of course, will be limited to the speed of the Internet connection. When using proCube Server, a client connects to the server via TCP/IP port 34324. The server communicates back to the client via TCP/IP port 34323. When running over the Internet, users must have access to communicate to the server via this port. If the server is behind a firewall, the firewall must be configured to permit port 34323 and 34324.

WARNING: Opening up ports on the firewall may pose security issues. Consult with your System or Security Administrator to configure the firewall. These are the default TCP/IP port assignments and can be changed if necessary.

 

Have more questions? Submit a request

0 Comments

Please sign in to leave a comment.
Powered by Zendesk