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.
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.
Your JoeDog is about to violate the RFC.
It won’t be the first time. Beginning with siege-3.0.6, we normalized URLs inside a Location header even though the RFC is clear: IT MUST BE AN ABSOLUTE URI, people. Just about ever browser does this so who are we to buck the trend?
With siege-3.1.1, we will add URI fragments to the request and send them to the server. Under nearly all conditions, a client is not supposed to do this. But if you want to send fragments to the server, then who are we to turn down the volume on your Ramones?
It if proves problematic, we’ll make it an option. To avoid sending fragements, omit them from your URLs.
Starting with version 3.1.1, siege supports Server Name Indication. During the SSL handshake, it will send the name of the server with which it wants to connect. This means it supports virtual hosting of HTTPS servers.
Siege 3.1.1 also includes several minor bug fixes. See the ChangeLog for details.
Sorry about the radio silence. Your JoeDog has been turning caffeine into code again. We’ve applied some patches to siege. Thanks to Rob, we fixed a potential segfault. Thanks to Kaspar, you guys can post from files that contain null bytes.
We’re also working on NTLM authentication. That’s the stuff Microsofties like to use when they configure IIS. At the moment, support is next to worthless. You can successfully authenticate but it doesn’t maintain session. So it works great for -g/–get requests but don’t expect to lay siege with it.
Your JoeDog wanted this code in the main branch so it was available to other developers. It does no harm to include this partially broken implementation. NTLM Authentication didn’t before today. Now it partially works. Baby steps, people. Baby steps.
Much of the implementation was stolen from wget-1.16. Their implementation was stolen from libcurl. The first rule of open source is this: never reinvent the wheel. Our problem does not involve hashing passwords into something IIS understands. The wget/libcurl code performs just fine. We’re having trouble maintaining session after authentication.
There’s a chance we’ll bundle a source distribution soon but in the meantime, siege-3.1.1 is available on GitHub: JoeDog / Siege
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:
But this ain’t no normal night, mister. Tonight we add an additional second. That sequence looks like this:
2015-06-30 23.59.60 <-- leap second
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: adjust time server 184.108.40.206 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.
Your JoeDog distributes this software and hosts this site mostly as a hobby. He loves to code and he likes sharing his thoughts with you. Still, some days it can be aggravating. Some days it can be drudgery. Some days it can be both. Today was one of those days.
Yesterday evening an automated Turdpress update exposed a problem in Your JoeDog’s theme. This site came to a screeching halt. dowload.joedog.org was zippy quick but www.joedog.org lumbered along like a drunken walrus. Those sites share the same infrastructure so for once we couldn’t blame Amazon. It wasn’t a hosting issue. Something else brought the site to its knees.
Then Your JoeDog found this in his error_log:
PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate
940175 bytes) in /content/joedog.org/wp-includes/functions.php on line 380
So Your JoeDog went to line 380 of the functions.php file in his theme directory. Line 380 was the end of the file. At that location, he discovered were several functions no longer in use. He deleted those functions and — bam! — the site was zippy again. But here’s the thing: He misread that error message. The functions.php file wasn’t the one from his theme, it was a core Turdpress file.
So what happened? The current working theory is the one expressed at the start of this post. An upgrade exposed a flaw and Your JoeDog pulled a Homer. So we’re running again but this Saturday feels like just another day at work….
Do you run a Linux variation which uses APT for software distribution? You do? Good, let’s have a little fun. From the command line I want you to run this:
$ apt-get moo
Pretty cool, huh? Okay, let’s try another one. Do you have aptitude installed? If not you can get it like this:
$ apt-get install aptitude
Okay, now that you have that package run this command:
$ aptitude moo
It’s not serious, is it? Let’s add some verbosity:
$ aptitude moo -v
I still don’t believe it, do you? Let’s increase its verbosity with even more v’s:
$ aptitude moo -vv
You get the point now, don’t you? Keep adding v’s to that command until it finally grants your wish….
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.