Siege 3.1.0 Release Candidate 3

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



Helpful Heuristic: Quick Links In WordPress

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….



Siege 3.1.0 Release Candidate 2

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.

 



Select and Timeouts and Poll, Oh My!

Hanging ChadsBack 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.



Siege 3.1.0 RC 1

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.

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



Millions of Cookies, Cookies For Me

cookiemonsterA couple weeks ago, a reader notified Your JoeDog of a problem with siege’s cookie handling. When the server sets a cookie that’s already stored, siege won’t update its expiration time. A JoeDog Fellow told him, “That’s a paddlin’.” The last cookie in, is the next cookie out.

The investigation took Your JoeDog into cookie.c, a file he hasn’t touched in years. “This code is awful,” he said. “Who wrote this shit? … Hmm, some guy named Jeff Fulmer, et al. If I ever meet that guy, I’ll tell him a thing or two.”

As an ethnic German with a tendency to over engineer — well, um — everything,  Your JoeDog decided to completely overhaul cookie handling. Why change two lines when you can rewrite everything, amirite? The file cookie.c now contains a COOKIE object with getters and setters, cookies.c is a cookie list object which houses all cookies in memory. Cookies will persist in $HOME/.cookies but the details are still being considered.

Here’s the thing. Siege isn’t a browser, it’s many browsers. We store cookies at the thread level. Each thread gets its own list of cookies. To distinguish them, we used pthread_self(), which is a long long int like 140018384393984 or something. Technically it’s not a long long int, it’s a pthread_t, but you get the point. The next time you fire up siege, its threads will have different IDs so we need a convenient way to associate stored cookies with new thread IDs.

Furthermore, there’s no guarantee that your next run will have the same number of simulated users. We need to consider how to handle that situation. If you have 50 stored cookies and you run 60 new users, should we stop assigning cookies at 50 or do we start repeating them starting with cookie 1 to user 51? Inquiring minds want to know. I want to know.

The new code is not yet in version control. If you want a copy, let us know. We can create a beta branch or send you a tar ball. Happy hacking.

NOTE: Your JoeDog refers to cookie and cookies as objects because they are. Yes, siege is written in C rather than C++ but you can write objects in C just fine thankyouverymuch. An object is simply a thing which references itself. To achieve this in C, you just pass a reference to the object as an argument.



Hey! There’s No configure Script!!1!1!!!1!

Your JoeDog gets this a lot lately: “The INSTALL file says run ./configure but there’s no configure file.” It took a second but it’s now clear what’s happening. You guys are grabbing the code directly from github.com

When Your JoeDog redesigned this site, he put that snazzy “Fork me on Github” banner up in the corner. Exciting! So now you guys are forking me! Here’s the thing. The stuff on github is THE source code, it’s not a source distribution. You can find the source distribution on the downloads site.

So what’s the difference? The source distribution contains helper scripts which are generated by autotools. You know, like that configure script. Since configure is built from other files, it’s not a source file and we don’t maintain it in version control.

That doesn’t mean you can’t fork me on github! If you take that route, you’ll need to build your own configure script. We’ll learn how to do that after the jump….

Continue reading Hey! There’s No configure Script!!1!1!!!1!



Recursion Level 21 Exceeded

recursionYour JoeDog’s long national mail nightmare is over.

Here at JoeDog Industries we forward our mail to Gmail. Google de-spams them and places them snuggly into our mailboxes. When we send mail, Google masquerades as us, Your JoeDog. To play this game, they want secure authentication. It logs into our sendmail server which relays our precious messages.

Since our server was configured so that only authenticated users could relay and since Google was de-spamming our messages, Your JoeDog was all, “Why should we even bother with the bloated pig known as spam assassin?” So we shut it down and removed it from the system. Done and done, amirite?

Life was good! We were running a mail server on the public internets without paying a heavy price in terms of administration or computing costs.

Now Your JoeDog studied economics and one thing he learned was this: There’s so such thing as a free lunch. Well sum bitch if that ain’t true. A couple weeks ago, Gmail decided it would start bouncing obvious spam. Guess what happened?

They bounced the message and our mailer sent it back. So they bounced it again and we promptly sent it back. While this was going on, Amazon was all “Why are these fsckers crushing our infrastructure?” So they throttled our asses at the firewall. So then the mail queue started backing up.

At that point Your JoeDog was all, “UGH! We have to run spam assassin again.” The idea was this: We’ll catch spam before it gets to Google then they won’t bounce it back.”

Seems like a good idea, right? WRONG!

Google is better at this shit than Your Spam Assassin. Even though we caught a bunch of stuff, they found plenty more to bounce at us. With Amazon throttling us and Google bouncing us, JoeDog Industries became The United States of Suck.

The solution to this cluster bump turned out to be pretty simple. We’ll learn about that after the jump! Continue reading Recursion Level 21 Exceeded



How To Switch Your Site To HTTPS

I told you that Your JoeDog would eventually complete that task. There was no need to remind us every couple of months. It’s done, now. Cross it off the list.

Congratulations, I guess?? What task is now complete?

Last August Your Google announced that it would give all sites running https a slight rankings bounce. Your JoeDog thought, “Yeah, yeah, yeah. We should do that.” Then August became October and October became January and January became whatever comes after that. Now you’re able to read this blog over a secure connection.

Let’s set-up https after the jump! Continue reading How To Switch Your Site To HTTPS



It Knows When You Are Sleeping

lurchMohammad Sabah is a former Netflix data scientist who worked on that company’s movie recommendation engine. He brought some of that technology to Workday, an HR software manufacturer. So what’s the result of a marriage between movie recommendations and human resource management? It’s an application called Workday Talent Insights.

What’s that do? It’s kind of cool, actually. The program predicts which employee is likely to quit and what can be done to retain them. It’s not clear how many inputs it evaluates but Your JoeDog can envision an applicable scenario. Let’s say — and why not? — a really tall employee dislikes being known as “Lurch.” The application’s corrective action could be “Stop calling him that!”