Having security software installed can have an impact on an application’s startup time. Learn how to measure startup time and instrument your code to identify where you can optimize for faster performance.

<a href="https://www.elastic.co/blog/practical-cpu-time-performance-tuning-security-software">In a previous blog</a>, we discussed how to monitor, troubleshoot, and fix high %CPU issues. We also revealed a system API that could have an unexpected impact on CPU consumption. In this episode, we’ll discuss another time-related performance aspect that is unique to security software: application startup time. You don’t need to be a developer to benefit from this article. As long as you are curious to find out how the applications in your environment perform and why sometimes they seem to be very slow and want to improve that, you might find this blog post helpful.
 <h2>What is application startup time?</h2>Security software usually sits along the critical path an application takes when it is about to launch or execute. The software makes the decision either to block or allow the launching/execution of the application. The decision-making process takes time and therefore impacts the launching speed of the application. To test application startup time, you might choose a popular application in your environment, such as Microsoft Word, Outlook, PowerPoint, Chrome, Edge, Safari, or Visual Studio, and measure the time between double-clicking the application (or invoking it from the command line) and when the application UI is fully ready for user interaction. If an application is popular and likely to be common in most customers’ environments, then it’s also worth testing the application’s startup time as part of in-house performance testing.
A variety of different tools can be used to measure application startup time, ranging from a stopwatch to more sophisticated automated tools. I wrote <a href="https://github.com/Trinity2019/WinWordStartupTime">a simple Windows program</a> to measure how fast my Microsoft Word program launches. I also encourage you to find or create your favorite tool and start to measure things.
 <h2>Establish a baseline</h2>First of all, we need to measure the application’s startup time without the security software installed. That result will be used as the baseline to compare the startup time when the software is installed and actively running. Then keeping everything else the same in the environment, we’ll install the security software, make sure it’s fully functional, and measure the application startup time again. This result will be compared with the baseline to get an idea of the software’s impact on the application’s startup time.
 <h2>Set a goal</h2>It shouldn’t be a surprise to find out that it always takes longer for the application to start up with security software running. If you are the developer, you want to optimize the security software so its impact is as small as possible — ideally, zero impact.
However, in the real world, trying to achieve zero impact would make performance tuning a never ending task. You need to have a clear goal to know when performance is good enough to stop tuning. For example, you could set an impact threshold of 10%, which would mean that any impact on application startup time of less than 10% of the baseline value would be considered acceptable. Alternatively, you could define acceptable impact in terms of human perception — if the baseline value is 10 milliseconds and the startup time with security software running is 20 milliseconds, you can probably consider this to be an acceptable level of impact, since the difference of 10 milliseconds likely won’t be noticed by users. There may be other criteria that are best suited for your product.
 <h2>Isolate the problem</h2>Let’s say that you’ve identified unacceptably long delays caused by a security product. If you are a user of the security product, it’s time to report the issue to the vendor. The developers will then try to reproduce the issue in-house; however, they may not always succeed due to unpredictable environmental factors. In such a case, the developers will need your help narrowing down the problem to one or a few features. To do this, measure application startup time with and without various features enabled until you’re able to pinpoint the specific features that have the biggest impact.
 <h2>Instrumentation profilers</h2>After isolating the problem, you have helped the developers narrow down the problem area to one or a few functions. Now it’s time for the developers to go back to the source code. Instead of using a profiling tool as described in <a href="https://www.elastic.co/blog/practical-cpu-time-performance-tuning-security-software">our earlier blog</a>, this time we suggest using instrumentation to find out how fast or slow each function runs.
