Comments on: Making PStore reaaaally fast (and stable)

By: indibelix

indibelix — Tue, 14 Dec 2010 13:48:45 +0000

Hi, I registered on this dating site Dating Free I made several interesting meeting. However I will like to know if you made that meeting and you meet later with the person?

By: Pennysmalls

Pennysmalls — Wed, 04 Mar 2009 14:50:07 +0000

[...] We don’t use the cookie store because our sessions can get bigger than the 4k limit in certain circumstances. So we use the memcache store on the production machines, and pstore on the dev and test machines. And we can’t do that any more, which is a shame as it worked well – particularly with Hongli Lai’s improvements. [...]

By: San

San — Thu, 27 Nov 2008 10:55:26 +0000

Hi,

I am currently handling Pstore. How do i Retrieve a Specific set of data from the stored PStore details?

e.g.
id1 0011 0011 0011
id2 0000 1111 0000
id3 1111 0000 0000

This case i want to detact “id3″ and retrieve the related binary details “1111 0000 0000″

San

By: Hongli

Hongli — Fri, 28 Mar 2008 18:14:28 +0000

No, the file I/O is probably safe. But bad things may happen if two threads enter the same transaction. For example, suppose thread 1 enters a read-only transaction, and it just passed this line:

@rdonly = read_only

Then a context switch occurs. Thread 2 enters a read-write transaction and passes the same line as well, setting @rdonly to false. Thread 2 exits transaction. Context switch occurs. Thread 1, which was supposed to be executing a read-only transaction, now thinks that the transaction is read-write and writes stuff to disk. Boom.

By: mla

mla — Fri, 28 Mar 2008 18:07:17 +0000

Just for my understanding, what made the original version
not thread-safe? I see your synchronize call, I’m just not
clear on exactly what it’s serializing access to. Is the
file I/O not thread safe even when flock’d?

By: mla

mla — Fri, 28 Mar 2008 06:44:47 +0000

The patch to marshal seems to work perfectly

For pstore physical writes your version is 2x faster for me:

user system total real
std 20.240000 36.490000 56.730000 ( 58.234056)
new_canonical_marshal 13.090000 12.830000 25.920000 ( 26.656768)

That’s using the fast store strategy and read/writing the same file 50k times.

For logical writes where the data hasn’t changed, the new version is
roughly 15-20% slower:

user system total real
std 6.500000 3.160000 9.660000 ( 9.841138)
new_canonical_marshal 8.640000 3.300000 11.940000 ( 12.119400)

I did some quick profiling and I don’t see anything obvious. I think it’s the
overhead of the added method calls. I inlined most of them and got pretty
close to the standard version.

new_mla 6.810000 3.110000 9.920000 ( 10.008198)

OTOH, even with the slight slow-down we’re still talking 4k+ ops/sec
which is unlikely to be a bottleneck.

By: Hongli

Hongli — Thu, 27 Mar 2008 21:01:31 +0000

Yeah, weird. I sent the email hours ago but I still don’t see it.

http://pastebin.com/m12689e12
Patch is against 1.8.6.

By: mla

mla — Thu, 27 Mar 2008 20:54:55 +0000

Fantastic. I don’t see the marshal patch in the archives yet. Would you post it to pastebin too?

By: Hongli

Hongli — Thu, 27 Mar 2008 18:40:49 +0000

I’ve modified Marshal.dump and added a ‘canonical’ option. A patch has been sent to ruby-core. I’ve also restored the MD5 checking code. It makes use of the ‘canonical’ option whenever possible. Code is here: http://pastebin.com/mb293607
Could you benchmark it?

(If you don’t want to apply the patch, then you can simulate the ‘canonical’ behavior by calling rehash() on all your Hash elements, including the @table instance variable in PStore.)

By: mla

mla — Thu, 27 Mar 2008 01:33:15 +0000

By the way, what benchmark script did you use to generate the results seen in your pstore.png graph?

Here is the patch to add partitioning:
http://mla.homeunix.com/tmp/pstore_hashed_directories.patch.txt

I think this is the script I used to test it. See the database_manager param which
I toggled for successive runs:

http://mla.homeunix.com/tmp/pstore-bench.rb

That was one of my first forays into Ruby so be gentle ;/

I think you should take another look at the md5 logic. Under Rails, the session is always being opened for R/W, correct?
Which means the session will always be written even if it hasn’t changed. But in most environments, the read/write ratio is often 10:1 or more.

In a quick benchmark of your new version, it appears to be 2x as slow when the session has not changed, suggesting that the write is still substantially more expensive than the md5 check.