[ZODB-Dev] ZODB blob support.
Christian Theune
ct at gocept.com
Tue Mar 22 00:11:25 EST 2005
Hi all.
I packed up a Zope 2.8 with my ZODB branch for blobs and implemented a
"stupid" OFS.Blob.File object and made some simple "ab" tests. Here are
the results of the "high tuned" OFS.File.File (without blob) versus the
most simple OFS.Blob.File (but with blob support):
ab2 was called this way: ab2 -n 1000 -c 20 http://localhost:8080/asdf
Round 1, filesize ~200k
=======================
OFS.File.File
-------------
Concurrency Level: 20
Time taken for tests: 7.100714 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 215900603 bytes
HTML transferred: 215632268 bytes
Requests per second: 140.83 [#/sec] (mean)
Time per request: 142.014 [ms] (mean)
Time per request: 7.101 [ms] (mean, across all concurrent
requests)
Transfer rate: 29692.79 [Kbytes/sec] received
This one didn't get all connections through and dropped a couple
sockets. Therefore the amount of data transferred differs.
OFS.Blob.File
-------------
Concurrency Level: 20
Time taken for tests: 5.539628 seconds
Complete requests: 1000
Failed requests: 998
(Connect: 0, Length: 998, Exceptions: 0)
Write errors: 0
Non-2xx responses: 2
Total transferred: 215248884 bytes
HTML transferred: 215084695 bytes
Requests per second: 180.52 [#/sec] (mean)
Time per request: 110.793 [ms] (mean)
Time per request: 5.540 [ms] (mean, across all concurrent
requests)
Transfer rate: 37945.33 [Kbytes/sec] received
Funnily this one also kicked _one_ (exactly the last) connection...
Round 2, filesize ~70MB
=======================
OFS.File.File
-------------
No stats. The server spilled my harddisk after about 100 Requests, I had
to kill ab.
OFS.Blob.File
-------------
Memory and disk usage is pretty low, the python producer spills out the
data constantly with about ~100 MB per second (loopback). This takes a
while, though.
The python process loads the cpu pretty much, this could be better. :)
Concurrency Level: 20
Time taken for tests: 500.718270 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: -89217134 bytes
HTML transferred: -89385104 bytes
Requests per second: 2.00 [#/sec] (mean)
Time per request: 10014.365 [ms] (mean)
Time per request: 500.718 [ms] (mean, across all concurrent
requests)
Transfer rate: -174.00 [Kbytes/sec] received
Obviously, the second round was even for OFS.Blob.File bound by the
internal transfer rate of the loopback device and other overhead stuff.
I decided to go for a third round with less data again:
Round 3, filesize ~5MB
======================
OFS.File.File
-------------
Concurrency Level: 20
Time taken for tests: 297.781491 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 696487394 bytes
HTML transferred: 696216872 bytes
Requests per second: 3.36 [#/sec] (mean)
Time per request: 5955.630 [ms] (mean)
Time per request: 297.781 [ms] (mean, across all concurrent
requests)
Transfer rate: 2284.10 [Kbytes/sec] received
In this case python did not use more RAM. The process was very
disk-based IO bound. Python couldn't make use of the complete CPU due to
that and used it about 25%.
OFS.Blob.File
-------------
Concurrency Level: 20
Time taken for tests: 35.506402 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 682015648 bytes
HTML transferred: 681848696 bytes
Requests per second: 28.16 [#/sec] (mean)
Time per request: 710.128 [ms] (mean)
Time per request: 35.506 [ms] (mean, across all concurrent
requests)
Transfer rate: 18758.03 [Kbytes/sec] received
This didn't end in any unexpected ends. No connections dropped. The
process made full use of the CPU.
So, for a first shot, on a prototype. This looks pretty promising to me.
Especially as I didn't have to do anything special for an application
object to support this, code handling blobs is likely to get _much_ more
robust.
Cheers,
Christian
--
gocept gmbh & co. kg - schalaunische str. 6 - 06366 koethen - germany
www.gocept.com - ct at gocept.com - phone +49 3496 30 99 112 -
fax +49 3496 30 99 118 - zope and plone consulting and development
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : http://mail.zope.org/pipermail/zodb-dev/attachments/20050322/4beddf30/attachment.bin
More information about the ZODB-Dev
mailing list