Jazoon 2013 – The Economies of Scaling Software

25. October, 2013

Jazoon 2013 badgeIf you’re small, scalability is not an issue. If you’re big, you can plan for it. But what if you wake up one morning and you suddenly find you’ve become the next Google?

In his talk “The Economies of Scaling Software“, Abdelmonaim Remani talks about what scaling means, how you can plan for it (even if you don’t expect it to happen) and all the nasty details that stand between you and success (slides on slideshare).

Today, the ubiquity of the Internet has blurred the lines between consumers and enterprises. They start to ask the same questions which eventually all boil down to: “How can I find what I’m looking for in a universe of haystacks?”

One day, many of us will find themselves with the need to scale because the performance of the old solution has become unbearable and all low-hanging fruit (faster CPU, more RAM) have been picked.

To solve this, you can look at the CPU (slide 16-35) or you can start to build clusters (36-45).

Or your I/O might be the bottleneck (slides 46-60). You can solve this by looking at NoSQL databases and caching.

Is the network the problem? (slides 61-75) Start with asynchronous processing, batch jobs, content delivery networks (CDN), DNS sharding or use a different protocol to connect the various parts of your system.

But how do you know what part is the bottleneck? The answer here is monitoring. (slide 77)

Note that scaling often helps with disaster recovery, you still have to plan for it – if all nodes of your cluster are in the same room, it’s still a single point of failure (slide 79)

Software isn’t everything. Don’t forget your team (slide 82)


Efficient CSS

26. May, 2011

Is “.first” faster or slower than “li.first”?

This blog post has some answers: Efficiently Rendering CSS


Another lesson in performance: NIO

29. December, 2010

Remember when I wondered how slow it is to copy data around in memory?

This time, I needed to load a 2MB file from disk and examine it for certain patterns.

The original from jazzy spell checker worked like this: It did a binary search in the file for a code. The code would be at the start of each line and be separated from the correct word by an asterisk:

    AT*wide
    AT*widow
    AT*width
    AT*wight
    AT*wit

The search algorithm would seek somewhere in the file, skip the current line, read the next one, compare the code against the one we look for. If our code was smaller, we would seek backward; if it was larger, we would seek forward. Standard binary search.

Only it didn’t work. The test took 4 seconds to load the file without finding anything. Debugging recursive algorithms isn’t as nice as looking at them …

So I considered a different approach: I would load the whole file, character by character, and remember the lines with the same code in an index. A good time to have a look at NIO, especially the grep example.

Question: If it takes 4 seconds to seek ten times in a RandomAccessFile and read about 2000 bytes from it, how long would it take to read it character by character, examine each line, build an index and then load whole chunks (say, 1KB each) from the file when a word needs to be looked up? Plus the additional work of removing the code pattern from the chunk to produce a list of words …

Answer: 0.3 seconds. That’s more than ten times faster. And I could probably optimize the code some more.

Conclusion: When it comes to performance, measurement beats superstition.

And the new code is easy to understand, and to test, too! ^_^


Firefox performance

24. November, 2010
Mozilla Firefox Icon

Image via Wikipedia

It’s 2010, Firefox is going 4.0 soon and it still has no way to tell why it’s sluggish.

Yes, it would be nice if the FF developers could make the browser so fast that it would never become sluggish in the first place. I just fear that this is simply not possible with the current design. Look at Chrome: Every tab runs in it’s own process. So what if one of them is slow? All the other still feel crisp.

On FF, if one tab takes over the machine, you’re doomed. Yes, I could disable JavaScript and every add-on individually. Why bother? Starting Chrome solves the issue in no time.

If you care, support Bug 505104: Please add a tool to gauge Addon performance.


Extremely complex queries in BIRT reports

30. September, 2010

Sometimes, SQL just isn’t enough. What do you do when you just can’t get the SQL to run in under an hour while a little piece of Java code does the same query in a few seconds? Put the result into a report table and then run the report against that table.


Sins of Commissions

18. July, 2010

If you plan to measure the performance of your employees or to improve their performance with a bonus, then you should read this: How Hard Could It Be? Sins of Commissions.


Extending Tomcat WebappLoader to Share Library jars

16. March, 2010

If you’re like me and use Tomcat and you want to bring down the size of your WAR, you’re faced with one issue: All your applications need to use the same libraries (since there is only a single common/lib for everyone). So you’re either stuck with an old version or you need to upgrade all your apps at the same time. I just can see the budget guys shake their heads.

The solution is a list of directories in your context.xml which contain specific versions of the libraries you need. This way, you can install all the versions you need and each app can pick and choose.

For the complete solution, see the original article: Extending Tomcat WebappLoader to Share Library jars

OSS for teh win! :-)


Follow

Get every new post delivered to your Inbox.

Join 334 other followers