Performance issues? Remain calm and analyse.

Web companies are all about growth.
But also about speed.
It's all about getting your great idea out there, as fast as you can, which means scale and performance issues could be left 'for later' (Which is mostly a good idea at the beginning stage, when resources are sparse, and time is an issue).
Once your service scales from 100 users to 10000, you will encounter performance issues. If you have an app, response times would slow to a halt. A site, data loads slow.
In 2013 Google IO UI sessions, it was mentioned that app users tend to close their app when waiting for more than 10 seconds. While that might sound harsh, imagine tapping, waiting 10 seconds, then tapping again, waiting again - I would uninstall such an app, or never visit such a website (Unless they have something I really, really need, in that case I'll look for a competing product before uninstalling)

Clear your head. Analyse the situation.

So, what do you do?
First, don't pannick. Performance issues happen to everyone. (Kidding)
But be focused, because time is of the essence here.

An 'automatic' go to solution is upgrading your hardware - I wouldn't go there unless I was really desperate - This is hardly ever a scalable solution.

First thing you would want to do is analysis.
The base for all solutions shouldn't be by intuition alone - This could lead you to waste time on ideas that may or may not bring the solution, and waste valuable time.

- Analyse each step by time, dump it to a log file. Find the 10 most time consuming tasks, and select the easiest ones to take care of.
- Analyse DB calls - See which ones are being performed to most, or which ones take a lot of time.
- Analyse insertion rates - Maybe a queuing mechanism could solve some bottlenecks.

- Always use a perl script to 'clean' logs, do count operations on logs, and a spreadsheet to calculate and sort stuff - These are the best ways to get insights.
- Call a friend. Four eyes are always better than two.
- Call an expert. It's cheaper to pay someone for two expensive days of work and get your issues solved than lose a week of momentum.

And a final note - Don't try to rewrite your server in two days of 'no sleep'... ;)

Good luck.

The short blanket

One small rule - If you don't know all the execution paths of a code and are about to make changes, beware.

Especially if your software is made of a lot of modules speaking with each other, it's difficult to know what impact one bug fix could have over interacting modules.

If you don't have an automated test suit that covers all your execution paths, my best suggestion would be a simple file search on the method changed - This would at least give you a hint of what to check in order to make sure you'r covered.

Otherwise, this might happen:

Reading time #5!

Here we go again - The fifth instalment in the 'good reads'!

- "The software is processed by more than just the computer. It's also processed by a human sitting in front of the screen". Take the time to watch this: A Great lecture from Google IO about cognitive science and design.

- Having a great product might not just be enough. Check out this article "So you think you can go viral?", In order to find out the challenges behind the assumptions about viral products.

- With Flickr been rebuilt to a whopping 1TB of free image storage, Tumblr bought, and Hulu on sight, Yahoo's new strategy is marking the comeback of the all-mighty mega portals, spending billions of dollars basically on user acquisition. Yahoo aims high. We'll see how that evolves...

And, finally, check out my new pet project: The startup nation feed, bringing you great stories from the startup nation!



Previous reads:
#4

#3

#2

#1

Reading time #4!

- The good people at gosquared.com got some nice tips for node.js:
https://engineering.gosquared.com/10-vital-aspects-of-building-a-node-js-application

- Stats from 2012 are here. Samsung sells a lot more phones than Apple. Twice.

- If you're a geek, this guy is hilarious.

- "2013 will be all about the ecosystems, not just the hardware": Here are some trends to watch for, curtesy of techradar.

And, finally, have a happy 2013!

Reading time #2!

It's time for some more links to inspirational stuff...

This 2009 article at wired is one of my favorites. It talks about how 'good enough' easily beats 'great' in so many aspects. Whenever approaching a big design or architectural task, I tend to go back to this article a little bit. People tend to over design stuff, and try to come out with a Lamborghini (That costs like one to develop, sell and maintain), when all their customers want is a Mazda...

If you're always looking for 'the next thing' in dev technology and new stacks, you have to visit the changelog regularly. Lots of emerging technologies, useful libraries and code - All the goodies us geeks need.

For all you non-coders out there, here's a great article on starting a tech company without coding knowledge, and, this great article by @martingryner shows the other side of entrepreneurs recruiting a tech co-founder.

The new iPad paves the way for laptops, PCs and tablets with astronomical resolutions. As resolution gets higher, sites with dynamic adaptation to screen resolution need to scale differently. A simple reflow is not enough - Reflow your site, and your font size will be too small to read. Scale your site, and graphics quality degrades. This article gives some pointers about redesigning your website for retina displays.

And, finally, here's an article comparing between the two leading cross platform mobile development SDKs - Phonegap vs. Titanium. If you're considering cross platform app development, you should read this one.

Reading time!

Part of my work week is dedicated to reading and learning.
Most of my reading these days is actually UI/ GUI related stuff, as we're closing a large project at work, and are going through some final GUI iterations.

The 'Little Big Details' blog is dedicated to small but neat and significant UI features found over the web/ mobile world.

This blog, of presentation expert Jan Schultink (Idea Transplant) contains all sorts of tips and notes about presentations, presentation design etc.

Wired's webmonkey has some neat notes in their UI/ UX section.

Here's a neat book by Google about web design.

Terry Martin's great blog got some great insights about design, tech and startups.

And, finally, some management stuff:
My company's COO is a big believer in Theory Of Constraints, and has started to implement this project management methodology in our company (Time To Know).

Basically, TOC works by identifying the project chain and building blocks, trying to deal with each building block as fast as you can (Which also means using as many resources in parallel on each building block to speed up the task), and daily reviews to find the critical (Longest) chain, and speed it up.

This method, though counter intuitive sometimes, has been implemented in the project I'm leading, with wonderful result. My team (~20 UI/ GUI/ Developers/ Testers) have sped up our project delivery times, management overhead is lower, and we're actually enjoying the process...

If you're managing a medium to large size project, my suggestion would be to give it a try. Though it takes some commitment, it seems to be working well for me... As well as reduce original cost in ~30%.

A link to our TOC consultancy company would be added to this post soon.

Three nice tips for web developers.

Actually, two basic dev tips and one neat resource site.

First tip is regarding dynamic HTML. We've been encountering some rendering performance problems with huge tables, and after some investigation, here are some pointers:

• Do not use tables. They're bad for you, especially large ones, and nested tables. By the way, YUI creates lots of inner tables. You can read some more with this link, top answer has some great detailed arguments for you. I know it's a corny advice, but there are lots of frameworks out there that use tables, even gwt.
• Do not create each dom element separately - If you need to create a very large table/ chunk of html, it's better to create a huge html string and then insert it into dom for processing, rather than use the dom to create each element, and the append them. Think of it as using 1000 'native' calls from a VM rather than 1 long call. The overhead for each dom element is huge.
• Establish a maximum size for a list and browse through results. Google does that with search results, why don't you? You can cache results in javascript, or keep an index to the query and go back to the server to fetch the next n entries, but displaying one thousand items for a user is highly ineffective. 

Second tip is rather basic - Regarding server/ client processing and separation. As we're moving towards cpu consumption related billing rather than permanent hosting, we need to rethink what we do on the server and on the client side. The main principal would be having the server perform validation and data (model), and do the rest in the client:

• Your server code should not create html. It should either create status/ session/ json, but not html. This is just a waste of server cpu. It speeds up server response, and when written well, makes client experience better. It scales a whole lot better.
• You must think of your client and server modules as replaceable. This means that if you're writing a server, imagine that you need to write two completely different (Say html and iOS) clients for it.
• If you're afraid that competitors may reverse engineer your client html/ js/ css code, you can always minimize it, or get an obfuscator.

Final tip is this site. Microsoft is putting a lot of effort these days - It's great to see them as the underdog. You'll find Azure php sdk, nice html5 references, and lots of useful resources. Check it out. I'm considering Azure for a project I'm working on, the php sdk seems quite cool.

Have a great week!
y.