This content has been marked as final. Show 5 replies
In general the grouping of services in to servers is based upon two considerations. One is that the services are usually logically related and thus share a lot of code. The other consideration is in general to segragate long running services from short running services. Again, this isn't a hard and fast rule, just a good rule of them. The advantage of this is that short running service requests won't get stuck behind long running requests. Clearly setting up MSSQ sets can help aleviate this problem, although it is still possible for short running requests to get stuck behind longer running requests if there is a burst of long running requests that end up making all the servers busy.
In general how services are divided into servers won't have an impact on throughput. Throughput is determined by having an adequate number of servers configured to utilize the available resources. Where segregation may make sense is to help keep resource utilization more constant. Thus if you have some services that are more CPU bound and others that are more I/O or database bound, by grouping like services togethere into a server, you can control how much concurrency occurs and thus control the maximum level of resource consumption. So if server A contains CPU intensive services so generally consumes mostly CPU time, you would configure no more A servers than you have available CPU resources. Likewise if server B contains database intensive services, you'd configure no more B servers than the database can handle.
As for memory usage, all servers will share code segments. Thus running 10 copies of server A versus 20 copies of server A will likely not consume a huge amount of more memory. Or another way to put it is, say running 1 copy of server A takes 50 MB, it is likely that the next copy of A running will only consume another 10 MB as most of the processes virtual address space will likely be taken up by code, which will be shared across instances. CLOPT settings in general shouldn't affect memory consumption. If you are really concerned about memory consumption, try to build your code into shareable libraries, which then allows that code to be shared by any server needing that code with only a single copy of the code in memory.
Regarding the domain gateway, it follows the normal Tuxedo routing algorithm assuming load balancing has been turned on. So imported services from a remote domain are treated just like local services. Exported services again have standard request routing applied to any incoming requests, i.e., the incoming load will be optimized across the servers (actually request queues) that offer the service.
I'm not sure the above answered your questions. If not, please describe a bit more in detail what you are concerned about.
Oracle Tuxedo Chief Architect
Thanks for the reply.....
We don't have CPU problems today. The majority of our services (these so called "situations" in the future) will be mainly reading from the database layer, hitting IO when not cached in Veritas Quick IO. So "guess" is that the main concern is dividing into fast/slow services.
Take from your answer that the only hinder for the domain are the request queues. From here I am speculating (hard, since I mainly do performance testing on Java and SAP environments). Do you mean the gateway has a set of request queues that handover work to a "free" instance? What determines the number of these queues? Is there any way to monitor "overheating" of queues other than pulling info from SNMP? Would be cool to view the throughput of domain queues.
thanks / Matthew
Every Tuxedo server, including our domain gateways have a request queue (System V IPC queue) associated with them. This queue may be specific to a single server instance (SSSQ - Single Server Single Queue) or associated with multiple server (MSSQ - Multiple Server Single Queue). In the case of the Tuxedo domain gateways, they operate in an SSSQ configuration, so when requests are routed, they are placed on a request queue that is specific to the domain gateway instance.
With regards to monitoring, Oracle offers a product called TSAM (Tuxedo System and Application Monitoring) that allows a customer to view in real-time the number of messages queued and number of bytes pending to be sent to a remote domain. This should allow you to see whether the gateways are becoming bottlenecks. If a domain gateway is becoming a bottleneck, multiple domain gateways can be configured to increase the throughput to a remote domain.
I hope this answers your questions. If not, please elaborate on what else you need to know.
Oracle Tuxedo Chief Architect
So the domain gateway has it's SSSQ. And the gateway has an access point (unique) and a group with a TMSCOUNT (default of 3). What we normally do (in production) is have 2 sometimes 3 domain gateways where the every subscribing domain gets local access point to both gateways. Thereafter a percentage of services are exposed on one of the gateways. The segregation in our environment is not likely do to historical performance problems with the gateway rather the ability to shut off communication to sections of the domain or for administrative concerns.
But if the traffic for customer services (these 11 situations) was so high could it be possible to overheat the TMS or the SSSQ of the gateway? Wondering basically if you have seen that problem with other Tuxedo users?
Really appreciate the time you have taken. mvh / matthew