You wouldn’t make your website slower on purpose, would you?

Perhaps it shows a bias on my part, but I tend to assume that people want their web sites to be faster.

so I was quite surprised when I saw some code on the homepage of a major high street retailer, which deliberately slowed down visitors to the site.

This wasn’t just a rate-limiting thing. It’s a proof-of-work algorithm – you have to earn the right to visit their site.

Continue reading

Wireshark: Tools versus Weapons

Not long after I started in performance testing, I was debugging a script. It didn’t seem to like one of the requests the script
made, so I did what I would have done at home. I ran through the procedure manually, and watched in Wireshark.

I told a colleague about this, and he said “Don’t ever do that again, and don’t tell anyone that you did it”. The client I was working for at the time were very nervous about security, and would have been furious that I’d used Wireshark on their network.

Continue reading

Solve Memory Leaks by Not Solving Memory Leaks

Memory leaks have been a fact of life in programming for as long as anyone can remember. C is the mac daddy of memory leaks – any non-trivial program has a memory leak – but even in garbage collected languages you’re not safe, as there are some types of resource that you have to remember to close (OS-native objects, like files and processes).

Or at least, that’s the theory.

Continue reading

Advanced Squeryl/Play Integration

There’s a question on Stack Overflow about how best to integrate Squeryl and Play.

Since Play is an external framework, you might guess that you want to have quite tight integration, using SessionFactory.externalTransactionAdapter. However, the right answer turns out to be looser integration, using SessionFactory.concreteFactory, which means you have to use explicit inTransaction blocks.

So what’s the problem? Well, Play’s database support is deliberately minimal. It provides a connection pool, and handles evolutions for you, but otherwise it’s up to you how you use it. It won’t commit or rollback your transactions unless you ask it to, which means you’re probably best off using inTransaction blocks anyway.

Problem solved, right? Well, almost. There’s still a slight impedance mismatch between Play and Squeryl. Play uses an asynchronous event-driven model, whereas Squeryl is designed for a connection-per-thread model.

So, for example, if you have code like this:

def sendAsteroid = Action { req =>
  import org.squeryl.PrimitiveTypeMode._
  import DinosaurSchema._
  inTransaction {
    val cretaceousDinosaurs = from(dinosaurs)(d => where(d.era === "Cretaceous") select(d)).toList
    Async {
      Akka.future {
        for (dinosaur <- cretaceousDinosaurs.par) {
          dinosaur.extinct = true
          dinosaur.save
        }
        Ok("All cretaceous dinosaurs killed")
      }
    }
  }
}

Then your code won’t work the way you expect.

Continue reading