Community Tip - You can Bookmark boards, posts or articles that you'd like to access again easily! X
We are having some problems with server performance when using the API. I don't know if it's due to the way I am using the API or some settings on the server or something else. We have several tablets running Windows 8.1. On each tablet, we have an app (written in C#) which downloads project data and allows us to execute our procedures offline. If only one tablet is downloading project data (and making API calls) then things seem to work fine. Once multiple apps try to download project data at the same time, everything slows down. Sometimes, one app might stop receiving downloading all together.
The way the app works is that I get the list of segments in a project using the code below. Then, I loop through the returned segments and make a new API call for each one to download the nodes. There doesn't seem to be any specific type of node or node content which causes things to slow down.
I am working adding some things into the app for the sake of debugging it to see if I can track down specifically what causes the slowdown. Has anyone seen similar issues where API calls from multiple sources leads to server slowdowns?
public List<Segment> GetProjectSegments(string Project)
{
List<Segment> allSegments = new List<Segment>();try
{
// Get all of the approved segment types from the approvedTypes array
// and convert them to a string for the query definition.
string approveString = "(field[Type]=" + approvedSegmentTypes[0] + ")";
for (var i = 1; i < approvedSegmentTypes.Length; i++)
{
approveString += " or (field[Type]=" + approvedSegmentTypes[i] + ")";
}// Define the query definition and the requested fields to return.
string queryDef = "((field[Project]=" + Project + ") and (item.live) and (" + approveString + "))";
string fields = "ID,Project,Type,Assigned User,Summary,State";Command cmd = new Command("im", "issues");
cmd.AddOption("hostname", hostServer);
cmd.AddOption("port", hostPort.ToString());
cmd.AddOption("user", userName);
cmd.AddOption("password", userPassword);
cmd.AddOption("queryDefinition", queryDef);
cmd.AddOption("fields", fields);if (!APIFactory.IsInitialized)
APIFactory.MKSInitialize();IIntegrationPoint ip = APIFactory.CreateIntegrationPoint(hostServer, hostPort, false, 4, 13);
ISession s = ip.CreateSession(userName, userPassword);ICmdRunner cr = s.CreateCmdRunner();
IResponse r = cr.Execute(cmd);foreach (WorkItem w in r.WorkItems)
{
int f0 = (int)w.Fields["ID"].Value;var fi1 = (MKS.ManagedAPI.Item)w.Fields["Project"].Value;
string f1 = (fi1 == null ? string.Empty : fi1.Id);var fi2 = (MKS.ManagedAPI.Item)w.Fields["Type"].Value;
string f2 = (fi2 == null ? string.Empty : fi2.Id);string f3 = w.Fields["Summary"].Value.ToString();
var fi4 = (MKS.ManagedAPI.Item)w.Fields["State"].Value;
string f4 = (fi4 == null ? string.Empty : fi4.Id);var fi5 = (MKS.ManagedAPI.Item)w.Fields["Assigned User"].Value;
string f5 = (fi5 == null ? string.Empty : fi5.Id);allSegments.Add(new Segment
{
UId = f0,
ProjectName = f1,
ItemType = f2,
Summary = f3,
State = f4,
AssignedUser = f5
});
}cr.Dispose();
s.Dispose();
ip.Dispose();
}
catch (APIException e)
{
throw e;
}
finally
{
//APIFactory.Instance.Shutdown();
}return allSegments;
}
Hi,
Try 's.release();' statement after 'Response r = cr.execute(cmd);'.
s.release() doesn't appear to be available for me. Maybe that's only available in the Java API? I've changed my code to reuse a connection for an extended time instead of creating and killing a bunch of connections. This seems to have fixed some of my problems. The other issues appear to be client side on the tablet (unrelated to Integrity itself).
This is involved enough that I recommend you open a case for this, unless you've figured it out, in which case please share! There are many variables at play here, and the lack of response here suggests we should investigate further.
With respect to using s.release();, I think the C API equivalent would be mksAPITerminate(), and should be documented in the Integration Builder's Guide.
Regards,
Kael
I think the server performance issue that I saw was actually unrelated to the API and just coincidentally occurred at the same time. It was on our "demo" server so it wasn't something we spent much time on tweaking beforehand. I think this can be closed.