What’s the problem with RelStorage?

Last night in a desperate attempt to squeeze some performance out of a plone site that was being loaded with data marshalled from a MySQL database (a new plone-based app is replacing the old generic php-introspects-the-db frontend generator-based one).

Only about 3000 objects, bad performance, lots of CPU and RAM used, etc. And it’s Plone 4. It was also eating up disk space, I’d have to pack it multiple times during the course of the import or the Data.fs would climb to 60+ GB.

I have a sinking suspicion that the bulk of the bad performance is due to some very fancy and very hastily put together roll up screens, our virtualization environment (KVM on RHEL 5), or some other factor, but I’m not sure. Profiler tools don’t seem to work well with the zope that comes with Plone 4, and what did work (CallProfiler) didn’t work with five browser views, so when optimizing we were basically flying blind.

We’ve gotten rid of any brain.getObject() calls, prudent use of memoize, plone.app.caching… we’ve done whatever we can to make it faster, and it was better, but still no bueno.

Anyway on a whim I switched my development copy of the app to use RelStorage with MySQL on the back-end (only using mysql because it’s what we’ve already got deployed). I also added memcached into the mix. The non-scientific, contrived tests I did saw a massive increase in performance (only a slight difference between using memcached and not). Almost 4000 requests per second for the default home page, vs about 900 using a stock ZEO setup on basically the same hardware (I was inadvertently testing RelStorage on 2GB of RAM vs 4 in the initial tests). Logged in. Our expensive roll up screens showed an increase from 150 requests per second to 223, with twice as much data in play (there’s an especially slow report that pulls about 1600 objects from the catalog and provides pagination.. when I did my relstorage tests I used a script to generate 900 and then copy-and-pasted them until I got over 3k).

RAM no longer climbed to the point where the VM would swap itself to death, the site remained responsive under heavy load (importing from the MySQL db via wsapi4plone) with only one client running, the database files have barely climbed over 17GB and I forgot to tweak some innodb optimization factors before I created the RelStorage tables (granted the import isn’t done yet, about 50% of the data is left to import..).

So, I’m way happy about all this. But my question now is, why doesn’t it seem like more people are using this? It’s documented very well, it’s a little weird to set up if you’re not a RDBMS person, but it was very easy. It’s fast, it’s efficient, and doesn’t require anything from the developer. You can even build it without undo if you want to make it presumably faster (I opted to not do that, but it’s a nice option). You can scale out the DB server and memcached easily (probably not easier than ZEO + FileStorage, but still very easy). You can move up to postgres or oracle if you need more heft. You can theoretically go back to ZEO if you want (I had trouble with the conversion scripts and cron4plone, but they’re fast and would probably do the trick).

RelStorage is, like, my favourite thing ever. So what’s the downside?

Advertisements
This entry was posted in Uncategorized. Bookmark the permalink.

9 Responses to What’s the problem with RelStorage?

  1. Good to hear! I’m a big fan of RelStorage too. It’s very sane, and a nice side effect is now that you have an RDBMS, you’re not afraid to use it (via SQLAlchemy).

    I think the main reason it’s not more popular is that it’s a lot younger than ZEO. But I predict it rising in popularity for sure.

    Martin

  2. It’s really weird that you have such issues in such a small DB. I have sites that are well over 100,000 objects and hover around 60GB. Either way glad to hear you had such success – it’s been on my ticklist to try for some time now!

    • jjmojojjmojo says:

      I talked to a couple of other plone developer/systems folks in other departments at UNC and they said almost the exact same thing “I’ve heard of it, it’s on my ticklist” :)

      I’m still baffled as to why our code, and the site itself was being sluggish pre-relstorage. We’re in the midst of a roll-out so, regrettably, I didn’t have time to try to fix the profiling tools or write some new ones. At one point I had hard-wired the python profiler into my browser view where I thought the problem was, and it identified some quirks, which helped, but it didn’t identify any glaring problems in the code. It did, however, show me that my view code was being called 5 or 6 times for reasons I couldn’t pinpoint (has something to do with Dynamic Views… I have a policy product that sets up the fancy reports as the default view for certain folders)

      It sucks big time that there’s no drop-in profiling solution that’s currently working, like PTProfiler or ZopeProfiler.

      The upside of the story is that I know how to run the profiler, and that gets me 50% of the way to eventually getting something working in plone4/zope [whatever version plone 4 ships with].

      And now RelStorage is the new Way, and buys us some time, so it’s all good.

  3. encolpe says:

    One reason is that no default buildout template propose the relstorage installation.

  4. Silvio Tomatis says:

    Sorry if it’s a silly question, but did you try repoze.profile? I used it a couple of times coupled with ab and it did the job very well; also very easy to install (just plug it into your wsgi pipeline). I was using grok though, but I hear Zope 2.13 supports wsgi.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s