Instrumentation is inserting code into your program to collect information. The instrumentation code is usually small, so it does not introduce too much extra cost to your program or return confusing results. One good way to limit the impact of the instrumentation code is to apply it to debug builds only — enclosing the instrumentation in #ifdef DEBUG and #endif pairs so it doesn’t have any impact on your release build.&nbsp;
To find out which part of the code introduces a long delay during runtime, we typically add code that collects time information to measure the time being spent on particular parts of the code. There are many options for doing this. For example, on Windows, the easiest way could be placing <a href="https://docs.microsoft.com/en-us/windows/win32/api/sysinfoapi/nf-sysinfoapi-gettickcount64">GetTickCount64() </a>at the entrance and exit of a function and subtracting the return values to obtain the approximate execution time of a function. See the following example:
<pre class="prettyprint">int Foo() 
{ 
 ULONGLONG start = GetTickCount64(); 
 …… // Foo() function logic here 
 ULONGLONG stop = GetTickCount64(); 
 ULONGLONG duration = stop - start; 
 printf("Time interval from start to stop is: %d(ms)", duration); 
 return 0; 
}
</pre>Other than that, the C++ library provides std::chrono::steady_clock, which is compatible across operating systems and is easy to use. Here's<a href="https://en.cppreference.com/w/cpp/chrono/steady_clock/now"> an example of using std::chrono::steady_clock to get time duration</a>.&nbsp;
The <a href="https://github.com/Trinity2019/macOSStaticCodeCheck">checkCSInfoObserveCPU</a> sample also demonstrates a simple example of using <a href="https://www.manpagez.com/man/3/clock_gettime/">clock_gettime</a> to get the time that was taken to use SecStaticCodeCheckValidityWithErrors on the code object of Xcode. The instrumented code printed out the following result that shows it took 134 seconds for the API to validate Xcode’s code object:
<code>SecStaticCodeCheckValidityWithErrors took 134 seconds to finish.</code>
Therefore, by using code instrumentation, we have successfully identified the hot spot in our sample, which is SecStaticCodeCheckValidityWithErrors — an Apple security framework API. Again, the purpose of the sample is not to question Apple’s implementation of SecStaticCodeCheckValidity* on the performance side. Instead, it is a proof-of-concept showing that code signing validation against large bundles is CPU-intensive. If such a function is called by security software inside of the critical path during an application’s launch stage, it can result in significant increases in application startup time.
 <h2>Fix</h2>In <a href="https://www.elastic.co/blog/practical-cpu-time-performance-tuning-security-software">our earlier blog</a>, we proposed a fix for the sample program, which is telling SecStaticCodeCheckValidityWithErrors to not validate the presence and contents of all bundle resources (if any). It indeed made the program run dramatically faster; however, it comes at the price of sacrificing the overall bundle security. Therefore, we should carefully evaluate our needs, make tradeoffs, and choose the optimal fixes. Sometimes, in order to fix a performance issue, changes must be made on a design level.
Let’s take a step back and look at what we need. If SecStaticCodeCheckValidity* was used to validate the codesign information of a process, then we need to find another way to achieve the same without using SecStaticCodeCheckValidity*.&nbsp;
Luckily, we do have another option. The macOS <a href="https://developer.apple.com/documentation/endpointsecurity">Endpoint Security</a> (ES) framework provides the process’s code signing information along with every event it passes to a third-party ES extension. <a href="https://www.elastic.co/blog/macos-windows-what-kernels-tell-you-about-security-events-part-1">I wrote an article about the new macOS System Extensions and the ES framework</a> last year. The article mentions that the signing information is available for each ES event (the following example was collected by <a href="https://objective-see.com/products/utilities.html">ProcessMonitor</a> on macOS 10.15.6 when launching Xcode 12.2):
<pre class="prettyprint"> "signing info (reported)" : 
 { 
 "teamID" : "APPLECOMPUTER", 
 "csFlags" : 570452481, 
 "signingID" : "com.apple.dt.Xcode", 
 "platformBinary" : 0, 
 "cdHash" : "6BEB4DCEA2E64B149BB2314EB71652694DA195BE" 
 }
