Performance Tuning AR System Mid-Tier
Page 1 of 1
Performance Tuning AR System Mid-Tier
What are some basic performance tuning steps for AR System Mid-Tier?
giby.varghese@gmail.com- Posts : 107
Points : 222
Reputation : 3
Join date : 2009-11-11
Re: Performance Tuning AR System Mid-Tier
Here are some suggestions for tuning the Mid-Tier for best performance:
-Mid-Tier maintains a persistent cache of form, workflow objects, raw HTML and JavaScript code. By default this cache is built as
users access forms in their browser. The performance hit to do the caching for the first user touching the form can be significant.
Mid-Tier has a undocumented feature in 7.0.1 called prefetch which can be enabled and used to configure a list of forms or
applications that you would like mid-tier on startup to act as the specified user or users and cache commonly accessed forms.
This way the performance penalty on the human users is minimized. This feature is fully documented and supported in our 7.1
Mid-Tier release documentation along with other enhancements to 7.1 Mid-Tier to assist with caching. Please see Knowledge
Article KM-000000024917 which explains basic functionality and use of prefetch for 7.0.x Mid-Tier.
-Ensure that the JVM mid-tier lives in has a sufficient max heap size, when using mid-tier with the ITSM 7 applications we
recommend at least 1024mb or even 2048mb max heap size be set as java startup options. See your JSP/Servlet engine
vendor's documentation for details on how to set the JVM heap size.
-Capture some HTTP transactions for users accessing the Mid-Tier with a HTTP debugging tool, such as Microsoft’s Fiddler tool,
http://www.fiddlertool.com. Check that the HTTP requests show as coming from a HTTP 1.1 client and are being responded to by
a HTTP 1.1 webserver. Mid-Tier has built in content compression that gzip compresses content if the request is from a HTTP 1.1
client. IE 6 is by default a HTTP 1.1 client but a user can disable this in their Internet options. Also, check in the HTTP response
header, by sure the HTTP webserver is using persistent connections with the browser client, also known as Keep-Alive
connections. Make sure you don’t see Connection:close entries in the response headers sent back to the client.
-Once in production disable the Mid-Tier’s automatic cache updating functionality on the Cache Settings page in Mid-Tier Config
tool.
-Once everything is cached in the Mid-Tier memory and in the browser client and there still seems to be performance problems,
then we can take some additional steps to tune the system. For example we can enable Performance and Servlet logging only in
the Mid-Tier which should give us some indications of any slow running API calls to arserver, or excessive amounts of response
data being generated by mid-tier for things like table field refreshes, or Results List queries. Make sure the Log Level is set to
Fine and Log Format is set to Simple Text. This could reveal tuning needed in the arserver and the database. It also could show
that it would be wise to limit the number of entries returned in a get list operation, this is a configurable setting in arserver. Or, it
may be good to on certain table fields or form Results List to enable data chunking to minimize the amount of content mid-tier has
to generate back to the browser client.
-Mid-Tier maintains a persistent cache of form, workflow objects, raw HTML and JavaScript code. By default this cache is built as
users access forms in their browser. The performance hit to do the caching for the first user touching the form can be significant.
Mid-Tier has a undocumented feature in 7.0.1 called prefetch which can be enabled and used to configure a list of forms or
applications that you would like mid-tier on startup to act as the specified user or users and cache commonly accessed forms.
This way the performance penalty on the human users is minimized. This feature is fully documented and supported in our 7.1
Mid-Tier release documentation along with other enhancements to 7.1 Mid-Tier to assist with caching. Please see Knowledge
Article KM-000000024917 which explains basic functionality and use of prefetch for 7.0.x Mid-Tier.
-Ensure that the JVM mid-tier lives in has a sufficient max heap size, when using mid-tier with the ITSM 7 applications we
recommend at least 1024mb or even 2048mb max heap size be set as java startup options. See your JSP/Servlet engine
vendor's documentation for details on how to set the JVM heap size.
-Capture some HTTP transactions for users accessing the Mid-Tier with a HTTP debugging tool, such as Microsoft’s Fiddler tool,
http://www.fiddlertool.com. Check that the HTTP requests show as coming from a HTTP 1.1 client and are being responded to by
a HTTP 1.1 webserver. Mid-Tier has built in content compression that gzip compresses content if the request is from a HTTP 1.1
client. IE 6 is by default a HTTP 1.1 client but a user can disable this in their Internet options. Also, check in the HTTP response
header, by sure the HTTP webserver is using persistent connections with the browser client, also known as Keep-Alive
connections. Make sure you don’t see Connection:close entries in the response headers sent back to the client.
-Once in production disable the Mid-Tier’s automatic cache updating functionality on the Cache Settings page in Mid-Tier Config
tool.
-Once everything is cached in the Mid-Tier memory and in the browser client and there still seems to be performance problems,
then we can take some additional steps to tune the system. For example we can enable Performance and Servlet logging only in
the Mid-Tier which should give us some indications of any slow running API calls to arserver, or excessive amounts of response
data being generated by mid-tier for things like table field refreshes, or Results List queries. Make sure the Log Level is set to
Fine and Log Format is set to Simple Text. This could reveal tuning needed in the arserver and the database. It also could show
that it would be wise to limit the number of entries returned in a get list operation, this is a configurable setting in arserver. Or, it
may be good to on certain table fields or form Results List to enable data chunking to minimize the amount of content mid-tier has
to generate back to the browser client.
giby.varghese@gmail.com- Posts : 107
Points : 222
Reputation : 3
Join date : 2009-11-11
Similar topics
» AR System Mid-Tier cache invalidation and cache flush behavior explained.
» Cannot log into mid-tier Configuration Tool nor able to maintain session ID using the virtual IP address of the ARS mid-tier server.
» How does the Mid-tier's "Definition Change Check Interval" work?
» The Application List field in Mid-tier is yielding intermittently bad results - missing (or too-much) content, or 9201 session errors.
» ARERR [8760] Cannot establish a network connection to the AR System Plug-In server : BMC.FILTERAPI.NORM.ENGINE
» Cannot log into mid-tier Configuration Tool nor able to maintain session ID using the virtual IP address of the ARS mid-tier server.
» How does the Mid-tier's "Definition Change Check Interval" work?
» The Application List field in Mid-tier is yielding intermittently bad results - missing (or too-much) content, or 9201 session errors.
» ARERR [8760] Cannot establish a network connection to the AR System Plug-In server : BMC.FILTERAPI.NORM.ENGINE
Page 1 of 1
Permissions in this forum:
You cannot reply to topics in this forum