Чем отличается sampling от profiling java

Чем отличается sampling от profiling java

• The basics of TOGAF certification and some ways to prepare TOGAF offers architects a chance to learn the principles behind implementing an enterprise-grade software architecture, including.
• Haskell vs. PureScript: The difference is complexity Haskell and PureScript each provide their own unique development advantages, so how should developers choose between these two .
• A quick intro to the MACH architecture strategy While not particularly prescriptive, alignment with a MACH architecture strategy can help software teams ensure application .

• Postman API platform will use Akita to tame rogue endpoints Akita’s discovery and observability will feed undocumented APIs into Postman’s design and testing framework to bring them into .
• How to make use of specification-based test techniques Specification-based techniques can play a role in efficient test coverage. Choosing the right techniques can ensure thorough .
• GitHub Copilot Chat aims to replace Googling for devs GitHub’s public beta of Copilot Chat rolls out GPT-4 integration that embeds a chat assistant into Visual Studio, but concerns .

• Explore the key features of Microsoft Defender for Cloud Apps Monitoring and visibility are crucial when it comes to cloud security. Explore Microsoft Defender for Cloud Apps, and see how .
• 4 popular machine learning certificates to get in 2023 AWS, Google, IBM and Microsoft offer machine learning certifications that can further your career. Learn what to expect from each.
• Rein in services to avoid wasted cloud spend Organizations often make the easy mistake of duplicate purchases, which lead to wasted cloud spend. Learn strategies to avoid .

• Security hygiene and posture management: A work in progress Security hygiene and posture management may be the bedrock of cybersecurity, but new research shows it is still decentralized and.
• How to avoid LinkedIn phishing attacks in the enterprise Organizations and users need to be vigilant about spotting LinkedIn phishing attacks by bad actors on the large business social .
• Thoma Bravo sells Imperva to Thales Group for $3.6B With the acquisition, Thales looks to expand its Digital Security and Identity business with an increased focus on protecting web.

• AWS Control Tower aims to simplify multi-account management Many organizations struggle to manage their vast collection of AWS accounts, but Control Tower can help. The service automates .
• Break down the Amazon EKS pricing model There are several important variables within the Amazon EKS pricing model. Dig into the numbers to ensure you deploy the service .
• Compare EKS vs. self-managed Kubernetes on AWS AWS users face a choice when deploying Kubernetes: run it themselves on EC2 or let Amazon do the heavy lifting with EKS. See .

Источник

VisualVM CPU Sampling

If you need to investigate CPU related issues, sampling provides an easy mechanism for identifying bottlenecks, with minimal effects on the performance.

Sampling vs Profiling

First of all, let’s understand the difference between sampling and profiling, which is a key prerequisite.

Profiling

Profiling involves instrumenting the entire application code or only some classes in order to provide runtime performance metrics to the profiler application. Since this involves changes to the application code, which are applied automatically by the profiler, it also means that there is a certain performance impact and risk of affecting the existing functionality.

The actual degree of the performance impact is hard to determine, but it can become significant if CPU intensive sections are instrumented.

Profiling is usually recommended for optimizing specific algorithms or when you’re interested in measuring the invocation counts.

Sampling

Sampling on the other side works by periodically retrieving thread dumps from the JVM. In this case, the performance impact is minor (and constant since the thread dumps are retrieved using a fixed frequency) and there’s no risk of introducing side effects. This process is a lot less intrusive and can also be performed quite reliably on remote applications (i.e. it could even be applied to production instances).

The main downside of CPU sampling is the accuracy — since the thread dump is retrieved at fixed intervals, there is a high risk of missing certain method invocations (especially the very fast ones). This means that the invocation count of methods is very innacurrate, but the total spent time (and CPU time) should still provide some relavant metrics.

When to Use CPU Sampling

Unless you are interested in very precise performance metrics (albeit affected by the added cost of instrumentation), you should use sampling most of the time. The main advantage of profiling is its accuracy, but since there’s the performance impact added by instrumentation, most of the performance metrics will be off by an unknown factor.

How to Run CPU Sampling

Local applications

For local applications, launch VisualVM from the JDK binary directory,

1. Select (double click) on the process that you would like to monitor on the left hand screen.
2. Click on the “Sampler” tab
3. When you are ready to perform your test, select the button “CPU” next to the “Sample” tab.
4. Once the test has finished, press “Stop” and press the “Snapshot” button.