</pre>The macOS ES framework puts a process’s code signing information in <a href="https://developer.apple.com/documentation/endpointsecurity/es_process_t?language=objc">es_process_t</a>, which comes with every event’s message(<a href="https://developer.apple.com/documentation/endpointsecurity/es_message_t?language=objc">es_message_t</a>), and passes the information to third-party ES extensions. es_process_t structure is defined in XCode’s SDK header file:
<pre class="prettyprint">/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/EndpointSecurity/ESMessage.h
</pre>Please note the codesigning_flags, signing_id, and team_id fields in es_process_t and carefully read the documentation in the header file (the header file includes more detailed explanations than the online document for <a href="https://developer.apple.com/documentation/endpointsecurity/es_process_t?language=objc">es_process_t</a>). codesigning_flags can be used to check the process’s code signing state that the kernel has already validated under certain conditions. signing_id and team_id can be used to identify the process without having to call the security framework APIs. Apple also provides a <a href="https://developer.apple.com/documentation/endpointsecurity/monitoring_system_events_with_endpoint_security">sample ES extension</a> that demonstrates how to deny or allow an application’s execution based on the signing_id that comes with the event’s message.
 <h2>Summary</h2>A number of things can impact security software performance. It could be just a tiny bug, but it might also be a mistake in architectural design. Although improving performance is usually a long-term and consistent ongoing effort, the techniques described in this blog series are proven to be useful. Regardless of which stage of development you’re in and what part of the product you’re working on, it’s always better to take performance into consideration as early as possible, even before development cycles begin, instead of trying to fix performance issues later.
If you’re wondering how things perform in your environment, try installing <a href="https://www.elastic.co/observability">Elastic Observability</a>. It provides these cool <a href="https://www.elastic.co/guide/en/observability/7.13/host-metrics.html">metrics</a> to help you identify performance issues.

blog-banner-tuning-piano.jpg

blog-thumb-tuning-piano.jpg

Practical CPU time performance tuning for security software: Part 2

In this blog post, we identify security software performance issues related to high %CPU usage on macOS, and explain how to fix and avoid them in future.

