Http Client benchmark

.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:
@@ -280,3 +280,35 @@ jobs:
       run: |
         python -c "from urllib.request import urlretrieve; urlretrieve('${{ env.BUILDER_HOST }}/${{ env.BUILDER_SOURCE }}/${{ env.BUILDER_VERSION }}/builder.pyz?run=${{ env.RUN }}', 'builder.pyz')"
         python builder.pyz build -p aws-c-http --cmake-extra=-DENABLE_LOCALHOST_INTEGRATION_TESTS=ON --config Debug
+
+  localhost-canary-linux:
+    runs-on: ubuntu-24.04 # latest
+    steps:
+    - name: Checkout
+      uses: actions/checkout@v4
+    - name: Build and test
+      run: |
+        python3 -c "from urllib.request import urlretrieve; urlretrieve('${{ env.BUILDER_HOST }}/${{ env.BUILDER_SOURCE }}/${{ env.BUILDER_VERSION }}/builder.pyz?run=${{ env.RUN }}', 'builder.pyz')"
+        python3 builder.pyz build -p aws-c-http --cmake-extra=-DAWS_BUILD_CANARY=ON --config Debug
+
+  localhost-canary-mac:
+    runs-on: macos-14 # latest
+    steps:
+    - name: Checkout
+      uses: actions/checkout@v4
+    - name: Build and test
+      run: |
+        python3 -m venv .venv
+        source .venv/bin/activate
+        python3 -c "from urllib.request import urlretrieve; urlretrieve('${{ env.BUILDER_HOST }}/${{ env.BUILDER_SOURCE }}/${{ env.BUILDER_VERSION }}/builder.pyz?run=${{ env.RUN }}', 'builder.pyz')"
+        python3 builder.pyz build -p aws-c-http --cmake-extra=-DAWS_BUILD_CANARY=ON --config Debug
+
+  localhost-canary-win:
+    runs-on: windows-2022 # latest
+    steps:
+    - name: Checkout
+      uses: actions/checkout@v4
+    - name: Build and test
+      run: |
+        python -c "from urllib.request import urlretrieve; urlretrieve('${{ env.BUILDER_HOST }}/${{ env.BUILDER_SOURCE }}/${{ env.BUILDER_VERSION }}/builder.pyz?run=${{ env.RUN }}', 'builder.pyz')"
+        python builder.pyz build -p aws-c-http --cmake-extra=-DAWS_BUILD_CANARY=ON --config Debug

CMakeLists.txt

@@ -3,6 +3,7 @@ project(aws-c-http C)
 
 option(ENABLE_PROXY_INTEGRATION_TESTS "Whether to run the proxy integration tests that rely on pre-configured proxy" OFF)
 option(ENABLE_LOCALHOST_INTEGRATION_TESTS "Whether to run the integration tests that rely on pre-configured localhost" OFF)
+option(AWS_BUILD_CANARY "Whether to build the canary for benchmark the performance of our http client" OFF)
 
 if (NOT IN_SOURCE_BUILD)
     # this is required so we can use aws-c-common's CMake modules
@@ -83,5 +84,8 @@ if (NOT BYO_CRYPTO AND BUILD_TESTING)
     add_subdirectory(tests)
     if (NOT CMAKE_CROSSCOMPILING)
         add_subdirectory(bin/elasticurl)
+        if (AWS_BUILD_CANARY)
+            add_subdirectory(bin/canary)
+        endif()
     endif()
 endif()

bin/canary/CMakeLists.txt

@@ -0,0 +1,28 @@
+project(canary C)
+
+list(APPEND CMAKE_MODULE_PATH "${CMAKE_INSTALL_PREFIX}/lib/cmake")
+
+file(GLOB CANARY_SRC
+        "*.c"
+        )
+
+set(PROJECT_NAME canary)
+add_executable(${PROJECT_NAME} ${CANARY_SRC})
+aws_set_common_properties(${PROJECT_NAME})
+
+target_include_directories(${PROJECT_NAME} PUBLIC
+        $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/include>
+        $<INSTALL_INTERFACE:include>)
+
+target_link_libraries(${PROJECT_NAME} aws-c-http)
+
+if (BUILD_SHARED_LIBS AND NOT WIN32)
+    message(INFO " canary 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 bin
+        COMPONENT Runtime)