Wrath of Khan and failure

SPOILERS AHEAD: I will comment a couple of things about Star Trek Into Darkness, so, if you haven’t seen it, and don’t want to know some plot details, you may not want to read this. Just watch the movie and come back, I’ll be here waiting ūüėČ

Oh, there were plenty about Star Trek II: The Wrath of Khan (and a little of Space Seed), but being a movie from 30 years ago, I doubt they can be considering spoilers.

so 80s
so 80s

Star Trek II: The Wrath of Khan is, no doubt, a fan favourite. It has a great combination of a powerful story, iconic moments, connection with the TV series roots, and that extra Shakespearean touch that keeps everything together. But I want to focus in a particular aspect, one of the stronger themes than runs through the movie.

And that is to grow old. The fact that in particular (here Admiral) Kirk is not young any more is presented through the whole movie. He becomes an unexpected father. He needs to use reading glasses.

But, over all, he has to face the consequences of his previous actions. Especially failed ones.

Kirk starts the movie as that invincible fleet captain that has faced all possible risks and dangers (“Risk… risk is our business! That’s what this starship is all about…”) and has been triumphant on each and every occasion. Getting as far as cheating on Kobayashi Maru (a training mission designed to present failure to cadets) because, well, he simply don’t believe in non-win situations. During The Original Series, basically every single opportunity to take the bold approach to fix a problem is taken, with amazing success.

But, just as the movie starts, we discover that there has been something unexpected during this time. Khan and his crew were left at the end of Space Seed on a harsh planet, basically so they can get a challenge worth of genetically engineered supermen. At the same time, the rest of the universe won’t have to worry about their conquest aspirations. But there was a mistake. That challenge has mutated into a nightmare, even for men like Khan. Enterprise crew (and Starfleet, for what matters) just forgot about the issue, moving to the next exciting adventure the following week. But the truth is that it has been a disaster. Kirk failed without noticing it.

Ok, so Kirk goes to fix the problem and saving the day. He is even able to use some tricks and cheat Khan a couple of times, giving the impression that he is defeated, but managing to save the day at the eleventh hour. As usual, on the other hand.

I have been -- and always will be                             -- your friend... Live. Long. And.                             Prosper.
I have been — and always will be — your friend…

But, then the final moment arrives. Kirk truly faces a real non-win situation. Spock sacrifices himself to save the full ship, in a move that Kirk couldn’t anticipate. And here is the genius on the script. Spock dies. He truly does! There are no tricks, no last minute saving, no technobabble that reverts death. Spock is dead, he is no more, has ceased to be, expired and gone to meet his maker. For real. For the next 2 years (until the next Star Trek movie) Spock was totally dead. And this is extremely powerful from the point of view of drama. It is not common at all for a big budget movie, and it was a big bold move for Star Trek.

Because Kirk faces the moment he has feared for his whole life. The moment of failure. Yes, sure, it’s not a total failure, the ship has been saved. But he has been able during his whole career to end every adventure making a comment with Spock and McCoy at the bridge without a scratch. Death is for Red Shirts and aliens, not for him or close friends.

And that’s the main point of it. Failure really sucks. It hurts a lot. That’s why no one wants to fail. No matter how many times we say “failing is the first step in succeeding“, or how we repeat the mantra of “fail often, fail early“. Fail small sucks less, but still sucks. But it is unavoidable. Kirk was able to deal with it because, well, he is a fiction character. But in our lives, the truth is that we fail constantly. And the way of dealing with it is not denying that fact, or cheat our own Kobayashi Maru, living in a “I don’t believe in non-win situations” bubble. The way of doing it is trying to make each failure the seed of a new success, to learn from our errors, to keep us motivated to better ourselves. Even if it hurts every single time.

That’s one of the main reasons why Star Trek Into Darkness didn’t really move me inside. While there are some superficial similarities/homages, the character of John Harrison does not have any particular meaning for Kirk or Spock. He does not represent any personal failure for them or haunt from the past. And the end is yet-another-protagonist-almost-die-to-be-saved-by-a-gimmick, lacking the deep meaning of The Wrath of Khan.

Python Wizard

Elton+John+Pinball+WizardEver since I was a young boy,
I typed on keyboards
From bash commands to Java
I must have code them all
but I ain’t seen nothing like him
In any Hackathon
That nice, nerd and shy kid
Sure codes great Python!

He stands like a statue,
Becomes part of the machine.
Lots of comprehensions
always writing clean
right code indentation
dicts used the most
That nice, nerd and shy kid
Sure codes great Python!

He’s a coding wizard
There has to be a twist.
A coding wizard,
S’got such a supple wrist.

How do you think he does it?
I don’t know!
What makes him so good?

ain’t got no distractions
semicolons or brackets
Nice packaged modules
produced everyday
Functional programing
when it fits the best
That nice, nerd and shy kid
Sure codes great Python!

I thought I was
The system admin king.
But I just handed
My hacker crown to him.

Even on my favorite system
He can beat my best.
Opens the text editor
And he just does the rest
He’s got crazy vi fingers
no IDE at all
That nice, nerd and shy kid
Sure codes great Python!

Requests per second. A server load reference

