| | 17 | == Experimenting with Jinja2 (2.8) |
| | 18 | |
| | 19 | Nothing like a few numbers to make a point ;-) |
| | 20 | |
| | 21 | These are the timings for rendering !r3871, with the diff options set to side-by-side, in place modifications, served by tracd on my development laptop. This generates a page weighing 11.5MB (Genshi) to 10.3MB (Jinja2) in size. |
| | 22 | |
| | 23 | || ||||||||= Genshi ||||||||||||||||||||||||= Jinja2 || |
| | 24 | || ||||= stream ||||= blob ||||= generate ||||= stream (5) ||||= stream (10) ||||= stream (100) ||||= stream (1000) ||||= blob || |
| | 25 | || ||= 1st ||= 2nd ||= 1st ||= 2nd ||= 1st ||= 2nd ||= 1st ||= 2nd ||= 1st ||= 2nd ||= 1st ||= 2nd ||= 1st ||= 2nd ||= 1st ||= 2nd || |
| | 26 | ||= TTFB || 16600||**15670**|| 25530|| 24460|| 2020|| 1160|| 2030|| 1160|| 2070|| 1170|| 2150|| **1230**|| 2280|| 1230|| 3370|| 2450|| |
| | 27 | ||= CD || 16090||**16050**|| 387|| 1240|| 2820|| 2720|| 2730|| 2640|| 2730|| 2680|| 2470|| **2390**|| 2350|| 2250|| 488|| 1060|| |
| | 28 | |------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| | 29 | ||= Total|| 32690|| 31720|| 25917|| 25700|| 4840|| 3880|| 4760|| 3800|| 4800|| 3850|| 4620|| 3620|| 4630|| 3480|| 3850|| 3510|| |
| | 30 | ||= Rdr || --|| --|| 23533||**23273**|| --|| --|| --|| --|| --|| --|| --|| --|| --|| --|| 1477||**1263**|| |
| | 31 | |
| | 32 | Some explanations: |
| | 33 | - Genshi (0.7 with speedups) |
| | 34 | - ''stream'' means we return content via `Stream.serialize` and send chunks as we have them |
| | 35 | - ''blob'' means we first generate all the content in memory with `Stream.render`, then send it at once |
| | 36 | - Jinja2 (2.8 with [http://www.pocoo.org/projects/markupsafe/ speedups]) |
| | 37 | - ''generate'' means we use `Template.generate` and send chunks as we have them |
| | 38 | - ''stream'' means we use the `TemplateBuffer` wrapper on the above, which groups a few chunks (given by the number in parenthesis) together before we send them; |
| | 39 | for a chunk size of **100**, we get the best compromise: still a very low TTFB and a reduced Content download time; actually the sweet spot is probably between |
| | 40 | 10 and 100, and will most certainly depend on the actual content (I just tested 75 which gives 1160/2430 for example) |
| | 41 | - ''blob'' means we first generate all the content in memory with `Template.render` |
| | 42 | - both: |
| | 43 | - ''1st'' is the time in ms for the first request, sent right after a server restart |
| | 44 | - ''2nd'' is the time in ms for the second request, sent just after the first (usually the 3rd and subsequent requests would show the same results as this 2nd request) |
| | 45 | |
| | 46 | We measure: |
| | 47 | - TTFB (Time to first byte), as given by Chrome network panel in the developer window |
| | 48 | - CD (Content download), idem |
| | 49 | - Rdr (template rendering time), mostly significant for the "blob" method otherwise it also takes the network latency into account |
| | 50 | |
| | 51 | Note that even if the total "blob" time seems better than the total "stream" one, the lower TTFB is nevertheless a major benefit for the streaming variant, as this means the secondary requests can start earlier (and in this case, finish before the main request). |
| | 52 | |
| | 53 | In addition, while I didn't measure precisely the memory usage, Genshi made the python.exe process jump from 109MB to 239MB while rendering the request (blob). The memory seems to be freed afterwards (there were no concurrent requests). By contrast, with Jinja2 the memory spike was 106MB to 126MB. |
| | 54 | |
| | 55 | In summary, this means that for the big problematic pages, we can easily have a 10x speedup and more, by migrating to Jinja2,and this with a much lighter memory footprint. |
| | 56 | For smaller pages, the speed-up is between 5x to 10x as well. |
