Update Async Profiler doc (#12842)

docs/en/concepts-and-designs/profiling.md

@@ -19,9 +19,6 @@ In the SkyWalking landscape, we provided three ways to support profiling within
 In-process profiling is primarily provided by auto-instrument agents in the VM-based runtime.
 
 ### Tracing Profiling
-Learn more tech details from the post, [**Use Profiling to Fix the Blind Spot of Distributed
-Tracing**](sdk-profiling.md).
-
 This feature resolves the issue <1> through capture the snapshot of the thread stacks periodically.
 The OAP would aggregate the thread stack per RPC request, and provide a hierarchy graph to indicate the slow methods
 based
@@ -30,20 +27,25 @@ on continuous snapshot.
 The period is usually every 10-100 milliseconds, which is not recommended to be less, due to this capture would usually
 cause classical stop-the-world for the VM, which would impact the whole process performance.
 
+Learn more tech details from the post, [**Use Profiling to Fix the Blind Spot of Distributed
+Tracing**](sdk-profiling.md).
+
 For now, Java and Python agents support this.
 
-### Async Profiler
+### Java App Profiling
+
+Java App Profiling uses the [AsyncProfiler](https://github.com/async-profiler/async-profiler) for sampling
 
 Async Profiler is a low overhead sampling profiler for Java that does not suffer from Safepoint bias problem. It features HotSpot-specific APIs to collect stack traces and to track memory allocations. The profiler works with OpenJDK and other Java runtimes based on the HotSpot JVM.
 
-async-profiler can trace the following kinds of events:
+Async Profiler can trace the following kinds of events:
 
-CPU cycles
-Hardware and Software performance counters like cache misses, branch misses, page faults, context switches etc.
-Allocations in Java Heap
-Contented lock attempts, including both Java object monitors and ReentrantLocks
+- CPU cycles
+- Allocations in Java Heap
+- Contented lock attempts, including both Java object monitors and ReentrantLocks
+- and [more](https://github.com/async-profiler/async-profiler/blob/master/docs/ProfilingModes.md)
 
-For now, Java agent support this.
+Only Java agent support this.
 
 ## Out-of-process profiling
 

docs/en/setup/backend/backend-java-app-profiling.md

@@ -1,19 +1,32 @@
-# Async Profiler
+# Java App Profiling
+
+Java App Profiling uses the AsyncProfiler for sampling
 
 Async Profiler is bound within the auto-instrument agent and corresponds to [In-Process Profiling](../../concepts-and-designs/profiling.md#in-process-profiling).
 
-It is passed to the proxy in the form of a task, allowing it to be enabled or disabled dynamically.
-When service encounters performance issues (cpu usage, memory allocation, locks), async-profiler task can be created.
-When the proxy receives a task, it enables Async Profiler for sampling.
-After sampling is completed, a flame graph will be generated for performance analysis to determine the specific business code line that caused the performance problem.
+It is delivered to the agent in the form of a task, allowing it to be enabled or disabled dynamically.
+When service encounters performance issues (cpu usage, memory allocation, locks), Async Profiler task can be created.
+When the agent receives a task, it enables Async Profiler for sampling.
+After sampling is completed, the sampling results are analyzed by requesting the server to render a flame graph for performance 
+analysis to determine the specific business code lines that cause performance problems.
 
-## Activate async profiler in the OAP
+## Activate Async Profiler in the OAP
 OAP and the agent use a brand-new protocol to exchange Async Profiler data, so it is necessary to start OAP with the following configuration:
 
 ```yaml
 receiver-async-profiler:
-  selector: ${SW_RECEIVER_ASYNC_PROFILER:default}
-  default:
+   selector: ${SW_RECEIVER_ASYNC_PROFILER:default}
+   default:
+      # Used to manage the maximum size of the jfr file that can be received, the unit is Byte, default is 30M
+      jfrMaxSize: ${SW_RECEIVER_ASYNC_PROFILER_JFR_MAX_SIZE:31457280}
+      # Used to determine whether to receive jfr in memory file or physical file mode
+      #
+      # The memory file mode have fewer local file system limitations, so they are by default. But it costs more memory.
+      #
+      # The physical file mode will use less memory when parsing and is more friendly to parsing large files.
+      # However, if the storage of the tmp directory in the container is insufficient, the oap server instance may crash.
+      # It is recommended to use physical file mode when volume mounting is used or the tmp directory has sufficient storage.
+      memoryParserEnabled: ${SW_RECEIVER_ASYNC_PROFILER_MEMORY_PARSER_ENABLED:true}
 ```
 
 ## Async Profiler Task with Analysis
@@ -45,18 +58,18 @@ When the Agent receives a Async Profiler task from OAP, it automatically generat
 
 ### Wait the agent to collect data and upload
 
-At this point, async-profiler will trace the following kinds of events:   
+At this point, Async Profiler will trace the events you selected when you created the task:
 
-1. CPU cycles
-2. Hardware and Software performance counters like cache misses, branch misses, page faults, context switches etc.
-3. Allocations in Java Heap
-4. Contented lock attempts, including both Java object monitors and ReentrantLocks
+1. CPU,WALL,ITIMER,CTIMER: CPU cycles
+2. ALLOC: Allocations in Java Heap
+3. LOCK: Contented lock attempts, including both Java object monitors and ReentrantLocks
 
-Finally, java agent will upload the jfr file produced by async-profiler to the oap server for online performance analysis.
+Finally, the agent will upload the jfr file produced by Async Profiler to the oap server for online performance analysis.
 
 ### Query the profiling task progresses
 
-Wait for async-profiler to complete data collection and upload successfully，We can query the execution log of the async-profiler task and the successful and failed instances,which includes the following information:
+Wait for Async Profiler to complete data collection and upload successfully.
+We can query the execution logs of the Async Profiler task and the task status, which includes the following information:
 
 1. **successInstanceIds**: SuccessInstanceIds gives instances that have executed the task successfully.
 2. **errorInstanceIds**: ErrorInstanceIds gives instances that failed to execute the task.

docs/menu.yml

@@ -260,8 +260,8 @@ catalog:
             path: "/en/setup/backend/backend-ebpf-profiling"
           - name: "Continuous Profiling"
             path: "/en/setup/backend/backend-continuous-profiling"
-          - name: "Async Profiler"
-            path: "/en/setup/backend/backend-async-profiler"
+          - name: "Java App Profiling"
+            path: "/en/setup/backend/backend-java-app-profiling"
       - name: "Event"
         path: "/en/concepts-and-designs/event/"
       - name: "Extension"