Update h2 windowing algo & Http Client benchmark (#388)

Author: TingDaoK

.github/workflows/ci.yml

@@ -64,24 +64,24 @@ jobs:
           - name: gcc-8
           - name: gcc-11
           - name: gcc-13
-          # See Issue: https://github.com/llvm/llvm-project/issues/59007. Although this issue 
-          # has been fixed in LLVM, the fix will probably not propagate to older versions of Ubuntu and GCC 13.1. 
+          # See Issue: https://github.com/llvm/llvm-project/issues/59007. Although this issue
+          # has been fixed in LLVM, the fix will probably not propagate to older versions of Ubuntu and GCC 13.1.
           #
-          # Starting with GLIBC version 2.34, the `dn_expand` function, previously found in `libresolv.so`, was moved to `libc.so`. This 
+          # Starting with GLIBC version 2.34, the `dn_expand` function, previously found in `libresolv.so`, was moved to `libc.so`. This
           # function is used internally by the `getaddrinfo()` system call.
           #
-          # In our setup (As of December 2024), we are using an Ubuntu 18 Docker image on a newer Ubuntu host. 
+          # In our setup (As of December 2024), we are using an Ubuntu 18 Docker image on a newer Ubuntu host.
           # However, due to compatibility issues between newer libasan.so in GCC 13.1
-          # and the older Ubuntu image, the linker does not link with `libresolv.so`. 
+          # and the older Ubuntu image, the linker does not link with `libresolv.so`.
           # This results in crashes in `getaddrinfo()` since Ubuntu-18 GLIBC is 2.31.
           #
-          # This problem does not occur on Ubuntu 22 and newer because GLIBC versions 2.34 
-          # and above include `dn_expand` in `libc.so`, eliminating the dependency on 
+          # This problem does not occur on Ubuntu 22 and newer because GLIBC versions 2.34
+          # and above include `dn_expand` in `libc.so`, eliminating the dependency on
           # `libresolv.so`.
           #
-          # We can bypass this problem by linking with "resolv" manually until we bump 
+          # We can bypass this problem by linking with "resolv" manually until we bump
           # our base Linux image to Ubuntu 22.
-            extra-build-flag: --cmake-extra=-DCMAKE_EXE_LINKER_FLAGS="-lresolv" 
+            extra-build-flag: --cmake-extra=-DCMAKE_EXE_LINKER_FLAGS="-lresolv"
     steps:
     - uses: aws-actions/configure-aws-credentials@v4
       with:

CMakeLists.txt

@@ -83,5 +83,6 @@ if (NOT BYO_CRYPTO AND BUILD_TESTING)
     add_subdirectory(tests)
     if (NOT CMAKE_CROSSCOMPILING)
         add_subdirectory(bin/elasticurl)
+        add_subdirectory(bin/h2benchmark)
     endif()
 endif()

bin/h2benchmark/CMakeLists.txt

@@ -0,0 +1,22 @@
+project(h2benchmark C)
+
+file(GLOB H2BENCHMARK_SRC
+        "*.c"
+        )
+
+set(PROJECT_NAME h2benchmark)
+add_executable(${PROJECT_NAME} ${H2BENCHMARK_SRC})
+aws_set_common_properties(${PROJECT_NAME})
+
+target_link_libraries(${PROJECT_NAME} aws-c-http)
+
+if (BUILD_SHARED_LIBS AND NOT WIN32)
+    message(INFO " h2benchmark will be built with shared libs, but you may need to set LD_LIBRARY_PATH=${CMAKE_INSTALL_PREFIX}/lib to run the application")
+endif()
+
+install(TARGETS ${PROJECT_NAME}
+        EXPORT ${PROJECT_NAME}-targets
+        COMPONENT Runtime
+        RUNTIME
+        DESTINATION ${CMAKE_INSTALL_BINDIR}
+        COMPONENT Runtime)

bin/h2benchmark/README.md

@@ -0,0 +1,10 @@
+# HTTP/2 benchmark
+
+this is a C program mimic the API call benchmark from aws-java-sdk-v2. https://github.com/aws/aws-sdk-java-v2/tree/master/test/sdk-benchmarks/src/main/java/software/amazon/awssdk/benchmark/apicall/httpclient
+
+It collects how many API calls finish per second. Basically how many request can made per second.
+
+The program connects to the local host that can be found [here](../../tests/py_localhost).
+
+To run the benchmark, build the h2benchmark with aws-c-http as dependency.
+TODO: Currently the configs are all hardcoded.