“Wasting other people’s time is tantamount to robbery and murder, and wasting one’s own time is tantamount to chronic suicide.”&nbsp;- Lu Xun
Software performance issues come in all shapes and sizes. Therefore, performance tuning includes many aspects and subareas, and has to adopt a broad range of methodologies and techniques. Despite all this, time is one of the most critical measurements of software performance.&nbsp;
In this multi-part series, I’ll focus on a few of the time-related aspects of software performance — particularly for security software. Each post in this series will focus on a single topic, including how to identify performance issues, how to fix them, and how to avoid them in future.&nbsp;
<h2>%CPU</h2>Let’s start by diving into a high %CPU usage example on macOS. I wrote a demo program called <a href="https://github.com/Trinity2019/macOSStaticCodeCheck">checkCSInfoObserveCPU</a> to demonstrate how system API may introduce unexpected performance overhead. The source code can be downloaded <a href="https://github.com/Trinity2019/macOSStaticCodeCheck">here</a>. While the sample program only runs on macOS, the general approach we’ll cover here is common for all operating systems.&nbsp;
<h3>Monitor CPU</h3>First, you’ll need a tool to monitor %CPU usage. There are many choices for such tools. My favorite tool on macOS is <a href="https://support.apple.com/guide/activity-monitor/view-cpu-activity-actmntr43452/mac">Activity Monitor</a>, because it comes with each macOS installation and has a nice graphic interface. <a href="https://ss64.com/osx/top.html">top</a> is also a popular tool — available both on macOS and Linux — and can be used for %CPU monitoring. On Windows, <a href="https://www.howtogeek.com/405806/windows-task-manager-the-complete-guide/">Windows Task Manager</a> is a good choice for such tasks.
The following picture shows the Activity Monitor. Note the area enclosed with a red circle. Select that dropdown in descending order so that the %CPU column is ordered from highest to lowest.
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt5260058d57899305/60c9317c9b520349ac9cf19a/1-descending-cpu-usage-blog.png" data-sys-asset-uid="blt5260058d57899305" alt="" style="display: block; margin: auto;">
Next, I compile&nbsp;my sample program, <a href="https://github.com/Trinity2019/macOSStaticCodeCheck">checkCSInfoObserveCPU</a>, from source code into binary(debug build by default). I double click&nbsp;it to run while closely monitoring the changes shown by Activity Monitor.
Note: Make sure the Console program is not running on your macOS. This is to eliminate the impact of logging on the running speed of your program.
Soon after the program was launched, %CPU usage of checkCSInfoObserveCPU jumped over 300% on my test machine. The program ran for about two minutes, and its %CPU was pegged between 100-600% until the program exited.
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt53f3f2e67d6e4728/60c931a483f9fe49a6fed28a/2-info-observe-cpu-usage-blog.png" data-sys-asset-uid="blt53f3f2e67d6e4728" alt="" style="display: block; margin: auto;">
Depending on the hardware spec, if you run the same program on different machines, you may get a different %CPU range. For example, on my physical MacBook Pro with eight cores, the program costs 100-600% CPU. But on my virtual machine with four cores, the same program costs 100~200% CPU and takes a longer time to finish. Generally speaking, if the program consistently costs more than 100% CPU for a prolonged period of time, it’s a sign that the program isn’t optimized.
<h3>Find the hot spot</h3>Now that we’ve established that the program checkCSInfoObserveCPU is consuming abnormally high %CPU, we’ll want to find out why and&nbsp; understand which part of the code is causing it (aka find the bottleneck, or hot spot).&nbsp;
macOS provides a profiling tool called <a href="https://www.manpagez.com/man/8/spindump/">spindump</a>, which is perfect for this job. It profiles the entire system during a time interval (10 seconds by default), so you can analyze the execution of your program during that interval and identify the hot spots in your program. The spindump needs to be run while the high CPU is happening so it can capture the smoking gun. For detailed information about spindump, please run “man spindump” in <a href="https://support.apple.com/guide/terminal/open-or-quit-terminal-apd5265185d-f365-44cb-8b09-71a064a42125/mac">Terminal</a>. Apple also provides an <a href="https://support.apple.com/guide/activity-monitor/run-system-diagnostics-actmntr2225/mac">article</a> that shows how to invoke spindump from Activity Monitor.
I’ve collected the spindump output while my sample program was running as an example. In the output, we can find a list of threads that were running inside of checkCSInfoObserveCPU when the spindump was taken. It also shows lots of useful information, such as the threads’ CPU time and their callstacks. The top two most CPU-consuming call stacks inside of the program are:
<pre class="prettyprint"> Thread 0x849d4f DispatchQueue "com.apple.main-thread"(1) 1001 samples (1-1001) priority 31-46 (base 31) cpu time 7.782s (18.1G cycles, 28.8G instructions, 0.63c/i) 
 1001 start + 1 (libdyld.dylib + 89917) [0x7fff2044df3d] 
 1001 main + 122 (main.m:27,9 in checkCSInfoObserveCPU + 15498) [0x10308ac8a] 
 1001 -[checkStaticCSInfo checkStaticCSInfoOnPath:withRequirement:] + 427 (checkStaticCSInfo.m:65,14 in checkCSInfoObserveCPU + 14811) [0x10308a9db] 
 1001 SecStaticCodeCheckValidityWithErrors + 187 (Security + 1673198) [0x7fff224517ee] 
 1001 Security::CodeSigning::SecStaticCode::staticValidate(unsigned int, Security::CodeSigning::SecRequirement const*) + 2714 (Security + 1716598) [0x7fff2245c176]
