Skip to main content

Degradation of performance of API using Cics web service JSON(restful)

  • May 23, 2024
  • 3 replies
  • 3 views
A
  • Anonymous

Application using a API to call Cics Web Services build as a JSON(restful)  CICS commarea deteriorates when time goes thru. Cics partition is recycled in the evening, so in the morning the results to the API come in about 200ms, as time goes thru it increases, we begin with 200 ms now at noon we have 900 ms. The program used in the cics web service seems to respond in a timely maner and keeping between 10-20 ms.  Any idea what causes this degradation ? Thanks


#EnterpriseServer
#EnterpriseDeveloper
#EnterpriseSuite

3 replies

Kim Hoskin
Forum|alt.badge.img+2
  • Kim HoskinModerator
  • Moderator
  • May 24, 2024

Application using a API to call Cics Web Services build as a JSON(restful)  CICS commarea deteriorates when time goes thru. Cics partition is recycled in the evening, so in the morning the results to the API come in about 200ms, as time goes thru it increases, we begin with 200 ms now at noon we have 900 ms. The program used in the cics web service seems to respond in a timely maner and keeping between 10-20 ms.  Any idea what causes this degradation ? Thanks


#EnterpriseServer
#EnterpriseDeveloper
#EnterpriseSuite

Hi,

Some points to help investigate could be:
-How do you monitor the performance? Via ESCWA /ESMAC UI or other 3rd party tools?
-Is this a new issue, what has changed to cause this? E.g. more users are using the application or was a software change introduced?
-Are the number of transaction/api calls increasing throughout the timespan? How many SEPs are defined for the region, do you have enough defined?
-When the issue is seen is machine hardware such cpu or disk use higher compared to when it is 200ms, to check if the hardware is the cause?
-What else is running on the machine that can take valuable CPU/disk I.O, causing other processes to slow down?
-When the issue is seen, for one of the SEPs that is being used to process the CWS work can you go to the  SEP trace to see what type of events are recorded.

I do recommend you to consider raising a support case if you require further help, please include as much information as possible to help the investigation, e.g. generate a MFESDIAGS diagnostics collection from when it is 200ms, then another wen is 900ms, share those .zip files for review.

A
  • Anonymous
  • May 24, 2024

Hi,

Some points to help investigate could be:
-How do you monitor the performance? Via ESCWA /ESMAC UI or other 3rd party tools?
-Is this a new issue, what has changed to cause this? E.g. more users are using the application or was a software change introduced?
-Are the number of transaction/api calls increasing throughout the timespan? How many SEPs are defined for the region, do you have enough defined?
-When the issue is seen is machine hardware such cpu or disk use higher compared to when it is 200ms, to check if the hardware is the cause?
-What else is running on the machine that can take valuable CPU/disk I.O, causing other processes to slow down?
-When the issue is seen, for one of the SEPs that is being used to process the CWS work can you go to the  SEP trace to see what type of events are recorded.

I do recommend you to consider raising a support case if you require further help, please include as much information as possible to help the investigation, e.g. generate a MFESDIAGS diagnostics collection from when it is 200ms, then another wen is 900ms, share those .zip files for review.

This is a new API intended to replace a current web service using FileShare.  The logic in the main system is the same but currently the programs are called with batch processing and now with CICS.

There were 7 SEPS and actually only 3/4 were used so we reduce to 5 and this seems to be enough.

The use of cpu seems stable so I do not believe is a hardware problem.

There is two cics partitions in total I would say 30 users at the same time.  We have one job running permanently in concurrence using file share.  There is also the current web service that we want to replace by the new one using CWS,  The answer time of the old one is more or less 1 sec. and the new one that it is in production but not visible to users is 1 sec in the morning but at the end of the day is near 4 seconds.

Kim Hoskin
Forum|alt.badge.img+2
  • Kim HoskinModerator
  • Moderator
  • June 10, 2024

This is a new API intended to replace a current web service using FileShare.  The logic in the main system is the same but currently the programs are called with batch processing and now with CICS.

There were 7 SEPS and actually only 3/4 were used so we reduce to 5 and this seems to be enough.

The use of cpu seems stable so I do not believe is a hardware problem.

There is two cics partitions in total I would say 30 users at the same time.  We have one job running permanently in concurrence using file share.  There is also the current web service that we want to replace by the new one using CWS,  The answer time of the old one is more or less 1 sec. and the new one that it is in production but not visible to users is 1 sec in the morning but at the end of the day is near 4 seconds.

Hi Pat,

Apologies for the delayed reply, it seems I did not see any notification for your reply.
A couple of things you can consider testing are:
-Test with/without fileshare, any change seen?
-If you have any remote resource such as database access, then consider testing with those local to the region.
-Is a lot of data being passed between the web service client/server, as a test can that be reduced to see if that makes a differences, in case there is some kind of chunking of data issue.

If the issue persists and you require further help then consider raising a support case, please include as much information as possible, e.g. such a MFESDIAGS diagnostics collections of when it runs ok and again when issue is seen.

The MFESDIAGS script can be downloaded from here: www.microfocus.com/.../mfesdiags

Recent badge winners

Explore all badges
Terms & ConditionsAccessibility statement