Results tagged “performance” from Bill Benac

Why the Slowwwww API Searches?

Last month I shared a diagnostic application for the WCI API Service. It worked great on my machine, but...


Performance was terrible when I deployed it to my customer's environment. It commonly would take 8 seconds (8300 ms) to load. Why the hang up? On my laptop it only took 20 ms.

I looked at the spy logs, and I found that nearly all the processing time went to this  command from the API Service when it tried querying users:

SQueryRequest.execute() executing query: "(((not null) TAG phraseQ OR null) AND ((subtype:"PTUSER")[0])) AND ((((@type:"PTPORTAL")[0]) OR ((@type:"PTCONTENTTEMPLATE")[0])) AND (((ptacl:"u1") OR (ptacl:"9994") OR (ptacl:"9992") OR (ptacl:"51") OR (ptacl:"1"))[0]) AND (((ptfacl:"u1") OR (ptfacl:"9994") OR (ptfacl:"9992") OR (ptfacl:"51") OR (ptfacl:"1"))[0])) METRIC logtf [1]"

The customer has 1.1 million users in the database, so maybe the search index is just very slow? I deleted a few hundred thousand users, and the query could then regularly return in about 6200 ms, so this was a major improvement. Also, I used the standard administrative UI to search for all users, and it took a similarly long time to return.

Ahh, so the problem is that the search index is doing a very bad job querying against a large set of objects.

Does anyone know whether there is a way to overcome this problem? Some uninspired attempts to tune the search service's cache size gave me no material change.

So in the absence of good tuning knowledge? I changed the apicheck diagnostic app so that now it verifies it can query communities (of which there are hundreds) instead of the users. The performance problems for my portlet have magically gone away

A colleague, Jeff, called today to ask about various performance-related items including ALUI portal caching.  Many people know that portlet developers and administrators can coordinate to control caching of portlet content. This lets the company news portlet content, for example, be fetched once in an hour into memory and then be shared between all users, while the paycheck content is fetched for each individual user. Less well known though is that the system administrator can tune how the portal server handles the cache. How many of those paychecks for example should be stored in memory before being replaced?

So Jeff and I chatted a bit about the options and effects of tuning portal server caching today. I was reminded of analysis I did at one customer which was interested in whether performance (on version 5.0.4) could be improved by using more of its spare portal server memory for caching. We found that it isn't worth the trouble to tune away from the default settings because the system works great out of the box. I believe the analysis applies to current versions as well.

I'm not writing this as a blind fanboy who sees nothing but the brilliance of the ALUI product. Rather, after a careful analysis, I realized the tunings really are fine. You'll probably agree with me when you consider how the portal caching works. Basically, the portal stores content in its cache based on how recently used it is. So the more frequently used content is, the more likely it is to regain its place on the top of the list of items to cache. When an item is infrequently used, it will be pushed down the cache list by other items and ultimately get pushed out. But this means that the most important content, the most frequently used, is always on the top of the list. All that content toward the bottom of the list doesn't get used frequently anyway, so who cares if it gets pushed out of cache? And if you triple the cache size, then you just store several times more unimportant content in cache.

If you never knew the portal cache settings could be tuned, then forget you read this post because it doesn't matter. But if you were casting about on the Internet looking for information about this topic, stop while you're ahead! Don't bother fixing what isn't broken. It would be better for you to tinker with your image server's content expiration headers for something that will really have impact.

caching-analysis-results.jpgWant data? Feel free to read the presentation I did on the results of my analysis. You'll see that when we tripled the cache size, we gained only insignificant reduction in requests to remote servers.

Find recent content on the main index or look in the archives to find all content.