Discussions
Categories
Groups
Community Home
Categories
INTERNAL ENABLEMENT
POPULAR
PUBLIC CLOUD
PRIVATE CLOUD
Quick Links
MY LINKS
HELPFUL TIPS
Back to website
Home
Web CMS (TeamSite)
TeamSite Database performance issues with 7.1
System
Hey DevNetters -
I've been testing 7.1 in a (Solaris 10 LDOM) dev environment and have run into some performance issues.
Most everything runs OK but sort of slowly. I'm trying to determine if it's the LDOM / environment we're running in, or if it's something about 7.1 TeamSite itself. Here's an issue I've recently run into:
When, in Content Center, I select several directories for deletion in a workarea, the page waits to refresh for several minutes before timing out and this error displays:
The Interwoven Web Daemon was unable to contact the Interwoven Servlet Engine. The Interwoven Servlet Engine may be down, or running on an unexpected host or port.
If I refresh the screen, all's working OK. I can delete a few files, or a couple of directories, but a large deletion consistently errors out.
After checking out various logs, I noticed that the new content_center.log showed lots (and lots) of activity. I started watching this log while performing the deletions and saw that the deletion request was generating dozens and dozens (hundreds?) of jdbc connection requests and calls to the new back end database. I'm pretty convinced that it's this interaction that's causing the slowdown and eventual timeout.
It may be that we need to better optimize the connection to the db, but I'm suprised by the amount of communication to the db for what seems a fairly simple file deletion request.
Has anyone else run into this issue? On my 6.7.1 implentation, the response to this kind of request is snappy.
I've got a few other posts on DevNet about related db and performance issues with 7.1 (search forums for 'wally'), and this one seems particularly insidious. 7.x has introduced a new critical db component to the product set with little information on its function, administration, sizing, monitoring, etc. - and now it's also looking like a potential performance problem. Hmmmm...
Thanks for any insight here while I wait on Support to help with this -
Wally Box
Nike, Inc.
Find more posts tagged with
Comments
mart2001
Hi,
I hear TS 7.2 might come out soon. But keep creating db connections seem like a bad overall design, and the documentation about the database isn't plentiful. It just states that you need a certain database (no MySQL), yet their custom database option gives you the jdbc connection example of MySQL. :-(
Migrateduser
I did a test this morning. I:
- did an iwreset -a to refresh the system
- counted the number of 'opening JDBC connection' entries in the content_center.log file
- tried to delete 6 directories from a workarea
- recounted the number of 'opening JDBC connection' entries in the content_center.log file
As before, the UI timed out about 5 or 10 minutes after I made the request.
The number of 'opening JDBC connection' entries in the content_center.log file continued to grow afterwards until it appears that my session timed out.
During this test, there were 6,923 'opening JDBC connection' entries added into the content_center.log.
Has anyone else seen this type of behavior? I don't see it addressed in the release notes for 7.1 SP1 or 7.2
Thanks!
Wally Box
Nike, Inc.
nipper
Yea I noticed similar issues with removing files and deleting them. The customer has TS 7.1 on Solaris but I replicated the isssue with my Linux VM. Basically the removal of 6K images and submit took 3X longer in 7.1 than in 6.7.2. I did not narrow it down to any particular issue i.e. JDBC.
I did not file a case with support, though the customer may have.
If you file anything please post results.
Andy
Migrateduser
Misery loves company, thanks.
I'm testing further:
1 directory deletion took 10 jdbc connections.
2 directories took 2 jdbc connections.
3 directories is causing the runaway effect again.
nipper
Do you have search installed ? Are incremental updates turned on ?
Migrateduser
I have it installed, but currently have both the indexer and the search service turned off. I've been trying to keep the # of variables down as I test this out.
When search / indexing are turned on, I have the incremental mode on.
Migrateduser
Now I've got it failing with one directory, under which are 3500 files (no subdirectories.)
In the 7.2 release notes, I noticed this:
- Improving performance. Use the following strategies to improve
performance:
- Restrict the number of directories and files under a node to 1,000. If there
are more than a 1,000 items directly under a workarea or subdirectory,
partition the items into subdirectories.
While that's a good idea... having more files hasn't been a deal breaker in the past. I wonder if I'm running into the reason for that entry in the release notes?