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 22.214.171.124 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.
Here’s a handy-dandy labor saving tip for you. Let’s say — and why not? — we want to make a linky-link like Pittsburgh Pirates in WordPress. With the URL copied to your clipboard, highlight the link text in the WordPress editor then hit Ctrl-v. Done and done. No need to use the chain link icon. You’re welcome.
NOTE: Andrew McCutchen tied the game for the Pirates in the bottom of the eight as Your JoeDog was working on the Pittsburgh Pirates link for this entry….
Earlier today we told you about a hard limit in siege. Since it relied on select rather than poll, it was unable to open more than 1024 concurrent sockets on most — maybe all! — operating systems. Now Your JoeDog never needs that many sockets but some of you are over 1000. When you scheduled that many, your OS would abort siege. Don’t worry, the Supreme Court is cool with that.
This limitation was the result of a design decision from 1999. Fortunately, a 2001 design decision made it easy to incorporate both mechanisms in the same distribution. The configure script will check to see if you have poll and, really, in 2015 you should have it. If you do, it will use that mechanism to test your sockets.
Nothing changes for you dinosaurs. If you don’t have poll, then you can carry on with your precious select.
So Your JoeDog could use some beta testers. The changes have been submitted to the main branch at github.com and they’re available in this distribution: http://download.joedog.org/siege/beta/siege-3.1.0-rc2.tar.gz
Test it, Doggers, test its little brains out.
Back in 1999-ish, Your JoeDog made a decision! Once he makes a decision, he doesn’t look back. “That’s over, Doggers. It’s time to move on.” And move on we did. Since 1999 we’ve been using select to check if our socket descriptor is ready for input. This is an important test because siege pounds your web server until it calls him “Daddy.” If the socket doesn’t get ready, then the request must time out or siege will hang.
We don’t want more hanging chads!
There were two mechanisms we could have used to accomplish this: poll and select. We chose select because it was more flexible and more readily available. At the time, we supported a great many platforms: Solaris, HP-UX, AIX, SCO, BSD, Linux, etc. The downside to select was its capacity. The fd_set couldn’t handle numbers higher than 1024. Well back in 1999, Yahoo! might have been doing 1024 concurrent connections but mere mortals didn’t need that capacity.
Recently we told you that siege crashes when large pools of simultaneous users are created. We finally got to the bottom of that problem and it dates back to that 1999 decision. Siege aborts when socket descriptors larger than 1024 are passed to FD_SET. We will fix this problem but there’s currently no ETA. It will require extensive testing and more of those difficult 1999-ish decisions.
For example, should we just stone-cold switch to poll or should we support both mechanisms? The latter will create a macro soup; does anyone have a stomach for that? Another option is create an array of fd_sets and place them on each thread. That would allow us to continue using select. (Your JoeDog kinda likes this option). And finally we could just say “Fsck it.” If you really have that many users, then you can afford Load Runner.
NOTE: To give you some perspective on traffic, this site is ranked 155,295 in the US. We almost never exceed 50 hits a second. Your JoeDog professionally webmasters a site ranked under 8000 and it almost never exceeds 100 hits a second. You must have a really large audience to generate 1024 hits a second. The vast majority of you should be fine with 255 threads or less.
We received messages about core dumps that occur when siege is run with more than 700 threads. That’s a lot of threads, you guys! First things first — and this can’t be stressed enough — if you run siege with -c700, make sure your web server is configured with a pool of 700 threads. If you hit a pool of 256 threads with 700 users, all you’re gonna do is make a mess, mmmkay?
Now back to those core dumps. Here’s the thing: we’ve been unable to reproduce the problem but some diligent siegers have worked with us to get stack traces. As a result, we’ve added improved error handling and integrity checks in the problematic region. Your JoeDog would greatly appreciate if you could test version 3.1.0 release candidate 1. You can provide feedback here or by email, whichever you prefer.