Artifactory perfomance tuning tips?

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Artifactory perfomance tuning tips?

HughG_TMVSE

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 / [hidden email]

 

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/artifactory-users
Reply | Threaded
Open this post in threaded view
|

Re: Artifactory perfomance tuning tips?

HughG_TMVSE

Hi again, all,

 

it’s really time for me to go home but, before I do, I wanted to report something which seems quite suspicious, in case anyone happens to come back with an answer before I get back to work on Monday :-)

 

While investigating, someone looking over my shoulder noticed that the access.log files seemed to be getting rotated quite often.  In fact, they seem to be getting rotated continuously, perhaps because the original log file isn’t getting trimmed down after rotation, so remains over threshold.  Using the trick below, I can see that one file is being updated every 3-4 seconds, then the next, then the next, and so on.  Perhaps coincidentally, one of our users said that he’d seen an initial delay of “about 4 seconds” at the start of every request, in a recent run where he looked at detailed logs.

 

(The trick is adapted from http://www.computerhope.com/forum/index.php?topic=114296.0:

 

forfiles /m access.*.log /c "cmd /c ECHO The last modified time of @file is: @ftime”

 

)

 

I see at <a href="http://www.jfrog.com/confluence/display/RTF/Artifactory&#43;Log&#43;Files"> http://www.jfrog.com/confluence/display/RTF/Artifactory+Log+Files that the etc\logback.xml file controls rotation.  I haven’t changed this since install, and the file is the same as what was in place for 3.1.1.1, modulo some insignificant whitespace changes.  Maybe something else has changed in Artifactory in this area, or maybe this is not the cause, but I’ll investigate more on Monday …

 

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 / [hidden email]

 

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.

 

From: Greene, Hugh [mailto:[hidden email]]
Sent: 19 September 2014 13:14
To: [hidden email]
Subject: [Artifactory-users] Artifactory perfomance tuning tips?

 

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 / [hidden email]

 

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
______________________________________________________________________

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________


______________________________________________________________________
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/artifactory-users
Reply | Threaded
Open this post in threaded view
|

Re: Artifactory perfomance tuning tips?

HughG_TMVSE
In reply to this post by HughG_TMVSE

Hi again, again,

 

after further investigation, I found it was indeed the ever-rolling log files causing the performance problem.  This is quite insidious, because the slow-down is proportional to the size of the original log file, so it gets gradually worse over time.

 

My immediate workaround was to stop the service, move the log files away, and restart.  This immediately resulted in much-improved performance.  My long-term solution will be to switch to the time-based rolling policy (http://logback.qos.ch/manual/appenders.html#TimeBasedRollingPolicy) unless and until JFrog tell me they’ve fixed the bug.  (This might not be appropriate if you find your logs get very large in a short space of time, but that’s not an issue for us.)

 

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 / [hidden email]

 

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.

 

From: Greene, Hugh
Sent: 19 September 2014 18:32
To: [hidden email]
Subject: RE: Artifactory perfomance tuning tips?

 

Hi again, all,

 

it’s really time for me to go home but, before I do, I wanted to report something which seems quite suspicious, in case anyone happens to come back with an answer before I get back to work on Monday :-)

 

While investigating, someone looking over my shoulder noticed that the access.log files seemed to be getting rotated quite often.  In fact, they seem to be getting rotated continuously, perhaps because the original log file isn’t getting trimmed down after rotation, so remains over threshold.  Using the trick below, I can see that one file is being updated every 3-4 seconds, then the next, then the next, and so on.  Perhaps coincidentally, one of our users said that he’d seen an initial delay of “about 4 seconds” at the start of every request, in a recent run where he looked at detailed logs.

 

(The trick is adapted from http://www.computerhope.com/forum/index.php?topic=114296.0:

 

forfiles /m access.*.log /c "cmd /c ECHO The last modified time of @file is: @ftime”

 

)

 

I see at <a href="http://www.jfrog.com/confluence/display/RTF/Artifactory&#43;Log&#43;Files">http://www.jfrog.com/confluence/display/RTF/Artifactory+Log+Files that the etc\logback.xml file controls rotation.  I haven’t changed this since install, and the file is the same as what was in place for 3.1.1.1, modulo some insignificant whitespace changes.  Maybe something else has changed in Artifactory in this area, or maybe this is not the cause, but I’ll investigate more on Monday …

 

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 / [hidden email]

 

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.

 

