REST api performance investigation hints

Guy_Walker

Hi. I am looking for some hints or pointers on where to look, and possible best practice/architecture on using the CS REST api.

Imagine a customer who only uses CS as a document repository, literally nothing else. All business functionality was performed in customer created clients using the LLAPI api and some custom stored procedures in the CS database.

To upgrade to CS16, they migrated over to REST api (using C# and RESTSHARP I think), and also converted their custom stored procedures into equivalent REST calls.

They are now seeing a massive drop in performance when deployed to their business, though integration and unit testing didn't show quite this performance drop off, apart from folder browsing which they've had to replace with some custom SQL views as it was really poor.

The last I heard they were complaining about authentication taking too long. They are using impersonation. Although I've not seen exactly what they are doing, I'm assuming they are not getting an authentication token for every single request.

As to their actual performance figures, I've not got those from them yet.

How are other people implementing this sort of thing? A sort of singleton approach that checks if it needs to re-authenticate whenever it is requested?

Are there any specific known bottlenecks that could be checked, or anywhere we need to be looking into, or specific logs? Or useful tools?

thank you for any suggestions
regards
Guy

Appu Nair

Unfortunately without looking at Logs (Thread, Connect or at least summary timings), it is hard to address where the performance loss is.
Here are some general-purpose best practices.

1)LAPI was perhaps talking to 2099 so there is a slight advantage of avoiding the webserver.I assumed you meant LLIAPI as LAPI as LLIAPI is an internal Oscript API.
2)Authentication need not be done for every call in an expensive way. All API's address then in some way. The programmers need to be aware of how the application URL is serviced. The best example is your livelink browser if it hits for the first time authentication protocol happens but then for the time being and until the cookie expiration happens any call from that browser only goes through the LLCookie deciphering which is a very low call. But if your architecture is round-robin and if your architecture is out of the box then every client call may get re-authenticated which is expensive. Perhaps if your organization was IWA you could derive that auth method although REST explicitly prevents that.
3)Changing to REST should not be construed as a bad act as a REST call is nothing but a livelink request handler. All API methods also get dispatched by the same mechanism. This would happen to any livelink if the calling client bombarded a server who couldn't handle the requests. Same as without thread saturation analysis one cannot say anything.
4)If REST was anathema how would Smart survive?
5)if I had to guess their database was a "set it once and forgotten" which is not how healthy organizations run their livelinks constant TLC is given to the DB layer.