We recently installed v11 on our Test system and are currently in testing. I have noticed that the first time someone starts Tessitura in the morning it takes a very long time to access the Services (15-20 sec.) Subsequent logins startup as normal.
Is this normal behavior for the services or is there some tweaking needed on the server? Do the services timeout after a period of inactivity?
Hi Todd,
This sounds like the application pool starting up for the first time. In our situation, we have the app pool recycle once per day, at midnight. The first user logging in will experience a slight delay due to the app pool coming back up. If you wanted to avoid the delay for the first user, you could make a call to the REST services in some automated job and have that run after the time your app pool is set to recycle and before people show up. That would get it running before the first user logs in.
Thanks,
David
From: Tessitura Technical Forum [mailto:forums-technical@tessituranetwork.com] On Behalf Of Todd Tiffany Sent: Tuesday, March 19, 2013 12:50 PM To: David Frederick Subject: [Tessitura Technical Forum] v11 Services - slow client startup after period of inactivity
This message was sent automatically to you by www.tessituranetwork.com because you subscribed to the Tessitura Technical Forum. You may reply to this message to post to the Technical forum or visit the site to search, read and post to the forums. In the interest of keeping the forum posts from becoming cluttered, we encourage you to delete previous message text from your reply before sending. Thank you!
Exactly as David says.
You can stop the services from recycling (shutting down) from IIS app pool, but you may cause yourself problems later down the line in the production environment
Wayne
I am not sure if it is related but I was also seeing the following error message from Report Server for scheduled SSRS Reports running overnight.
ErrorError creating report snapshot: Service URI: https://<rest api serevr>/WebReports/Snapshot/Create/379863?auth=K%2fV6R1a1dgHBqh57QyrYZZgVuOy5YYzJzDnsiuPnvkdUW6W18yM%2fZsT7YBDW4Jtz Verb: POST StatusCode: 400 StatusDescription: Service Response: ErrorMessages: The operation has timed out XML Request: (None)
The report was running after the IIS recycle, and possibly looking at the earlier message after SSRS had recycled.
I ended up running Application Error Log every 30 minutes to try to get more of a grip on what the error was but that also seemed to solve the issue, so am not sure whether by doing this I was keeping the Web Reports, and therefore also SSRS and Rest Services, "warm" enough that they prevented that time out.
I haven't had any feedback from any individual that whoever logs on first is seeing a slow login, but that could just be because they aren't telling me.
The client does check that Web Reports is running along with the other REST API services, something we saw when we did our first Live over Test after V11 and hadn't realised we were still looking at the V10 doc.
I can do some testing with this on the Test system, where we do see the long login, as at the moment that can go for days without being used and there aren't any scheduled reports running on it currently.
Mark