</pre><pre class="prettyprint"> Thread 0x849d7e,0x849dfe,0x849e39,0x849eef,0x849ef7,0x849ef9,0x84a00d,0x84a00e,0x84a1b0,0x84a1b2,0x84a1b3,0x84a1b1,0x849ffc,0x84a1be,0x84a1b4,0x84a1af DispatchQueue "com.apple.root.default-qos"(10) 3062 samples (1-1001) priority 31-46 (base 31) cpu time 19.152s (45.1G cycles, 49.4G instructions, 0.91c/i) 
 3062 start_wqthread + 15 (libsystem_pthread.dylib + 9363) [0x7fff2042e493] 
 3062 _pthread_wqthread + 244 (libsystem_pthread.dylib + 13434) [0x7fff2042f47a] 
 3062 _dispatch_worker_thread2 + 92 (libdispatch.dylib + 77648) [0x7fff20297f50] 
 3062 _dispatch_root_queue_drain + 326 (libdispatch.dylib + 75768) [0x7fff202977f8] 
 3056 _dispatch_queue_override_invoke + 1035 (libdispatch.dylib + 24347) [0x7fff2028af1b] 
 3054 _dispatch_client_callout + 8 (libdispatch.dylib + 14310) [0x7fff202887e6] 
 3039 _dispatch_call_block_and_release + 12 (libdispatch.dylib + 9731) [0x7fff20287603] 
 3035 invocation function for block in Security::Dispatch::ExceptionAwareEnqueuing::enqueueWithDispatcher(void (void () block_pointer) block_pointer, void () block_pointer) + 30 (Security + 2802612) [0x7fff225653b4] 
 3032 invocation function for block in Security::CodeSigning::LimitedAsync::perform(Security::Dispatch::Group&, void () block_pointer) + 36 (Security + 1772422) [0x7fff22469b86] 
 3002 invocation function for block in Security::CodeSigning::SecStaticCode::validateResources(unsigned int) + 612 (Security + 1704213) [0x7fff22459115] 
 2223 Security::CodeSigning::SecStaticCode::validateResource(__CFDictionary const*, std::__1::basic_string&lt;char, std::__1::char_traits&lt;char&gt;, std::__1::allocator&lt;char&gt; &gt;, bool, Security::CodeSigning::SecStaticCode::ValidationContext&, unsigned int, unsigned int) + 4319 (Security + 1708977) [0x7fff2245a3b1] 
 2175 Security::CodeSigning::CodeDirectory::multipleHashFileData(Security::UnixPlusPlus::FileDesc, unsigned long, std::__1::set&lt;unsigned int, std::__1::less&lt;unsigned int&gt;, std::__1::allocator&lt;unsigned int&gt; &gt;, void (unsigned int, Security::DynamicHash*) block_pointer) + 626 (Security + 1762824) [0x7fff22467608] 
 1448 Security::CodeSigning::scanFileData(Security::UnixPlusPlus::FileDesc, unsigned long, void (void const*, unsigned long) block_pointer) + 160 (Security + 1761985) [0x7fff224672c1] 
 1433 read + 10 (libsystem_kernel.dylib + 7486) [0x7fff203fdd3e]
</pre>In the first call stack, we find that the program checkCSInfoObserveCPU stepped into Apple’s security framework function <a href="https://developer.apple.com/documentation/security/1395252-secstaticcodecheckvaliditywither?language=objc">SecStaticCodeCheckValidityWithErrors</a> and never stepped out during the whole sampling time period. Now it’s time to go back to the <a href="https://github.com/Trinity2019/macOSStaticCodeCheck">source code</a> and confirm our findings. The source code shows that the program does indeed call SecStaticCodeCheckValidityWithErrors <a href="https://github.com/Trinity2019/macOSStaticCodeCheck/blob/62a9aca8e63ba689c0019619cda995f1a74b302f/checkCSInfoObserveCPU/checkCSInfoObserveCPU/checkStaticCSInfo.m#L65">once</a> to check up on the code object of <a href="https://github.com/Trinity2019/macOSStaticCodeCheck/blob/62a9aca8e63ba689c0019619cda995f1a74b302f/checkCSInfoObserveCPU/checkCSInfoObserveCPU/main.m#L22">Xcode</a>.&nbsp;
However, in the source code, the program doesn’t call any of the functions shown in the second stack. It also doesn’t create threads shown in the second call stack. So then where do the threads come from? In fact, they are helper threads created by the security framework in serving the request from SecStaticCodeCheckValidityWithErrors. That’s why even though in the source code we didn’t explicitly start any helper threads, we still found multiple threads within the running program, and they made the CPU even busier.
Now we find the function SecStaticCodeCheckValidityWithErrors is the culprit here. SecStaticCodeCheckValidityWithErrors is a system library function implemented by Apple. Does it mean the function implementation is bad and we should report a bug to Apple? Not in this case. Validating code signature is a computing-intensive task — especially when the target to validate is a large bundle such as Xcode, high CPU consumption is expected.&nbsp;
<h3>Fixing high %CPU</h3>Fixing your high %CPU usage will vary depending on the specific issue, the function of your product, and many other factors. Our sample here is used to demonstrate that calling SecStaticCodeCheckValidityWithErrors on a large bundle is CPU-intensive. However, SecStaticCodeCheckValidity* is a very convenient API — security software often needs to call this API to collect signature information of other programs. If you cannot avoid using such APIs, it’s best to be really careful choosing the circumstances where it is used. Generally speaking, using it on small bundles is still affordable.
For this particular sample, we could easily fix the high %CPU usage by changing one line of code <a href="https://github.com/Trinity2019/macOSStaticCodeCheck/blob/512850db6cc3b3a3c31d2a5df595a8a002f66bcb/checkCSInfoObserveCPU/checkCSInfoObserveCPU/checkStaticCSInfo.m#L75">here</a>, as shown below:
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt2a7f385f88a6db5c/60c931c7eefdde56c1143acf/3-high-usage-cpu-usage-blog.png" data-sys-asset-uid="blt2a7f385f88a6db5c" alt="" style="display: block; margin: auto;">
This fix changes the input parameter SecCSFlags from kSecCSDefaultFlags to kSecCSDoNotValidateResources, which tells the API to not validate the presence and contents of all bundle resources (if any). After this change, the sample program checkCSInfoObserveCPU finished instantly without consuming significant %CPU and other resources.
However, in this fix, the API caller sacrificed the overall bundle security in exchange for less %CPU consumption. Therefore, when fixing performance issues, nothing comes free. We should carefully evaluate all kinds of tradeoffs and choose the fix that best suits our needs.
<h2>Wrapping up</h2>In the next post of this series, we’ll&nbsp;discuss another time-related performance topic that's more unique to security software. Stay tuned.
In the meantime, you can install the latest version of <a href="https://www.elastic.co/security">Elastic Security on Elastic Cloud</a>, and be sure to take advantage of our <a href="https://www.elastic.co/training/elastic-security-quick-start">quick start training</a> to set yourself up for success.

