fredag 29. april 2011

Innbakte pølser på grillen


En enkel og knallgod fredagsrett:
- 1 pk pølser
- 1 klump fin deig

Lag en lang, flat stripe deig, og surr den rundt pølsa. Pensle med litt smør. Grill på lav varme i ~5 minutter. Enklere blir det ikke :)

fredag 8. april 2011

Firespice


Røykespon bruker man vanligvis til å røyke fisk og denslags, men Weber har en type litt større trebiter som funker bra i grillen. Firespice er små biter av treverk av feks mesquite, hickory eller epletre som kan puttes i grillen for å lage litt ekstra røyk.

Det funker flott til biff, og også pizza som jeg skrev om i forrige post. Det er lurt å legge flisene i vann et døgn i forveien, så de brenner mindre og ryker mer.

torsdag 7. april 2011

3xP: Predicting production performance pt. 2

In my previous post, I ranted on about testing environments, and how everything would look like if us tech nerds were to run a project. Well .. everything would be tested and running smoothly, but the users might not enjoy the command line interface.

Anyway, what to do when you're unable to reproduce performance issues that appear in production, disregarding excuses and previous assumptions ?

There are a number of non-intrusive metrics that is - or should be - available from your production environment. These should be used to monitor the application, and warn whenever something is about to come out of control.

But since we're already working on this - I guess the metrics failed, or someone did ignore the alerts and flags and whistles. Here's my short recipe for finding performance bottle necks:

1) Draw a diagram of the application stack
2) Map out the different diagnostics available from each layer
3) Figure out if each layer itself believes it is healthy
4) Let each layer figure if the layer below is healthy
5) Start fixing issues from the bottom. With each change, re-assert that the layers below still are hearty.

A typical example would be a long-running sql statement. It would be visible in database monitoring tools, and easily fixed either in the database or by altering the statement. Good.

But it's still a bottle neck. Why? Looking good at the data layer, there may still be issues with transporting the query results to the application server. So, next you look at the database driver, and see that there are a lot of result pagination. You query yielding 20 000 rows gets paginated into 1000 chucks of 20 rows.

So you fix the prefetch size, and now things run a bit smoother. But there's still some issues, because instantiating all of these results can take a while.

So you may be altering the data transfer model to be be more precise of which objects to fetch. But in doing so, you complicate the query again, yielding longer execution time ..

And so on you weave a path upwards to the application level, possibly introducing and resolving several issues as you go. This process is orders of magnitude simpler if you are able to simulate the results instead of actually deploying small fixes to production. In addition, you may unknowingly touch upon stuff that break other performance metrics. So again - monitoring of the entire stack is crucial.

Finally, when you reach a conclusion and have solved all of the current issues - ensure that your current footprint or benchmark is monitored for changes. Future maintenance and development will surely introduce new issues. Get at them early instead of letting them grow and interweave with each other. Then your next job won't be untying complicated knots of system behavior.

lørdag 2. april 2011

Grill-pizza på steinplate




Av og til oppdager man ting som er så fantastiske at man lurer på hvordan man ikke har oppdaget dem før. Igår hadde jeg en slik opplevelse, takket være en gammel steinplate som fikk plass inni grillen.


Pizzabunnen som ellers blir litt kjedelig i ovenen ble helt eksepsjonell i grillen. Og det hele var enklere enn svint: fyr opp grillen til ca 250 grader, forvarm steinplaten, kjevle ut deigen og stek den i 2 minutter på hver side. Den siste stekingen med litt ost og fyll på, feks creme fraiche, skinke, ananas, basilikum og mozarella. Genialt!

fredag 1. april 2011

3xP: Predicting production performance pt. 1

I've recently worked a bit on performance tuning several applications that have been in production for several years. They range from 70 users to 3000 users, but have one thing in common: None of them have a performance management scheme.

Of course, it comes down to a question of cost. To be able to make, say, 99% correct predictions of how a system will perform, you need to run a bunch of tests in a sensible environment. There are two cost drivers: creating and managing the tests, and acquiring and maintaining the environment.

Creating load tests for a huge custom made application in three weeks is not possible. There are so many tweaks and processes and different behavior, that you'd need a load of domain experts just to tell you about all the things you can do. If the load tests were written in parallel with development, it would at least be possible to get somewhat complete coverage. But that's a huge overhead that cannot be added to the vendor budget. And the customer didn't specify inferior performance, so why should they take the cost?

I guess the lesson learned is that "good" performance may be governed by a tedious technical project management. Great performance has to be a concern even wider than the project scope, also including pre- and post-processes.

The second cost driver - environment - requires the first driver to be implemented. No need for realistic testing if you don't have a clue of what to test. But if you do - having a faulty or incorrectly scaled environment gives you either a number of falsely positive performance issues to solve, or a number of excuses for bad testing results. None of which is a good thing.

So, if you got your tests - do go the extra mile and ensure that the environment in which they are running is enabling you to do realistic testing and get correct predictions.