Specialty engines have emerged as a way to redirect workload off of your GPP, which in turn means you can do more work without hitting capacity on the GPP. Specialty engines don’t “remove” workload – they just give you a place to redirect workload, and are unthrottled so you get the full power of the CPU vs. a subset. Ivory Service Architect has been architected to exploit the specialty engines: IFL, zIIP and zAAP.
Integrated Facility for Linux (IFL)
Ivory Service Architect can take full advantage of the IFL, or as it is known, Linux on System z. 100% of Linux on System z workload runs on the IFL so no work that occurs in Linux on System z will run on your GPP. Linux on System z also runs unthrottled so there are no speed restrictions applied. Additionally, with the use of Hipersockets, TCP/IP over to zOS is memory to memory so it’s extremely fast. So if you want the full power of the mainframe without incurring the additional workload on the GPP, leverage Ivory Service Architect running on the IFL using Linux on System z.
zAAP Processor
The zAAP processor, which was initially intended for Java workloads, is also utilized when you leverage IBM’s XML system services, which is a zOS-based XML parser. This can be leveraged by applications like Ivory Service Architect that run in CICS or outside of CICS. If you have a zAAP you can send the SOAP parsing and general Ivory XML parsing over to the zAAP to get MIPS relief.
This capability is available whether you deploy Ivory projects to our CICS or started task runtime. In fact, this is the only option to leverage a specialty engine should you desire a CICS-based deployment.
zIIP Processor
The zIIP was primarily intended for DB2 workload but is also able to be leveraged by ISVs like GT Software using a technique called an enclave SRB for XML processing. The zIIP processor provides an API to shift eligible workload, work that can be executed as an enclave SRB, to the zIIP. GT Software spent significant time identifying those pieces that can be moved and re-architected our runtime to exploit this capability.
There is an IBM limitation with the zIIP – as of today there is no way to shift the work over to the zIIP from CICS. To take advantage of the zIIP, you simply leverage the Ivory Server that runs as a started task.
Maximizing Specialty Engines
Common sense would say, “Send everything to a specialty engine,” but that’s simply not the case. To maximize performance, the best strategy is to balance your workload across processors. If not, you run the risk of peaking one processor to the detriment of the whole operation.
Considering the overhead of moving work from one processor to another, if the benefit, or the amount of time to execute, is less than the time to switch you can actually degrade performance.
To manage this process – Ivory Workload Manager will enable you to control: Which services will use an engine; which parts of the service will use the engine; and what workloads (based on size) will use the engine. Having control to decide when and how you leverage the engines will result in maximum performance with minimal overhead.