Practical CPU time performance tuning for security software: Part 1

We explore the system-level differences of OS events supported by Windows and macOS for effective endpoint security analysis, allowing you to adapt to differences and enrich your toolsets.

blog-banner-security-radar-anomaly-monitor.png

blog-thumb-security-radar-anomaly-monitor.png

macOS vs. Windows – What kernels tell you about security events: Part 2

Explore the system level differences of OS events supported by Windows and macOS for effective endpoint security analysis, allowing you to adapt to differences and enrich your toolsets.

macOS vs. Windows – What kernels tell you about security events: Part 1

Start free trial

Blog Footer CTA

Sign up for Elastic Cloud free trial

Yamin Tian

By submitting you acknowledge that you've read and agree to our <a href="/legal/elastic-cloud-account-terms" target="_self">Terms of Service</a>, and you agree to receive the <a href="/legal/privacy-statement#how-we-use-the-information" target="_self">selected communications</a> at the contact details you provided above. See <a href="/legal/privacy-statement/" target="_self">Elastic’s Privacy Statement</a> for more details or to opt-out at any time.

Communication Preferences - ONLY for /communication-preferences

제출하면 귀하가 <a href="/kr/legal/elastic-cloud-account-terms" target="_self">Elastic 서비스 약관</a>을 읽고 이에 동의하며, 위에 제공된 연락처로 <a href="/kr/legal/privacy-statement#how-we-use-the-information" target="_self">선택한 커뮤니케이션</a>을 수신하는 데 동의한 것으로 간주됩니다. 언제든지 수신을 거부할 수 있으며 자세한 내용은 <a href="/kr/legal/privacy-statement/" target="_self">Elastic 개인정보 취급방침</a>을 참조하시기 바랍니다.

By submitting you acknowledge that you've read and agree to our <a href="/legal/serverless-preview-terms" target="_blank">Terms of Service</a>, and that Elastic may <a href="/legal/privacy-statement#how-we-use-the-information" target="_blank">contact you</a> about our related products and services, using the details you provide above. See <a href="/legal/privacy-statement/" target="_blank">Elastic’s Privacy Statement</a> for more details or to opt-out at any time.

Serverless GDPR Text

