stöcklblog

  • Random
  • Archive
  • RSS
  • Got questions?

Ever thought about caching, you RoR guys?

I just read this blog post by William Hertling, a science fiction author and web developer:

http://www.williamhertling.com/2012/02/scaling-web-app-1000x-in-3-days.html

Well, they got the case solved and their visitors served - still I’m left with some questions.

Before starting the “flame war” I must say that we’re also using New Relic in my company (only the free plan currently) and I really like it, especially the pro features which I know from the “trial” month.

Now for my “comments”:

Slow query log, anyone? Some commenter already mentioned it, if you have a MySQL bound app and find the DB servers to be your bottleneck that’s for sure the first place to look at!

Caching, anyone? William writes:

using memcache or other mechanisms to hit only memory instead of database: this too would have been extensive code changes. Given the short timeframe, it felt too risky

Excuse me, but building a DB heavy (web) application without caching is imho not very smart, to be extremely polite! This seems to be a RoR paradigm (here’s the “flame war” - I’m a PHP guy ;-). Especially if you’re on MySQL where load balancing the DB itself is really not trivial you need to cache as much as makes sense and this needs to be implemented from the start!

Sure, it’s some coding overhead and the flushing can get tricky, depending on your access patterns. That’s why you need to have code in your library that you can mostly use out of the box and I’m sure that’s not much harder with RoR than with Zend Framework!

That way, having a good caching solution, you can always just throw web application servers to be able to handle more load without a DB load that increases into some bottleneck!

My current suggestion is to cache your complex objects in a MongoDB backed cache that uses replication, sharding and whatnot. I have mentioned this before -> atomic updates inside your complex objects is what makes this rock!

Have fun, Anton

    • #caching
    • #ror
    • #New Relic
    • #mysql
    • #db
    • #php
    • #Zend Framework
    • #MongoDB
  • 3 months ago
  • Comments
  • Permalink
  • Share
    Tweet

The light year - an often misunderstood unit of length

Dear advertisers / media / others: A light year is a unit of length (a quite big one) and nothing else! Go ask Wikipedia if you don’t belive me: http://en.wikipedia.org/wiki/Light_year

Now, with that in mind … sentences containing stuff like that are pure bullshit:

  • … surfing light years faster … (no, it’s not a speed unit)
  • … takes light years … (no, it’s not a time unit)

Please stop misusing our most impressive unit of lenght for the sake of Einstein!

:-)

    • #light year
  • 4 months ago
  • 2
  • Comments
  • Permalink
  • Share
    Tweet

Howto fix: Tomboy sync fails with Ubuntu One

I have two computers syncing tomboy with my Ubuntu One account on Ubuntu 11.10 (Oneiric). One one computer it worked without problems, but on the other the sync failed with this error (found in “~/..config/tomboy/tomboy.log”):

Synchronization failed with the following exception: A note with this title already exists: New Note Template

in german:

Synchronization failed with the following exception: A note with this title already exists: Neue Notizbuchvorlage

I couldn’t find a note in tomboy with that name because it is a template, which does not show up as a note. After some searching I found this: Tomboy fails to synchronize its notes with ubuntu one (scroll down to the tip from Martijn).

It did not work the way Martijn suggested, but similar:

  • go to tomboy settings, open the new note template and change the title
  • start the sync, it should work now
  • open the new note template again and delete it
  • sync again

That way you should only have one new note template on all your computers and a working sync!

Enjoy!

    • #tomboy
    • #ubuntu
    • #ubuntu one
    • #sync
    • #fail
  • 4 months ago
  • 6
  • Comments
  • Permalink
  • Share
    Tweet

How to make Zend Studio start from Ubuntu Unity launcher

If you “install” Zend Studio on Linux it’s nothing else than extracting the .tgz archive. When you start it and pin it to the launcher there are some issues:

  • the Zend Studio icon is not used
  • when you try to start it from the launcher it does not start

The solution is quite simple.

Create a launcher icon with some editor:

~/.local/share/applications/zend-studio.desktop

Add the following content to it:

[Desktop Entry]
Name=Zend Studio
Exec=/path/to/ZendStudio/ZendStudio
Icon=/path/to/ZendStudio/icon.xpm
Terminal=false
Type=Application
StartupNotify=true

Make the file executable:

chmod +x ~/.local/share/applications/zend-studio.desktop

Then, navigate to that location via Nautilus (press CTRL+H to |un|hide files), run the “Zend Studio” icon and pin it to the launcher.

    • #zend studio
    • #ubuntu
    • #unity
    • #launcher
    • #integration
  • 4 months ago
  • 8
  • Comments
  • Permalink
  • Share
    Tweet

My MongoDB cache backend adapter for Zend Framework is on Gibhub

I just put my MongoDB cache backend adapter (for Zend Framework 1.11, not for ZF2!) on Github. It’s a fork from Stunti (Olivier Bregeras) with some fixes and improvements, so Oliver did the hard work, not me!

You can find it here: Zend_Cache_Backend_Mongo

Details about Zend_Cache can be found here: Zend_Cache

MongoDB is very easy to install on Debian / Ubuntu, it’s not more than a

apt-get install mongodb-server

to get the server running, listening (only) to localhost. DBs in MongoDB are created when they are requested, so you don’t need to do anything apart from getting my cache backend running. :-)

I did some performance tests with it and compared to Memcache, here are my numbers:

Memcache

inserted 1000 items in 201ms (items/second: 4986)
loaded 50000 random items in 5455ms (items/second: 9165)
1000 cache miss requests 109ms (items/second: 9153)
Memory peak usage: 6029312 Byte (5.75 MB)

MongoDB

inserted 1000 items in 339ms (items/second: 2946)
loaded 50000 random items in 5747ms (items/second: 8700)
1000 cache miss requests 115ms (items/second: 8660)
Memory peak usage: 6029312 Byte (5.75 MB)

So MongoDB is a bit slower in writes and has almost the same read performance.

But the big advantage is that MongoDB supports tags which Memcache doesn’t, so you can use the MongoDB backend adapter standalone (no two levels cache) with the full feature set (also the data is persistent in MongoDB) and almost the performace of Memcache. You can also use replication or even sharding on MongoDB, but you need to set this up for yourself.

Enjoy!

P.S.: Once I’ll find the time I’ll describe how MongoDB can do even better as a caching layer that caches your data as complex objects (including arrays) that supports atomic updates (even increments) without the need to read the data first.

    • #Zend Framework
    • #Zend_Cache
    • #backend
    • #MongoDB
    • #adapter
    • #memcache
  • 5 months ago
  • 29
  • Comments
  • Permalink
  • Share
    Tweet
← Newer • Older →
Page 1 of 7
Avatar

I'm a web developer since about 1998. Generally I work with Linux like operating systems, code with PHP, do stuff the LAMP way. Currently I work as a freelancer plus have a "Start-Up" called Pixel Talents. I'm sort of "specialised" on Zend Framework. Also I'm married and finally a proud dad of a lovely girl. :-)


Social Me

  • @TonyBologni on Twitter
  • Facebook Profile
  • Linkedin Profile

Twitter

loading tweets…

I Dig These Posts

See more →
  • RSS
  • Random
  • Archive
  • Got questions?
  • Mobile

copyright by Anton Stöckl. Effector Theme by Carlo Franco.

Powered by Tumblr