|
| 1 | +Zephyr HTTP Server |
| 2 | +================== |
| 3 | + |
| 4 | +Overview |
| 5 | +-------- |
| 6 | + |
| 7 | +This sample application demonstrates the use of the ``http_server`` library. |
| 8 | +This library provides high-level functions to simplify and abstract server implementation. |
| 9 | +The server supports the HTTP/1.1 protocol which can also be upgraded to HTTP/2, |
| 10 | +it also support native HTTP/2 protocol without upgrading. |
| 11 | + |
| 12 | +Requirement |
| 13 | +----------- |
| 14 | + |
| 15 | +`QEMU Networking <https://docs.zephyrproject.org/latest/connectivity/networking/qemu_setup.html#networking-with-qemu>`_ |
| 16 | + |
| 17 | +Building and running the server |
| 18 | +------------------------------- |
| 19 | + |
| 20 | +To build and run the application: |
| 21 | + |
| 22 | +.. code-block:: bash |
| 23 | +
|
| 24 | + $ west build -p auto -b <board_to_use> -t run samples/net/sockets/http_server |
| 25 | +
|
| 26 | +When the server is up, we can make requests to the server using either HTTP/1.1 or |
| 27 | +HTTP/2 protocol from the host machine. |
| 28 | + |
| 29 | +**With HTTP/1.1:** |
| 30 | + |
| 31 | +- Using a browser: ``http://192.0.2.1/`` |
| 32 | +- Using curl: ``curl -v --compressed http://192.0.2.1/`` |
| 33 | +- Using ab (Apache Bench): ``ab -n10 http://192.0.2.1/`` |
| 34 | + |
| 35 | +**With HTTP/2:** |
| 36 | + |
| 37 | +- Using nghttp client: ``nghttp -v --no-dep http://192.0.2.1/`` |
| 38 | +- Using curl: ``curl --http2 -v --compressed http://192.0.2.1/`` |
| 39 | +- Using h2load: ``h2load -n10 http://192.0.2.1/`` |
| 40 | + |
| 41 | +Server Customization |
| 42 | +--------------------- |
| 43 | + |
| 44 | +The server sample contains several parameters that can be customized based on |
| 45 | +the requirements. These are the configurable parameters: |
| 46 | + |
| 47 | +- ``CONFIG_NET_SAMPLE_HTTP_SERVER_SERVICE_PORT``: Configures the service port. |
| 48 | + |
| 49 | +- ``CONFIG_HTTP_SERVER_MAX_CLIENTS``: Defines the maximum number of HTTP/2 |
| 50 | + clients that the server can handle simultaneously. |
| 51 | + |
| 52 | +- ``CONFIG_HTTP_SERVER_MAX_STREAMS``: Specifies the maximum number of HTTP/2 |
| 53 | + streams that can be established per client. |
| 54 | + |
| 55 | +- ``CONFIG_HTTP_SERVER_CLIENT_BUFFER_SIZE``: Defines the buffer size allocated |
| 56 | + for each client. This limits the maximum length of an individual HTTP header |
| 57 | + supported. |
| 58 | + |
| 59 | +- ``CONFIG_HTTP_SERVER_MAX_URL_LENGTH``: Specifies the maximum length of an HTTP |
| 60 | + URL that the server can process. |
| 61 | + |
| 62 | +To customize these options, we can run ``west build -t menuconfig``, which provides |
| 63 | +us with an interactive configuration interface. Then we could navigate from the top-level |
| 64 | +menu to: ``-> Subsystems and OS Services -> Networking -> Network Protocols``. |
| 65 | + |
| 66 | +Performance Analysis |
| 67 | +-------------------- |
| 68 | + |
| 69 | +CPU Usage Profiling |
| 70 | +******************* |
| 71 | + |
| 72 | +We can use ``perf`` to collect statistics about the CPU usage of our server |
| 73 | +running in native_sim board with the ``stat`` command: |
| 74 | + |
| 75 | +.. code-block:: bash |
| 76 | +
|
| 77 | + $ sudo perf stat -p <pid_of_server> |
| 78 | +
|
| 79 | +``perf stat`` will then start monitoring our server. We can let it run while |
| 80 | +sending requests to our server. Once we've collected enough data, we can |
| 81 | +stop ``perf stat``, which will print a summary of the performance statistics. |
| 82 | + |
| 83 | +Hotspot Analysis |
| 84 | +**************** |
| 85 | + |
| 86 | +``perf record`` and ``perf report`` can be used together to identify the |
| 87 | +functions in our code that consume the most CPU time: |
| 88 | + |
| 89 | +.. code-block:: bash |
| 90 | +
|
| 91 | + $ sudo perf record -g -p <pid_of_server> -o perf.data |
| 92 | +
|
| 93 | +After running our server under load (For example, using ApacheBench tool), |
| 94 | +we can stop the recording and analyze the data using: |
| 95 | + |
| 96 | +.. code-block:: bash |
| 97 | +
|
| 98 | + $ sudo perf report -i perf.data |
| 99 | +
|
| 100 | +After generating a file named ``perf.data`` which contains the profiling data, |
| 101 | +we can visualize it using ``FlameGraph`` tool. It's particularly useful for |
| 102 | +identifying the most expensive code-paths and inspect where our application is |
| 103 | +spending the most time. |
| 104 | + |
| 105 | +To do this, we need to convert the ``perf.data`` to a format that ``FlameGraph`` |
| 106 | +can understand: |
| 107 | + |
| 108 | +.. code-block:: bash |
| 109 | +
|
| 110 | + $ sudo perf script | ~/FlameGraph/stackcollapse-perf.pl > out.perf-folded |
| 111 | +
|
| 112 | +And, then, generate the ``FlameGraph``: |
| 113 | + |
| 114 | +.. code-block:: bash |
| 115 | +
|
| 116 | + $ ~/FlameGraph/flamegraph.pl out.perf-folded > flamegraph.svg |
| 117 | +
|
| 118 | +We can view flamegraph.svg using a web browser. |
0 commit comments