As there seems to be a lot of misconceptions about what Big Data, there are also not really a good baseline to know “how much is high load”, specially from the point of view of people with not that much experience in servers. If you have some experience dealing with servers, you will probably know all this.¬†So, just for the sake of convenience, I am going to do some back-of-the-envelope calculations to try to set a few numbers and explain how to calculate how many requests per second a server can hold.

We are going to use RPS (requests per second) as the metric. This measures the throughput, which is typically the most important measure. There are other parameters that can be interesting (latency) depending on the application, but in a typical application, throughput is the main metric.

Those requests can be pure HTTP requests (getting a URL from a web server), or can be other kind of server requests. Database queries, fetch the mail, bank transactions, etc. The principles are the same.

I/O bound or CPU bound

There are two type of requests, I/O bound and CPU bound.

Everything you do or learn will be imprinted on this disc. This will limit the number of requests you can keep open
Everything you do or learn will be imprinted on this disc. This will limit the number of requests you can keep open

Typically, requests are limited by I/O. That means that it fetches the info from a database, or reads a file, or gets the info from network. CPU is doing nothing most of the time. Due the wonders of the Operative System, you can create multiple workers that will keep doing requests while other workers wait. In this case, the server is limited by the amount or workers it has running. That means RAM memory. More memory, more workers.[1]

In memory bound systems, getting the number of RPS is making the following calculation:

RPS = (memory / worker memory)  * (1 / Task time)

For example:

Total RAM Worker memory Task time RPS
16Gb 40Mb 100ms 4,000
16Gb 40Mb 50ms 8,000
16Gb 400Mb 100ms 400
16Gb 400Mb 50ms 800
Crunch those requests!
Crunch those requests!

Some other requests, like image processing or doing calculations, are CPU bound. That means that the limiting factor in the amount of CPU power the machine has. Having a lot of workers does not help, as only one can work at the same time per core.  Two cores means two workers can run at the same time. The limit here is CPU power and number of cores. More cores, more workers.

In CPU bound systems, getting the number of RPS is making the following calculation:

RPS = Num. cores * (1 /Task time)

For example:

Num. cores Task time RPS
4 10ms 400
4 100ms 40
16 10ms 1,600
16 100ms 160

Of course, those are ideal numbers. Servers need time and memory to run other processes, not only workers.  And, of course, they can be errors. But there are good numbers to check and keep in mind.

Calculating the load of a system

If we don’t know the load a system is going to face, we’ll have to make an educated guess. The most important number is the sustained peak. That means the maximum number of requests that are going to arrive at any second during a sustained period of time. That’s the breaking point of the server.

That can depend a lot on the service, but typically services follow a pattern with ups and downs. During the night the load decreases, and during day it increases up to certain point, stays there, and then goes down again. Assuming that we don’t have any idea how the load is going to be, just assume that all the expected requests in a day are going to be done in 4 hours. Unless load is very very spiky, it’ll probably be a safe bet.

For example,1 million requests means 70 RPS. 100 million requests mean 7,000 RPS. A regular server can process a lot of requests during a whole day.

That’s assuming that the load can be calculated in number of requests. Other times is better to try to estimate the number of requests a user will generate, and then move from the number of users. E.g. A user will make 5 requests in a session. With 1 Million users in 4 hours, that means around 350 RPS at peak. If the same users make 50 requests per sessions, that’s 3,500 RPS at peak.


A typical load for a server

This two numbers should only be user per reference, but, in my experience, I found out that are numbers good to have on my head. This is just to get an idea, and everything should be measured. But just as rule of thumb.

1,000 RPS is not difficult to achieve on a normal server for a regular service.

2,000 RPS is a decent amount of load for a normal server for a regular service.

More than 2K either need big servers, lightweight services, not-obvious optimisations, etc (or it means you’re awesome!). Less than 1K seems low for a server doing typical work (this means a request that is simple and not doing a lot of work) these days.

Again, this are just my personal “measures”, that depends on a lot of factors, but are useful to keep in mind when checking if there’s a problem or the servers can be pushed a little more.

1 – Small detail, async systems work a little different than this, so they can be faster in a purely I/O bound system. That’s one of the reasons why new async frameworks seems to get traction. They are really good for I/O bound operations. And most of the operations these days are I/O bound.

Make beautiful Python code (talk at PyCon IE ’13)

Another year, another amazing PyCon. I guess I repeat myself, but I keep being impressed about the quality of the talks and the friendly, vibrant atmosphere. It is always a pleasure to spend some time with people interested in code and technology… There was also an increase in the number attendees, and quite a lot students. I said that on Twitter, but Python Ireland, you guys rock.

Of all the talks I attend to, I’d like to comment two that were especially interesting. The first was one of the keynotes, PRISM-as-a-Service: Not Subject to American Law, by Lynn Root. All this think is pretty scary when you think about it. Definitively worth a read. The other one was The Clean Architecture in Python, by Brandon Rhodes, about ways of designing code and make them data-centric.

I also gave a talk, and other than a problem with the project that made me rush a little, I think it went good. Just in case you’re interested, here are the slides. Here is also the PDF version with notes.

Oh, and another thing. there are launching the pyLadies Dublin group this wednesday 15th October, so if you’re interested, show up.


UPDATE: Added slides for Brandon Rhodes talk