Jazz Forum Welcome to the Jazz Community Forum Connect and collaborate with IBM Engineering experts and users

any performance impact for querying huge data from RTC?

 

Hi Someone who may concern,

     We are working on 6.0.4 ifix 007 for RTC.
     After we upgrade our system to patch ifix 007, we got the following error :
- A result set of 20xxx entries was seen
java.lang.Throwable: A huge result set was found here
 ...
      We noticed some team send http command to fetch about 20000 work item frequently to RTC server , the lest time interval is 15 minutes, average 1 hour...
     And RTC server was killed and connection was reset after the error reported 12 times in 12 hours, and it is the last command.

     We contacted the team who send command, they said they have set up several servers to fetch data from RTC server( in 20000 level periodically) for long time, they did not care about whether in worst case, these several servers may trigger request to fetch data at the same time, because RTC has the ability to handle fetch data in millions level, 20 thousands, or 40 thousands, should not impact RTC performance.

       We are not sure whether this is the case? i.e such kind of request will not impact the performance of RTC server ?

        Thanks!

Best Regards,
Jane Zhou

        

0 votes



One answer

Permanent link
No the server performance will not be impacted. The server will run as fast as it always does.

What will be impacted is the performance of the CLM application towards the user. It will potentially crash the CLM server software running on the server should the server run out of resources, RAM and CPU usage increase to 100%.

We are currently developing JazzMagic(tm) which will enable faster than light communication and infinite storage with no latency at all.

Sorry couldn't resist.

We suggest everyone to monitor the servers for performance, understand topologies and limitations of technology. See the deployment Wiki for monitoring https://jazz.net/wiki/bin/view/Deployment/DeploymentMonitoring  and planning and topologies https://jazz.net/wiki/bin/view/Deployment/DeploymentPlanningAndDesign

0 votes

Comments

 Hi Ralph,

       Thanks for your reply so quickly!
       So why query data for 20 thousands work items frequenlty will trigger error as follows? 
- A result set of 20xxx entries was seen
java.lang.Throwable: A huge result set was found here

        It seems RTC server suffer the query? or because other reason ,say, run out RAM or CPU, so it can not work?
Best Regards, Jane

I would suggest to talk to support. It might well be that our developers have created guards that throw that error in case the software gets insane requests. Unfortunately this is not unprecedented and maybe the development team wants to have hints in the logs in case a customer complains about performance after over-saturating the system with insanely huge query results? There is nothing more in your post to work with, no error numbers etc. So please approach support.

 Hi Ralph,


      Thanks for your reply!
      I checked the history, the query error happened 11 times in 12 hour, the time interval is between 15 minutes and 3 hours. So it seems it is not insane query happened so quickly, say, every second.
         We are wondering any threshold to define "huge result" in server log. We did not get this error before we patch ifix007, so it seems development team add more things there to highlight possible issues.
        We will ask our IT team to contact development team to investigate.

      Thanks!

Best Regards,
Jane Zhou

      

Your answer

Register or log in to post your answer.

Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.

Search context
Follow this question

By Email: 

Once you sign in you will be able to subscribe for any updates here.

By RSS:

Answers
Answers and Comments
Question details
× 12,020

Question asked: Jul 24 '18, 3:57 p.m.

Question was seen: 2,092 times

Last updated: Jul 25 '18, 11:55 a.m.

Confirmation Cancel Confirm