ananasblau.com

I once worked in a company where the default environment.rb deactivated the log file, and I guess it was just because the were bored by long lines of output they didn’t want to read. The sweet advantages of having a DB admin who checks your db queries before they go live.

general facts and hints

First of all: The less lines per request the better. If you see lines that basically repeat, maybe only some id being different, then you have a problem and should think about eager loading, counter caches and other optimizations. Partial caching for sidebar elements might also be a possibility.

A few example log lines

In the example posted at railsforum.com there are four database queries, one on topics, three on posts (of which one is most likely a find_by_sql or count_by_sql ?). We only have to look at the Load lines, the Cache lines are totally ok unless they come in dozens or hunderts. It takes ActiveRecord some time to generate a final sql query, so try to cache common objects e.g. in an instance variable (See railscast #1) and reduce the Cache lines.

1
2

Post Load (0.000185)   SELECT * FROM `posts` WHERE (topic_id = 3338) ORDER BY posts.id DESC LIMIT 1
Post Load (0.000132)   SELECT * FROM `posts` WHERE (`posts`.topic_id = 3338) ORDER BY posts.id DESC LIMIT

1
2

SQL (0.000180)   SELECT count(*) AS count_all FROM `posts` WHERE (`posts`.topic_id = 3338)

more examples??? Please send them in.

Further logfile analysis

There are a few tools but I use only two: The RailsLogVisualizer to see which actions are called often in production mode. And I look at what the longest taking requests are. grep and sort nr are your friend, the logfile is your enemy ;) But at the end, the trick is just understanding the log, sorry about, no way around.

Thanks to a poster on railsforum.com for the idea to this blogpost.

This is article is about improving javascript slideshows on both client and server side. I will discuss a few problems with slideshows of which we fixed some at Lomo’s beta website. The problems are independent from what framework you use server-side or if your javascript library is YUI, prototype, jQuery or MooTools. If you have only very small slideshows then my tipps might be overkill for your app.

Problem 1: Not everyone views the slideshow

Many slideshows are never being started, not to mention all the bots that don’t do JS anyways. So, this is a great chance to avoid a lot of database queries and HTML output. So, use AJAX calls to load the elements of your slideshow when the user requests them. In most cases you won’t need the actual ids or your items, just increase the offset in your sql queries.

Problem 2: Delays

So, you’re using AJAX to request the images or whatever, and after deploying you realize that either some content is skipped. The reason for interleaves are bad asynchronous requests, they must be synchronous unless you update the page through evaluating the request’s response.

Problem 3: Too many requests

Still, it takes a bit longer until the content displays, an example for this is flickr’s slideshow, it always feels a bit slow to me. Also, you receive one request for every item the users looks at. To improve both, your server performance and user experience you must load more than one element.

E.g. you show the first item right away, the user starts the slideshow and you load the next ten items. When the user reaches the seventh or eight item you could start loading the next ten items asynchronous for a even more seamless user experience. Of course you need some kind of caching on the user side.

Summary

• Use AJAX requests to retrieve data only when it’s needed
• Do synchronous requests to prevent interleaves
• Cache content on user-side (double linked lists or simple arrays)
• Load more than one item
• Load them early (this time asynchronous!)

Oh, if you need such a thing for PHP, here’s one: http://billwscott.com/carousel/