Wt embedded » History » Revision 8
Revision 7 (Pieter Libin, 10/29/2009 03:00 PM) → Revision 8/31 (Koen Deforche, 03/16/2010 07:35 AM)
h1. Wt embedded
{{toc}}
Find here information on running Wt in resource constrained embedded systems: performance, code size, memory usage, and other info.
h2. General
Wt can easily be built for and deployed on embedded POSIX systems, such as embedded linux.
h3. Cross-building
Using CMake with a cross compilation environment: to be completed...
Instructions for cross compiling with cmake can be found on the "CMake Wiki":http://www.cmake.org/Wiki/CMake_Cross_Compiling. If you encounter the following error a workaround is to replace $Build/src/filetostring with a version compiled with your native compiler.
<pre>
/bin/sh: ./filetostring: cannot execute binary file
</pre>
h3. Optimizing executable size
Points to consider when optimizing the executable size. size:
For building boost:
* Use static build of boost, which allows the linker to strip away unused symbols Choose build-type <tt>MinSizeRel</tt>
* Use the following Add extra compile flags for boost:
** @-fvisibility=hidden -fvisibility-inlines-hidden@: to FLAGS: <tt>-fvisibility=hidden</tt> (to avoid exporting listing symbols in the executable executable)
** @-ffunction-sections -fdata-sections@: to allowing fine-grained garbage collection of unused functions/data
For building Wt:
* Choose build-type @MinSizeRel@
* Extra Add extra compile falgs (@CMAKE_CXX_FLAGS@)
** @-fvisibility=hidden -fvisibility-inlines-hidden@: FLAGS: -DHAVE_GNU_REGEX to avoid exporting symbols in the executable
** @-ffunction-sections -fdata-sections@: to allowing finegrained garbage collection of unused functions/data
** @-DHAVE_GNU_REGEX@: to avoid the dependency on libboost_regex, when building on a system that is based on glibc or uClibc uClibc.
** @-DWT_NO_LAYOUT@: * _*Add extra compile FLAGS: -DNO_SPIRIT to avoid pulling in the Wt's layout managers, if you are not using any WLayout classes
** @-WT_NO_SPIRIT@: to avoid depending on use spirit to parse for parsing locale and cookies (if you don't need that)
** @-DWT_NO_XSS_FILTER@: to avoid the extra (runtime) overhead of XSS filtering, usually (FIXME: not relevant for a trusted embedded platform yet supported)*_
* Build static libraries (for libwt.a and libwthttp.a)
** in CMake: @SHARED_LIBS:BOOL=OFF@
* Disable build options you don't need and introduce extra dependencies (libz, openssl ?)
* Further tune your linker command:
** Append @-v@ Link statically to the linker command used by CMake to see the raw @collect2@ command-line.
** By default, shared/static all libraries is all-or-nothing with CMake. However, that you probably want to use system-wide versions of libstdc++, libm and libc depending on other applications on your device.
*** Use -Bdynamic in front of libraries you wish to link dynamically against
** There are some other flags that you only for Wt (such as for example the boost libraries). You will need to use to make sure do this manually since this currently isn't supported in the linker does not keep unused symbols: CMake build process. In this way, only used symbols from these libraries (including the static wt and wthttp) will be kept.
*** Remove @-export-dynamic@
*** Add @--gc-sections@
* Strip your binary using <tt>strip -s</tt>.
* Optionally, when available for your platform, you may want to compress the size of your binary using the "Ultimate Packer for eXecutables (upx)":http://upx.sourceforge.net/. This typically reduces executable size further by 60-70%, without noticable run-time performance hits.
h3. Measuring performance
To report the run-time performance of Wt on a particular embedded platform, you must connect to the device using a local area connection (through at most one switch), and measure the time between transmission and reception of packets (using a packet sniffer). For the measurements, we use two examples that are included in the Wt distribution: "hello":http://www.webtoolkit.eu/wt/examples/hello/hello.wt (as an example of a minimal application), and "composer":http://www.webtoolkit.eu/wt/examples/composer/composer.wt (as an example of a simple, yet functional, application).
We propose to measure the time to create a new session, and the time of a small event.
h4. Runtime: new session
Wt starts a new session by serving a small page to determines browser capabilities, and then trigger a second call to get the "main page", that has all visible content. To compare the relative performance for a particular platform, you should measure this "load" time, as the total duration of these two requests. You should measure the time from sending the first request, to sending the third request. The third request is either a GET request for auxiliary content (CSS or images), a GET request to a Wt resource, or a POST request to load invisible content in the background.
h4. Runtime: event
We estimate the time needed to process a small event, such as a click on the "Greet me" button in hello, and "Save now" in composer, by measuring the total time for the packet exchange triggered by such an event.
h4. Memory usage: basis
Measuring memory usage is a tricky thing, since code and read-only data memory used by shared libraries is effectively shared between processes, while writable data segments are obviously private to each process.
Therefore, we use <tt>pmap</tt> to study the memory in different segments. The basis RAM usage is divided between read-only segments, and writable segments. Only the latter are really constrained by physical RAM. We get the total writable size. by summing the size of all writable segments, indicated by pmap with a *w*. The total size reported by pmap and top, minus the size of all writable segments is then the read-only RAM usage. Thus, this number includes shared libraries, and thus overestimates actual RAM usage.
h4. Memory usage: per session
Compare the memory usage after starting 10 sessions with base memory usage, and divide the difference by 10 to estimate the memory used by a single session.
h2. Platforms
h3. ARM926EJ-S
h4. Processor features
* Clock-speed: 200 MHz
* Linux BogoMIPS: 89.70
* Caches: 8K instruction, 8K data
Configurations are ordered chronically, latest first.
h4. Config 2: #1: minimal (16/03/2010)
h5. Setup
* *Wt version:* git (16/03/2010, >= Wt 3.1.1)
* *Target system:* Linux uclibc 2.6.23
* *Build environment:* buildroot, arm-linux-gcc 4.2.1
* *Options:* without multi-threading, libz and OpenSSL
* *Build type:* full static build, except for: libstdc++, libc, libm and libstdc++
* *Runtime settings:* ./app.wt --docroot . --http-address 0.0.0.0 --no-compression
h5. Performance results
*Code size and RAM usage (in KBytes)*
|_.Program|_.Code size (strip)|_.Code size (strip + upx)|_.RAM: basis † (read-only)|_.RAM: basis (writable)|_.RAM: per session|
| hello| 1.130 | 304 | 2.580 | 372 | 28|
| composer| 1.462 | 420 | 2.712 | 372 | 126|
† includes shared libraries !
*Runtime-performance*
|_.Program |_.New session (http) |_.Event (http)|
| hello | 0. s | 0.15 s |
|composer| 0.69 s | 0.08 s |
h4. Config 1: minimal (18/03/2008)
h5. Setup
* *Wt version:* CVS-snapshot 18/03/08
* *Target system:* Linux uclibc 2.6.23
* *Build environment:* buildroot, arm-linux-gcc 4.2.1
* *Options:* with multi-threading, but without libz and OpenSSL
* *Build type:* full static build, except for: libc, libpthread, libdl, libstdc++, and libm
* *Build settings:* MinSizeRel, -DHAVE_GNU_REGEX
* *Runtime settings:* ./app.wt --docroot . --http-address 0.0.0.0 --threads=2 --no-compression
h5. Performance results
*Code size and RAM usage (in KBytes)*
|_.Program|_.Code size (strip)|_.Code size (strip + upx)|_.RAM: basis † (read-only)|_.RAM: basis (writable)|_.RAM: per session|
| hello| 1.130 | 304 | 2.580 | 372 | 28|
| composer| 1.265 | 332 | 2.712 | 372 | 126|
† includes shared libraries !
*Runtime-performance*
|_.Program |_.New session (http) |_.Event (http)|
| hello | 0.58 s | 0.15 s |
|composer| 1.8 s | 0.15 s |