제출하면 귀하가 Elastic <a href="/kr/legal/serverless-preview-terms" target="_self">서비스 약관</a>을 읽고 이에 동의하며, 위에 제공된 세부 정보를 사용하여 Elastic이 관련 제품 및 서비스에 대해 귀하에게 <a href="/kr/legal/privacy-statement#how-we-use-the-information" target="_self">연락할 수 있음</a>을 이해한 것으로 간주됩니다. 언제든지 수신을 거부할 수 있으며 자세한 내용은 <a href="/kr/legal/privacy-statement/" target="_self">Elastic 개인정보 취급방침</a>을 참조하시기 바랍니다.

By submitting you agree to <a href="/agreements/global/cloud-services-monthly" rel="nofollow">Elastic Cloud Terms of Service</a>. Your personal data will be processed in accordance with <a href="/legal/privacy-statement">Elastic's Privacy Statement</a>.

Cloud Trial GDPR Text

제출하면 <a href="/kr/agreements/global/cloud-services-monthly" rel="nofollow">Elastic Cloud 서비스 약관</a>에 동의하시게 됩니다. 개인 데이터는 <a href="/kr/legal/privacy-statement">Elastic의 개인정보 취급방침</a>에 따라 처리됩니다.

By submitting you acknowledge that you've read and agree to our <a href="/legal/terms-of-use" target="_blank">Terms of Service</a>, and that Elastic may <a href="/legal/privacy-statement#how-we-use-the-information" target="_blank">contact you</a> about our related products and services, using the details you provide above. See <a href="/legal/privacy-statement/" target="_blank">Elastic’s Privacy Statement</a> for more details or to opt-out at any time.

Newsletter GDPR Text

제출하면 귀하가 Elastic <a href="/kr/legal/terms-of-use" target="_self">서비스 약관</a>을 읽고 이에 동의하며, 위에 제공된 세부 정보를 사용하여 Elastic이 관련 제품 및 서비스에 대해 귀하에게 <a href="/kr/legal/privacy-statement#how-we-use-the-information" target="_self">연락할 수 있음</a>을 이해한 것으로 간주됩니다. 언제든지 수신을 거부할 수 있으며 자세한 내용은 <a href="/kr/legal/privacy-statement/" target="_self">Elastic 개인정보 취급방침</a>을 참조하시기 바랍니다.

Explore similar demos

Overview

Speakers

Close

See more insights

The content on this page is not available in the selected language. As Elastic grows globally, we continue to support content in multiple languages.

The content on this page is not available in the selected language.

이 페이지의 콘텐츠는 선택하신 언어로 제공되지 않습니다. Elastic은 다양한 언어로 콘텐츠를 제공하기 위해 최선을 다하고 있습니다.조금만 더 기다려주세요!

Author

Articles by

Learn more

Watch now (no PT)

Watch now

See all top stories

All (no PT translation)

Contact information

Press Release

Share on Reddit

Share this story

Share by Email

Thank you for your interest!

Contact Info

Follow us on Youtube

Load More

Share on LinkedIn

Follow us on LinkedIn

Search Integrations

All Solutions

Video for

Follow us on Twitter

See when this webinar starts in my time zone

내 표준 시간대로 웨비나 시작 시간 확인하기

Register to Watch

Register now

See All Posts

Can't make it? Register and we'll send you the recording. You'll also receive an email with related content

참여가 어려우신가요? 등록하시면 녹화 자료를 보내드리겠습니다. 이메일로 관련 콘텐츠도 받아보실 수 있습니다.

Small image for

On-demand webinar

Featured webinar

Register to Attend

Share on Facebook

Reset all

Upcoming webinar

View more posts

Print

Hosted by

Sign In to Attend

View next

Follow us on Facebook

Share

Highlights

Read less

You'll also receive an email with related content

이메일을 통해 관련 내용을 보내드리겠습니다.

Thank you for registering. We will send you a confirmation email soon.

등록해 주셔서 감사합니다. 곧 확인 이메일을 보내드리겠습니다.

Author

Articles by Yamin Tian

Practical CPU time performance tuning for security software: Part 2

Practical CPU time performance tuning for security software: Part 1

macOS vs. Windows – What kernels tell you about security events: Part 2

macOS vs. Windows – What kernels tell you about security events: Part 1

Sign up for Elastic Cloud free trial