Please keep in mind that the data displayed before taking a snapshot may or may not be very accurate. You should do your analysis only on snapshots.

A common error that people do when following this steps is to take an actual screenshot of the sampling screen. While it’s nice they were so thoughtful, the data is mostly pointless — as most of the time the performance bottlenecks will be somewhere deeper in the call hierarchy and will not be seen from the overview.

Remote applications

For remote applications, the process is very similar but it requires setting up a JMX connection to the Java process to be monitored.

1. Enable the JMX port on your application. This is outside the scope of this article, but you can check the official Oracle documentation for more details: Monitoring and Management Using JMX Technology
2. Right click on the “Remote” tab in the left hand screen.
3. Select “Add Remote Host”
4. Fill in the host name. Most of the times, this will be sufficient but depending on how you’ve enabled JMX on the remote process, you may need to also check the “Advanced Settings” tab.
5. Right click on the newly added host and select “Add JMX connection”.
6. Fill in the connection details (including port number) and the display name. If you’re application is deployed using multiple processes, you should enter a descriptive display name.
7. Double click on the newly added JMX connection.
8. From this point onwards, the steps are identical with the ones from “Local applications”.

How to Interpet the Data

This depends a lot on the actual issues that you’re trying to investigate and the application architecture. For example, if you have a desktop application with a fixed amount of threads, the call tree with the break down per thread may be useful.

However, if you’re working on a web application with a variable number of threads, it will probably be hard to figure out what’s happening. In this case, you should probably start from thet “Hot spots” tab and dig deeper from there.

Difference between “Self Time” and “Self Time (CPU)”

VisualVM reports two metrics related to the duration, but there is a significant difference between them:

• self time — counts the total time spent in that method, including the amount of time spent on locks or other blocking behaviour
• self time (cpu) — counts the total time spent in that method, excluding the amount of time the thread was blocked

From here, you will need to decide on what you want to focus,

• if you want to focus on optimising the multithreaded interactions, then you should aim for the self time values including the time the threads were blocked
• if you’re interested in the overall performace and not care too much about the multithreaded interactions, then should focus solely on the self time (cpu).

Be careful though on how you interpret your results. If you have a thread that keeps a connection open, most likely you will see some very large numbers for the self time. This is normal and it’s not issue.

Источник

Profiling Vs. Sampling in Java’s VisualVM

Most people will already be familiar with profiling, but you might be less aware of the different types of profilers on offer. A recent issue we had upon the release of Java 8 proved awkward to resolve using a traditional profiler, but Sampling proved well suited to the task.

Helpfully, Java comes with both a traditional profiler and a sampler in the form of VisualVM. I’m just going to be talking about CPU profiling, although the approaches to memory are similar.

VisualVM’s profiler works by “instrumenting” all of the methods of your code. This adds extra bytecode to your methods for recording when they’re called, and how long they take to execute each time they are.

VisualVM’s sampler, however, takes a dump of all of the threads of execution on a fairly regular basis, and uses this to work out how roughly how much CPU time each method spends.

So what was our problem with profiling?

We test our software by running our PDF to HTML5 converter on a large number of diverse PDF files which make use of different parts of the PDF specification and flagging up any changes in the output. On Java 8, this was taking 48 minutes.

One problem with instrumented profiling is that it adds a constant amount of extra execution time to every single method call. Sometimes – such as in image processing – small, quick methods are called many, many times, adding a great deal of time to the execution. Profiling our tests this way would take hours!

Sampling, however, takes a more or less constant amount of time each second to record stack traces for each thread. This only added 5 – 10 minutes of execution time in total, and still provided us with a good idea of where the problems lay.

One quirk of sampling is that the number of invocations recorded is not necessarily accurate, since a short method could easily start and finish between stack dumps. It appeared as though a method in our library was called three times as often in Java 8 as it was in Java 7 – the truth, however, is that it was taking three times as long, and thus was three times as likely to be caught in a dump.

Perhaps the lesson here is that sampling is most useful for recording the amount of CPU time spent, rather than the number of invocations. Still, there’s a very high chance that this will identify any problems, and do it much faster than the standard profiler.

Which do you prefer? Let us know in the comments below.

Are you a Developer working with PDF files?

Our developers guide contains a large number of technical posts to help you understand the PDF file Format.

Do you need to solve any of these problems?

Sam Howard Sam is a developer at IDRsolutions who specialises in font rendering and conversion. He’s also enjoyed working with SVG, Java 3D, Java FX and Swing.

Источник