summaryrefslogtreecommitdiff
blob: 3da34eed165f1ff1f2dd642642c524ba14483541 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
# https://bugs.gentoo.org/719846
# Probably related to https://github.com/sphinx-doc/sphinx/issues/4225
#
# Warning, treated as error:
# /var/tmp/portage/app-emulation/ganeti-2.15.2-r9/temp/gntbuild.tiR1shJ6/doc/design-impexp2.rst:512:Could not lex literal_block as "python". Highlighting skipped.

--- a/doc/design-impexp2.rst	2020-04-30 23:40:50.121698365 +0000
+++ b/doc/design-impexp2.rst	2020-04-30 23:41:05.692129339 +0000
@@ -507,32 +507,6 @@
 respective system (measured for the CGI/FastCGI program using ``time
 -v``).
 
-::
-
-  ----------------------------------------------------------------------
-  Block size                      4 KB    64 KB   128 KB    1 MB    4 MB
-  ======================================================================
-  Plain CGI script reading          83      174      180     122     120
-  from ``/dev/zero``
-                               0.6/3.9  0.1/2.4  0.1/2.2 0.0/1.9 0.0/2.1
-  ----------------------------------------------------------------------
-  FastCGI with ``fcgiwrap``,        86      167      170     177     174
-  ``dd`` reading from
-  ``/dev/zero``                  1.1/5  0.5/2.9  0.5/2.7 0.7/3.1 0.7/2.8
-  ----------------------------------------------------------------------
-  FastCGI with ``fcgiwrap``,        68      146      150     170     170
-  Python script copying from
-  ``/dev/zero`` to stdout
-                               1.3/5.1  0.8/3.7  0.7/3.3  0.9/2.9  0.8/3
-  ----------------------------------------------------------------------
-  FastCGI, Python script using      31       48       47       5       1
-  ``flup`` library (version
-  1.0.2) reading from
-  ``/dev/zero``
-                              23.5/9.8 14.3/8.5   16.1/8       -       -
-  ----------------------------------------------------------------------
-
-
 It should be mentioned that the ``flup`` library is not implemented in
 the most efficient way, but even with some changes it doesn't get much
 faster. It is fine for small amounts of data, but not for huge