cancel

Are others finding TRIM 7.31 slow?

SOLVED
Go to solution
Highlighted
Joshua Hutley
Outstanding Contributor.

Are others finding TRIM 7.31 slow?

I am testing TRIM 7.31 on a client PC.

 

My opinion so far is that it feels sluggish. Could this be related to this issue affecting TRIM 7.3?

 

"The connection between the Trim Client on a workstation and the WGS is very slow in checking in and creating new records"

 

HP Software Knowledge Document KM00351215 (http://support.openview.hp.com/selfsolve/document/KM00351215)

15 REPLIES
Neil Summers
Micro Focus Expert

Re: Are others finding TRIM 7.31 slow?

Hi Joshua,

 

Product engineering are currently investigating the possibility that an issue previously fixed after being discovered in early TRIM 7 builds, may have crept back in to 7.31 with an update to the RCF protocol used for communication between the clients and the server.

 

There was a workaround identified previously by one of our customers. Perhaps you might like to try this on one of your 7.31 client machines. I've copied the relevant parts of that customer's previous comments below:

 

"...Here is the solution (This will work for XP, VISTA and Windows 7):

 

Type in regedit and go to HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\(You'll have to figure out which key under interfaces is your adapter ID--It will be the entry with your computers IP address in there....)

 

Add the DWORD value of TcpAckFrequency=1 (Decimal) to HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \Tcpip \Parameters \Interfaces \{Your Adapter-id}

 

Reboot your machine and  you should get the performance back......

 

When 2 TCP/IP hosts establish a connection they each advertise something called the Maximum Segment Size. This is the maximum amount of data each TCP stack wants to see in a single packet. It's usually around 1460 bytes but due to VPN headers we will often see systems set to 1260.  TCP also has this thing called a Delayed ACK. It is basically the TCP stack waiting around 200 milliseconds to send an ACK for data it receives.

 

The way Microsoft implements the TCP delayed ACK is that it will delay every other segment that is smaller than the maximum segment size. This is done so that a stack isn't constantly sending ACKs for small packets when it can just wait a bit (200ms) for more small segments to be received and ACK them with one packet.

 

What was happening was that when the server started sending packets less than the Maximum Segment Size the TCP stack started to delay its acknowledgment. So  you had a whole bunch of packets that were taking 200ms to be acknowledged.  5 delayed packets is 1 second, a huge amount of time.

 

So the setting that you changed basically tells the Microsoft TCP stack to never delay a TCP ACK..."


Neil

Note: Any posts I make on this forum are my own personal opinion and (unless explicitly stated) do not constitute a formal commitment on behalf of HPE.

(Please state the version of CM you're using in all posts.

HPE Software Support Online (SSO): https://softwaresupport.hpe.com/
Joshua Hutley
Outstanding Contributor.

Re: Are others finding TRIM 7.31 slow?

Thank you Neil

 

I have tried this and my initial thoughts are it has improved speeds. I will continue to monitor.

Joshua Hutley
Outstanding Contributor.

Re: Are others finding TRIM 7.31 slow?

Neil and others I believe this issue is still affecting TRIM 7.3.2

I was hoping this would be addressed.

There is a noticeable difference to the lagginess before and after the registry key change. My question is can this key being easily deployed, especially as the adapter id will be different for each PC right?

 

 

 

tbanera
Trusted Contributor.

Re: Are others finding TRIM 7.31 slow?

We are currently seeing similar issues in out testing of 7.3.1.  I will try this fix to see if performance improves and advise.

 

Thanks.

 

 

EWillsey
Acclaimed Contributor.

Re: Are others finding TRIM 7.31 slow?

Josh,

 

If you want to roll this out via for all of your users, create a batch file with this content and then execute it on the workstation (as a local admin or during logon).

 

 

@echo off
for /f "tokens=*" %%a in ('reg query "HKLM\SYSTEM\CurrentcontrolSet\Services\Tcpip\Parameters\Interfaces"') do (
rem echo %%~na
reg add "%%a" /f /v "TcpAckFrequency" /t REG_DWORD /d 1
)

 

 

 

I hope this helps.

 

Cheers,

Erik

---------
Erik
CMRamble.com
Joshua Hutley
Outstanding Contributor.

Re: Are others finding TRIM 7.31 slow?

Thanks Erik

 

This will be helpful

tbanera
Trusted Contributor.

Re: Are others finding TRIM 7.31 slow?

Along with this change we made one more tweak that improved performance and that was to install the SQL server Native Client 10.0 and use that as the provider instead of the out of box OLE DB one.

 

 

Phil_The
Respected Contributor.

Re: Are others finding TRIM 7.31 slow?


tbanera wrote:

Along with this change we made one more tweak that improved performance and that was to install the SQL server Native Client 10.0 and use that as the provider instead of the out of box OLE DB one.

 

 


As part of our June TRIM upgrade, I considered using the SQL server Native Client instead of the HP OLEDB one; mainly because I was strongly considering implementing mirrored databases (SQL 2008 R2)with the potential for automatic failover if required. In the end, I wussed out given that we were migrating from TRIM 6.24 on Oracle 10 to TRIM 7.31 on MSSQL and I wanted to minimize the inital batch of changes during project implementation (I also don't like scope creep).

 

As I probably will revisit this in the future once the dust has settled, can you provide some ideas on how performance with the RDBMS has improved? With TRIM 7.31 at the moment our major bottleneck and issues appear to relate primarily to the Workgroup server rather than the database back end.

 

With regard to DB performance, we're running a 30GB primary database on a SQL 2008R2 box with 14GB of RAM at the moment on Tier 1 storage and the server appears to be running smoothly.

 

 

Phil_The
Respected Contributor.

Re: Are others finding TRIM 7.31 slow?

We too are finding various TRIM 7.31 behaviours  "sluggish" and have been recommended by HP support to implement: http://support.openview.hp.com/selfsolve/document/KM1166526 

 

For those of you preferring a vbscript approach to implementing KM1166526 feel free to use/edit the one I'm using (deployed with SCCM 2007 R3). Just rename the text file with a .vb or .vbs extension before use.

 

Disclaimer: This script (and I believe Erik's one earlier in this thread) will change ALL interfaces on the client workstation (modems, virtual NICs etc.) and not just the currently active ethernet connection. This shouldn't be an issue for most sites, (we implemented the script as it stands) but please assess the implications of running this script on your infrastructure before trying it out :)

tbanera
Trusted Contributor.

Re: Are others finding TRIM 7.31 slow?

Everything for the client was faster.  Loading, searching, navigating through the classifications.  We would blow errors using a third party explorer tool.  These vanished as well when we moved to the driver.

 

We ran it in our 624 environment with the SQL native driver as well.

 

The only time we saw any load on the database was during the run of the Index Text Utility.  No real bottle neck on the database.

 

We are running SQL server 2008 64 bit with the O/S being Server 2008 64 bit.  There are 6 different databases on the server.  It has 2 CPU, 12 GB of memory.  We gave the TRIM instance 4 GB of memory.

 

We have a doc store of about 600 GB, 700 users and 1.2 million records. 

 

No bottle next on the workgroup servers either.  We are running two workgroup servers.

 

Workgroup one is just a workgroup server with TES and Rendering.  2 CPU 4 GB memory.

Workgroup two is a workgroup server with TEST and IDOL.  We have set the MaxSyncDelay to 4 hours so we see a spike of all our resources for the time the commit happens.  Lasts for about 15 minutes.  2 CPU, 18 GB of memory.  Three separate LUNS.  Disk 1 for for O/S and install of IDOL, disk 2 for Content Service 1 and 2 and disk 3 for Content Service 3 and 4.

 

We run in plain non mirror mode for IDOL config.

 

We have only been live for a couple of weeks so not sure what lies ahead.

Ross Phillips
Respected Contributor.

Re: Are others finding TRIM 7.31 slow?

Can anyone confirm for me whether this issue was resolved in 7.33?

 

The notes for QCCR2D47230 suggests that it was, but my quick testing of the client doesn't bear that out.

 

Connecting to a 7.32 server:

A clean install of the 7.3.3.5645 client returns an average performance index of just 13.

If I add the TCPAckFrequency key to the client, the performance index average jumps to over 1000!

 

Am I missing something?

Cheers!

 

Joshua Hutley
Outstanding Contributor.

Re: Are others finding TRIM 7.31 slow?

Hi Ross

 

I agree with you. My setup is 7.33 to TRIM 7.32 server (haven't upgraded the server yet) I get 13.8 performance test results consistently

 

with the TCPACK key applied anywhere between 500 and 1200.

Ross Phillips
Respected Contributor.

Re: Are others finding TRIM 7.31 slow?

Bugger.

 

Thanks Joshua! I'll see what happens after I upgrade the server also.

 

Joshua Hutley
Outstanding Contributor.
Solution

Re: Are others finding TRIM 7.31 slow?

The good news is that updating the server to TRIM 7.33 seems to have fixed this issue. I am now getting comparable results to running performance test on the server.

Ross Phillips
Respected Contributor.

Re: Are others finding TRIM 7.31 slow?

Confirmed here also, thanks Joshua.