R
Rob Fitzpatrick
Guest
Hi David, Your understanding (paragraph 3 above) is correct. I always set -Mi to 1 so after the first Mpb clients have connected, assuming no disconnects, all servers have been spawned. I don't think there's as much for the DBA to juggle as you imagine. Yes, there are several parameters but they are interrelated; setting some determines how others can be set. I'll explain that below. For a particular connection broker, you have: -Mpb: max servers for that broker -Ma: max clients for each server -Mi: minimum clients before a new server will be spawned, if not all servers have been spawned Also, for the primary broker (which may also be a connection broker, as it is in your case): -n: total database connections allowed (not including brokers and servers) -Mn: total "servers" I should also note that this is far from being an exhaustive list of parameters related to C/S. It's just the very basics. As you know, the maximum number of concurrent clients that can connect through a connection broker is Mpb * Ma. You need to know what that product is. The -Mi parameter defaults to 1 and that's a good default so I always leave it there. So, knowing the desired maximum number of concurrent remote ABL clients, you essentially have one decision to make. You need to decide the trade-off between number of servers and number of clients per server. In choosing one, you are also choosing the other. For example, let's say you want a maximum of 500 remote clients. You said you plan to use -Ma 100, so that would make -Mpb 5. Setting a relatively high value for -Ma reduces the server footprint on the server, in terms of memory and CPU utilization and resource contention in the database, but it imposes a high penalty on clients. At maximum load, a client's query might have to wait before the server comes back to it until 99 other queries are processed. That would be a bad end-user experience, if those are interactive users. If the clients are App Servers, they may spend a lot of their time waiting on DB I/O. On the other hand, if you were to set -Mpb 100 and -Ma 5, then clients would have much lower latency and much more consistent wait times for data, but at the cost of much higher 4GL server footprint on the server machine. I can't tell you what is the right trade-off for your hardware and your application, but I can tell you that -Ma 100 is very high in my experience. I typically keep -Ma in the range of 3 to 5. As for setting other parameters, -Mn is easy: set it to a minimum of (sum of broker -Mpb values) + (total number of secondary brokers). Setting -n means anticipating how many total concurrent DB connections you will have at peak. This is limited by the number of rows in _connect, which is -Mn + -n + 2. The two extra are for the primary broker and for a proshut, to ensure you can always shut down your DB. So -n should include all 4GL clients (self-service or remote), all SQL clients, background processes (BIW, AIW, APWs, WDOG, AIMD, etc.), utilities, monitors, etc. You don't have to include remote servers or secondary brokers in the -n calculation as they are accounted for in -Mn. I always add a buffer of at least a dozen or two on -n, as there might be connections I need later (say, a monitoring or interactive client to see what's going on) that I don't anticipate up front. You didn't mention parameters for server ports but it's important so I will, just in case. You should always specify -minport/-maxport on every connection broker. They determine the contiguous range of TCP ports used by the broker for spawning servers. Give every broker a unique range, different from every other broker in this and every other database on the same machine. Be sure to avoid ranges that are specified, whether they are used or not, in the OS services file. I like to add my brokers' port ranges as a comment in the services file so that I and others will know which ranges to avoid on that machine in future. Doing this will help avoid "unable to spawn server" errors that prevent clients from connecting. For -prefetch*, I'm using -prefetchDelay, -prefetchFactor 100, -prefetchNumRecs 10000. These parameters will work best if you don't use the default message size (-Mm 1024). I use 8192 or 16384. > Given that we are running 11.7.4, are these all single-threaded processes? I've heard that they are, and that they use some kind of cooperative multi-tasking in order to allow work to be done in a serialized way on behalf of all the client connections (-Ma). Yes, in 11.x and earlier the 4GL server is single-threaded and uses a multiplexing design to process client queries, and connection/login requests, serially. This will change to a multi-threaded model in 12.0. As for metrics, you can see current connections in promon's Servers by Broker screen (R&D 1 17). You can see the server metrics you asked about in the _Servers VST. There is a browse for that info in ProTop as well. > My biggest concerns are related to the "broker" for ABL. How does it distribute new client connections to the available servers (-Mpb) once all of the servers have all been started? Does it just round-robin the incoming clients? Or does it try to somehow determine if a server is busy first? Once all servers have been spawned and then some clients disconnect, the broker does not just round-robin between servers to distribute new client connections. It assigns clients to the servers with the least clients first, until the distribution is even.
Continue reading...
Continue reading...