Joe Dog Software

Your JoeDog overhauled siege’s cookie handling. It was re-written in an object-oriented manner which makes maintenance and debugging simpler. That’s good for me, Your JoeDog, but what about you, Your Siege User?

Siege 3.1.4 will have two noticeable changes. Individual configuration files have moved and cookies will now persist between runs. In order to be tidy, we created $HOME/.siege The resource file was moved from $HOME/.siegerc to $HOME/.siege/siege.conf A new file will also be added to that directory. Your cookies will be stored in $HOME/.siege/cookies.txt At some point we’ll probably move the urls.txt file there as well.

We’d appreciate if you could test it. You can find it here: Siege-3.1.4b2

Siege is available through most major Linux distributors. That makes us feel like important uppity-ups. It also cuts down on the time we spend walking n00bs through the compile process. Unfortunately, it comes with a downside. Because most people use distributed versions, it takes a while for news of buggie bugs to reach us.

We applied a patch to version 3.1.1 that introduced one such bug. Versions 3.1.1 and 3.1.2 incorrectly handle HTTP POST. Instead of following protocol, those versions make this request:

POST /test POST ha=1&ho=2 HTTP/1.0

Well, that’s embarrassing! Version 3.1.3 fixes that mess. Your JoeDog regrets the SNAFU.

This latest version does another thing! It may look like a bug, but it’s a feature. Beginning with siege-3.1.3 you will no longer be able to run siege with more than 1000 users without changing your configuration. This allows us to Dog-splain in the rc file why you’re probably doing something foolish.

The siegerc file now contains a limit directive which caps the number of users at 1000 by default. Frankly, that’s probably still too high. If the limit directive is not present in that file, then siege defaults to a hardcoded limit. If you want to run siege with more than 1000 users, you’ll have to set that ceiling in the rc file yourself:

limit = 1001

Please understand, if you jack that up and make a mess, we’re not going to be very sympathetic.

[SIEGE: 3.1.3]

Your JoeDog plans to put the brakes on you people.

The number one we email message we receive goes something like this: “When we hit the server with 60 billion users we get socket timeouts. How do we correct that?” Short answer: configure your web server with a pool of 60 billion threads.

If you run more siege users than you have web handlers, requests start to queue up and sockets start to timeout. Out of the box, apache has a pool of 256 handlers. So if you run siege with 1024 users, 768 of them are waiting for a thread to handle their request.

So this is where the brakes come in. Your JoeDog plans to add a 255 thread limit in the siegerc file. If you configure more users than that, it will warn you and reduce the pool to 255. You can override the limit inside the file but in the comments you’ll find this lecture splaining why you shouldn’t do that without configuring your site for high capacity.

[drops mic]

If you’re the kind of person who likes to close a bar on a Tuesday night, then good news for you! There are discrepancies between the amount of time it takes us to round the sun and the clocks we use to measure it. In order to correct those discrepancies, we add a second every once-in-a-while. That once-in-a-while is now! We add a second at midnight.

If this was a normal night, the sequence to midnight would look like this:

  2015-06-30 23.59.57
  2015-06-30 23.59.58
  2015-06-30 23.59.59
  2015-07-01 00.00.00
  2015-07-01 00.00.01

But this ain’t no normal night, mister. Tonight we add an additional second. That sequence looks like this:

  2015-06-30 23.59.57
  2015-06-30 23.59.58
  2015-06-30 23.59.59
  2015-06-30 23.59.60 <-- leap second
  2015-07-01 00.00.00
  2015-07-01 00.00.01

So if closing time arrives at Midnight, you can say to the bartender, “Not so fast, Jeeves! I’ve got another second!”

But let’s say — and why the hell not? — that instead of drinking beer, you like testing servers into the wee hours of the morning. What is siege going to do at 23:59:60? To be honest, I have no idea. Chances are your server won’t leap until its next NTP update. All transactions that occur during the adjustment will probably be skewed a second too long. (It might be a good idea to run the update manually)

NOTE: So how do you sync your Linux laptop with one of the government’s atomic clocks? Just use the time server at the National Institute of Standards. You can do that with the ntpdate command like this:

Bully # ntpdate time.nist.gov 
30 Jun 17:34:36 ntpdate[3977]: adjust time server 128.138.141.172 offset -0.026286 sec

With little fanfare and positively no hoopla, Your JoeDog released siege-3.1.0 to an unsuspecting world. This release is better able to handle concurrencies greater than 1024 — please don’t use concurrencies greater than 256 unless you know what you’re doing. Siege is able to accomplish this feat through a combination of select on its first 1024 socket descriptors and poll on each one after that. Again, please don’t use concurrencies greater than 256 unless you know what you’re doing.

Hat tips to Abhishek Bhuyan, cheshirecatalyst, Teoh Han Hui, scooby, webus and Dave Fink for input and testing leading up to this release. We still have more work to do this area but we’re in a better place.

Hey ho — that’s not all! Three-one-oh comes with a new feature. We applied a patch from Eric Abbott which provides improved delay granularity. You are no longer confined to the rigid world of integers, one, two, three, four, etc. You can now use decimal precision like this: –delay=0.05 or this: -d 1.5  But here’s the thing about this feature: It’s kind of embarrassing that we’re adding it in the sixteenth year of the project but you guys never asked for it!

One more thing: please don’t use concurrencies greater than 256 unless you know what you’re doing. If you lay siege to apache with an out of-the-box config, it will not be able to handle the load and all you’ll do is make a mess.

[JoeDog: http://download.joedog.org/siege/siege-3.1.0.tar.gz]

If you’re following the 3.1.0 thread, then you know siege clients are essentially capped by your operating system’s FD_SETSIZE. For most of us, that means 1024. You can increase its capacity by recompiling your kernel, an operation Your JoeDog hasn’t attempted in over 20 years. In all likelihood, you don’t feel like doing that either.

To overcome this limit, we switched from select to poll in siege-3.1.0 rc2. If your OS supported poll, then you’d use that mechanism to test socket readiness. So while that increased our capacity, it wrecked our performance. Why? It’s still not clear why but that’s the feedback we received from several testers. It also matches our own experience.

Which brings us to release candidate 3. We now use both mechanisms. If a socket descriptor is less than FD_SETSIZE, then we test it with select. If it’s greater than that, we use poll. Thus far it seems like a good compromise until we develop better method for high volume socket testing.

NOTE: If your web server is not configured to run a pool of 1024 threads, do NOT configure siege with that many simulated users. If you use more siege threads than available web server threads, connections will back up while waiting for handlers and before you know it, you’ll have a mess. You’ve been warned. 

http://download.joedog.org/siege/beta/siege-3.1.0-rc3.tar.gz