On Fri, Dec 4, 2009 at 3:41 PM, Shane Hathaway <sh...@hathawaymix.org> wrote:
> Jim Fulton wrote:
>> On Fri, Dec 4, 2009 at 3:07 PM, Shane Hathaway <sh...@hathawaymix.org>
>> I won't take the time now to analyze the new test, although I will ask
>> a couple of questions:
>> First, in your results, you show cold, warm and hot numbers. Do these
>> correspond to my cold, hot and steamin numbers?
> zodbshootout still produces steamin numbers, but I didn't include them on
> the web page because they would dominate the chart. I added the "warm" test
> after your speedtest modifications. My cold, hot, and steamin numbers
> correspond with your cold, hot, and steamin numbers. The steamin numbers are
> about the same for RelStorage and ZEO. See this page for a chart that
> includes steamin numbers:
I find this a bit confusing. For the warm numbers, It looks like ZEO didn't
utilize a persistent cache, which explains why the ZEO numbers are the
same for hot and cold. Is that right?
What poll interval are you using for relstorage in the tests?
Assuming an application gets reasonable cache hit rates, I don't see any
meaningful difference between ZEO and relstorage in these numbers.
>> Second, does the test still write and then read roughly the same
>> amount of data as before?
> That is a command line option. The chart on the web page shows reading and
> writing 1000 small persistent objects per transaction,
Which is why I consider this benchmark largely moot. The database is
to fit in the servers disk cache. Even the slowest access times are
on the order of .5
milliseconds. Disk accesses are typically measured in 10s of
milliseconds. With magnetic
disks, for databases substantially larger than the server's ram, the
of loading objects will be noise compared to the disk access.
The only real difference between relstorage and ZEO is in cold numbers
in ram. This measures the raw low-level server network performance.
MySQL and Postgress
servers are obviously faster than ZEO at this level, but networking is
a small component of
the overall work load.
For more information about ZODB, see the ZODB Wiki:
ZODB-Dev mailing list - ZODB-Dev@zope.org