Hi all,

in the last month, our interactions with our Artifactory server have been 
getting painfully slow (as in, an order of magnitude slower than before), and 
I'm looking for tips on how to diagnose and investigate this, or just generally 
for things which are like to make performance better or worse.  Other than 
upgrading from 3.1.1.1 to 3.3.0 Pro, and deleting a large number of artifacts 
(about 30%), we haven't made any obvious changes recently ... but we may have 
made some non-obvious ones.

I haven't tried much yet-thought I'd ask for general tips before wading in.  
Our setup is as follows.


*         VMWare VM with

o   Windows Server 2008 R2

o   300GB disk (77% used)

o   4GB RAM

o   Xeon E5-2660 2.2GHz with 2 cores

*         JVM start options: 
JOPTS=-Xms1g;-Xmx3g;-Xss512k;-XX:PermSize=128m;-XX:MaxPermSize=256m;-XX:+UseG1GC

*         Derby DB with filesystem storage

*         Storage summary says

o   Binaries Count: 39,343

o   Binaries Size: 226.17 GB

o   Artifacts Size: 267.57 GB

o   Optimization: 84.53%

o   Items Count: 55,043

o   Artifacts Count: 45,887

I have a couple of specific questions on one bit of behaviour I have found so 
far, related to Gradle (still at 1.4, because we have some complex plugins on 
top, so upgrading isn't trivial).  We have a custom (client-side) Gradle plugin 
which gets auth details from the Windows Credential Manager, and passes them to 
the usual Gradle "repositories.ivy.credentials" block.  Nonetheless, Gradle 
appears to make an HTTP HEAD request without authentication, then retry with 
auth when it gets a 401, for every artifact.  Unfortunately, the first attempt 
(which appears in request.log as "non_authenticated_user") can take a couple of 
minutes, and then the authenticated retry takes only a handful of milliseconds.


*         What's the difference between "non_authenticated_user" (NAU) and 
"anonymous", in the request.log?  Is the latter only for web UI requests, or 
something?

*         Is there some known reason that NAU requests take a long time?  
(E.g., anti-DoS, anti-hacking, etc., or some interaction with LDAP, which we 
use.)

o   If so, can and should I speed them up with some config setting?

Things I plan to try, once I have a fairly-repeatable way of measuring the 
speed of dependency resolution, are as follow.

*         Compact the DB (since we deleted a load of stuff recently).

*         Prune unused artifacts (just in case that helps, but I doubt it).

*         Try putting our one third-part cache (repo1) into Global Offline Mode 
(so it won't be sending resolution requests through).  Not sure if that'll help 
much, since all the artifacts showing the above delay in the Gradle logs are 
our own, but maybe it's also looking in repo1 for them.

*         Try dependency resolution of the same set of artifacts using Gradle 
1.4 and the latest 1.x version (without our plugins).

*         Turn on extra Artifactory logging, if I can find any way to do that.

Thanks for any help you can give.

Regards,

Hugh Greene, Senior Software Developer
Toshiba Medical Visualization Systems Europe, Ltd
Bonnington Bond, 2 Anderson Place, Edinburgh EH6 5NP, UK
Tel + 44 (0)131 472 4792 / Fax + 44 (0) 131 472 4799
http://www.tmvse.com / mailto:[email protected]

DISCLAIMER
Unless indicated otherwise, the information contained in this message is 
privileged and confidential, and is intended only for the use of the 
addressee(s) named above and others who have been specifically authorized to 
receive it. If you are not the intended recipient, you are hereby notified that 
any dissemination, distribution or copying of this message and/or attachments 
is strictly prohibited. The company accepts no liability for any damage caused 
by any virus transmitted by this email. Furthermore, the company does not 
warrant a proper and complete transmission of this information, nor does it 
accept liability for any delays. If you have received this message in error, 
please contact the sender and delete the message.


______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________
------------------------------------------------------------------------------
Slashdot TV.  Video for Nerds.  Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
_______________________________________________
Artifactory-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/artifactory-users

Reply via email to