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.

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.

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!

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.

Oracle Identity Management - Governance, Risk and Compliance Architecture

I'll have to admit that my primary reason for reading this book was not to kindle my knowledge of Oracle products, but rather get a picure of the IAM world. That proved a bit difficult, because it was not clear how the O-IAM model connected to the non-vendor-specific side of things. Not very suprising, but the foreword do describe the book as definitive guide. I'd recon the book would have been better with a "middle tier" of conceptual IAM.

Java EE6 with GlassFish 3 Application Server review

Just got through this interesting book. It provides a quite nice perspective on a default set of tools for web application development in Java. Obviously focused on config and deployment of GF, the book also covers JSP, JSF, taglibs, messaging, security, ejb, cdi and web services. Althought all very familiar topics, it's nice to have a collection to point to for referencing these proven technologies. It should be pointed out that there are no comprehensive code appendixes in the book. So it's not bloated with code, but on the other hand it's not entirely clear how web services and messaging fit into the big picture.

The primary audience of this book is web developers wanting to move a bit towards the server side, learning how to integrate scalable data providers into their applications. I'll be recommending this book to a couple of web developers.

Knowledge sharing days

Today is of our knowledge sharing days in Computas. I haven't reflected on the actual value of such days before, except the practical value of giving and attending lectures and talks.

But today I discovered that there is actually more to it than just the knowledge sharing. Being away from your current project, you get to reflect on things that are not immediatly useful to your work, but rather expands your horizon on other topics.

Such a day differs from a day at a conference in that you feel free from an obligation to learn directly useful stuff. So, with this new state of mind I got to attend .NET sessions, project management sessions and sales sessions.

And guess what - I actually learned a lot more than I expected! There are so much knowledge around that will come in handy at some point, which you never can afford spending time on learning in a normal day. But when disconnected from everyday obligations, the mind seeks other kinds of producing useful thoughts, and so attending sessions from other fields than your primary becomes so much more efficient!

So, today I'm truly appreciating this opportunity to learn something that belongs to another everyday set of mind. +1 for Computas :)