On 04/15/2010 06:00 PM, Adam GROSZER wrote:
Hello Christian,
Wednesday, April 14, 2010, 8:30:50 AM, you wrote:
CT> I don't think the transfer rate is actually that interesting. For small
CT> but many transactions the seek time/spinning speed should have the
CT> limiting influence.
CT> I'v
Am 15.04.2010, 20:52 Uhr, schrieb Jim Fulton :
> On Tue, Apr 13, 2010 at 8:42 PM, Nitro wrote:
>> Am 14.04.2010, 04:08 Uhr, schrieb Laurence Rowe :
>>
>>> Running your test script on my small amazon EC2 instance on linux
>>> takes between 0.0 and 0.04 seconds (I had to remove the divide by
>>> to
On Wed, Apr 14, 2010 at 2:39 AM, Wichert Akkerman wrote:
> On 4/14/10 08:24 , Christian Theune wrote:
>
>> I'm pretty sure it's not. IIRC fsync is defined by POSIX and absolutely
>> requires the implementor to flush data physically to disk ensuring its
>> persistency. If that doesn't hold true the
On Tue, Apr 13, 2010 at 8:42 PM, Nitro wrote:
> Am 14.04.2010, 04:08 Uhr, schrieb Laurence Rowe :
>
>> Running your test script on my small amazon EC2 instance on linux
>> takes between 0.0 and 0.04 seconds (I had to remove the divide by
>> total to avoid a zero division error). 0.02 is 5000/s.
>
Hello Christian,
Wednesday, April 14, 2010, 8:30:50 AM, you wrote:
CT> I don't think the transfer rate is actually that interesting. For small
CT> but many transactions the seek time/spinning speed should have the
CT> limiting influence.
CT> I've run the attached script a couple of times on my
Am 14.04.2010, 14:45 Uhr, schrieb Hanno Schlichting :
> Usually you will only loose the last transaction and not a days of
> work. The Data.fs is an append-only file, with one transaction
> appended after another. If there's a garbled or incomplete write,
> you'll typically loose the last transact
On Wed, Apr 14, 2010 at 11:52 AM, Nitro wrote:
> Yes, in my case it's nothing critical or related to money. If there's a
> hardware outage a day of work is lost at worst. In case of corruption
> (which can happen also without fsync as data within the file can just be
> garbled) you need a backup a
Am 14.04.2010, 09:24 Uhr, schrieb Christian Theune :
>> What I don't really get is why you should never use "None" on windows.
>> As
>> far as I can judge from the various transaction rates in the thread Tim
>> mentioned, fsync is just a no-op on linux anyways (depending on the
>> specific file
On 4/14/10 08:24 , Christian Theune wrote:
> I'm pretty sure it's not. IIRC fsync is defined by POSIX and absolutely
> requires the implementor to flush data physically to disk ensuring its
> persistency. If that doesn't hold true then all transactions are borked.
That was the problem with fsync
On 04/14/2010 01:25 AM, Nitro wrote:
40 tps sounds low: are you pushing blob content over the wire somehow?
>>
>> I have seen the ZEO storage committing transactions at least an order of
>> magnitude faster than that (e.g., when processing incoming newswire
>> feeds). I would guess that there
On 04/14/2010 03:30 AM, Nitro wrote:
> Am 14.04.2010, 04:39 Uhr, schrieb Tim Peters:
>
>> [Nitro]
>>> ...
>>> I wonder if _commit is really *that* slow
>>
>> Six years ago I timed factor-of-100 speed differences due to using MS
>> _commit() on WinXP at the time:
>>
>> https://mail.zope.org/pip
For the record, with
import os
os.fsync = lambda fd: 0
at the top of the test app I get ~3700 tx/s.
-Matthias
___
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/
ZODB-Dev mailing list - ZODB-Dev@zope.org
https://m
Am 14.04.2010, 04:39 Uhr, schrieb Tim Peters :
> [Nitro]
>> ...
>> I wonder if _commit is really *that* slow
>
> Six years ago I timed factor-of-100 speed differences due to using MS
> _commit() on WinXP at the time:
>
> https://mail.zope.org/pipermail/zodb-dev/2004-July/007720.html
>
>> or if
Am 14.04.2010, 04:08 Uhr, schrieb Laurence Rowe :
> Running your test script on my small amazon EC2 instance on linux
> takes between 0.0 and 0.04 seconds (I had to remove the divide by
> total to avoid a zero division error). 0.02 is 5000/s.
I don't know how EC2 works in detail, but 5000 transac
[Nitro]
> ...
> I wonder if _commit is really *that* slow
Six years ago I timed factor-of-100 speed differences due to using MS
_commit() on WinXP at the time:
https://mail.zope.org/pipermail/zodb-dev/2004-July/007720.html
> or if there's another (faster) function which can be called...
No
Am 14.04.2010, 04:08 Uhr, schrieb Laurence Rowe :
> Running your test script on my small amazon EC2 instance on linux
> takes between 0.0 and 0.04 seconds (I had to remove the divide by
> total to avoid a zero division error). 0.02 is 5000/s.
Thanks for running the test.
Intrigued by this extrem
Running your test script on my small amazon EC2 instance on linux
takes between 0.0 and 0.04 seconds (I had to remove the divide by
total to avoid a zero division error). 0.02 is 5000/s.
Laurence
On 14 April 2010 00:25, Nitro wrote:
40 tps sounds low: are you pushing blob content over the
40 tps sounds low: are you pushing blob content over the wire somehow?
I have seen the ZEO storage committing transactions at least an order of
magnitude faster than that (e.g., when processing incoming newswire
feeds). I would guess that there could have been some other latencies
involved in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Nitro wrote:
> Hello Tres,
>
> thanks for your detailed answers!
>
> Am 12.04.2010, 22:42 Uhr, schrieb Tres Seaver :
>
>>> Additionally I made some quick performance tests. I committed 1kb sized
>>> objects and I can do about 40 transaction/s if one
Hello Tres,
thanks for your detailed answers!
Am 12.04.2010, 22:42 Uhr, schrieb Tres Seaver :
>> Additionally I made some quick performance tests. I committed 1kb sized
>> objects and I can do about 40 transaction/s if one object is changed per
>> transaction. For 100kb objects it's also around
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Nitro wrote:
> After lots of googling and browsing the source I can answer some of my
> questions:
>
>> - What's the difference between storing bigger objects as blobs and as
>> plain large strings?
>
> Plain large strings cannot be streamed for in
After lots of googling and browsing the source I can answer some of my
questions:
> - What's the difference between storing bigger objects as blobs and as
> plain large strings?
Plain large strings cannot be streamed for instance. Products like Zope
chop up their file uploads into 64kb chunks
22 matches
Mail list logo