From: Greene, Hugh [[hidden email]]
Sent: 19 September 2014 13:14
To: [hidden email]
Subject: [Artifactory-users] Artifactory perfomance tuning tips?

 

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 / [hidden email]

 

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
______________________________________________________________________

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________


______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Artifactory-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/artifactory-users
Reply | Threaded
Open this post in threaded view
|

Re: Artifactory perfomance tuning tips?

Alex
Hi Hugh

We tried reproducing the issue you reported regarding the log file size but couldn’t successfully reproduce it on several scenarios.

In your case this issue might also be related either to I/O issues or network connectivity issues in case your log files are located on a network drive.

If this is not the issue in your case, you can decrease your log file’s maximum size, keeping the log file size to a size that does not affect your server’s performance; This can be done by modifying the ${artifactory_home}/etc/logback.xml file:

Just edit the relevant appender’s <MaxFileSize> tag (for the artifactory.log, the appender name is "FILE").
Please modify the size of the file to your desired size.
For example:

            <MaxFileSize>15MB</MaxFileSize>

Regards,
Alex
Reply | Threaded
Open this post in threaded view
|

Re: Artifactory perfomance tuning tips?

HughG_TMVSE
Hi Alex,

thanks for your suggestions, but I don't think any of them apply to us.

The files were on the same drive as the Artifactory install, with plenty of free space and low disk I/O usage.  I also used SysInternals Process Explorer to verify that only the Artifactory EXE had handles open on the file, and that it had two handles open, in the problem case.

I'm not surprised that you couldn't reproduce it, because I couldn't, either!  That is, I got the same behaviour on our production server even after restarting the service (and checking that all file handles were released), but was unable to reproduce the problem with a fresh install of Artifactory on a separate machine (my desktop PC), even when I dropped the same log files into its logs folder.

As for reducing the maximum size, the log file was already, at about 94MB, well over the default maximum size of 25MB.  The problem was that the roll-over process wasn't working as intended, as could be seen by looking at file operations using SysInternals Process Monitor.  The Artifactory process successfully zipped "access.log" to one of the 9 "access.<n>.log.zip" files, then tried to overwrite the original "access.log" file with an empty file -- but that failed, because the same Artifactory process had a second handle open on the file.  (Watching the same behaviour in my local install, I could see this second step succeed.)  This happened on every log message, taking 3-4 seconds each time.

So, I'm pretty convinced that Artifactory got into a bad state somehow, but I don't know how.


I have now replaced the logging with a time-based policy, like this:

    <appender name="ACCESS" class="ch.qos.logback.core.rolling.RollingFileAppender">
        <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
            <FileNamePattern>${artifactory.home}/logs/%d{yyyy,aux}/access.%d{yyyy-MM}.log.gz</FileNamePattern>
        </rollingPolicy>
        <encoder>
            <pattern>%d %m%n</pattern>
        </encoder>
    </appender>

This means that Artifactory no longer writes an "logs\access.log", only "logs\2014\access.2014-10.log" etc.  I've put a dummy log file in place at "logs\access.log" with a message directing people to look in the appropriate network share folder, so that admins who look at the logs in the web UI won't be confused by an empty log.  I've done the same for the other four logs, just in case, even though we only had a problem with the access.log.

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:[hidden email]

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.


-----Original Message-----
From: Alex [mailto:[hidden email]]
Sent: 05 October 2014 11:52
To: [hidden email]
Subject: Re: [Artifactory-users] Artifactory perfomance tuning tips?

Hi Hugh

We tried reproducing the issue you reported regarding the log file size but couldn’t successfully reproduce it on several scenarios.

In your case this issue might also be related either to I/O issues or network connectivity issues in case your log files are located on a network drive.

If this is not the issue in your case, you can decrease your log file’s maximum size, keeping the log file size to a size that does not affect your server’s performance; This can be done by modifying the ${artifactory_home}/etc/logback.xml file:

Just edit the relevant appender’s <MaxFileSize> tag (for the artifactory.log, the appender name is "FILE").
Please modify the size of the file to your desired size.
For example:

            <MaxFileSize>15MB</MaxFileSize>

Regards,
Alex




--
View this message in context: http://forums.jfrog.org/Artifactory-perfomance-tuning-tips-tp7579987p7579997.html
Sent from the Artifactory - Users mailing list archive at Nabble.com.

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Artifactory-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/artifactory-users

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com ______________________________________________________________________

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________
------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
_______________________________________________
Artifactory-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/artifactory-users