I’ve been banging my head against fastcgi. At a fundamental level, fastcgi is meant to be a CGI gateway allowing multiple simultaneous processes to run at once, to serve pages. Ok. nginx (and Apache, and others) can use fastcgi to run PHP code. Well, Apache can run it “natively” while the others need to run it externally. Our website is PHP based (drupal). So are some of our tools. And ya know, the transition to nginx has not been smooth for them.

This is somewhat tangential (at least the initial part) to HPC and storage, but it has significant similarities … its worth paying attention to. Much text, noise, and argumentation have surrounded things like Obamacare here in the US. This is, whether or not the proponents like to admit it or not, a push for a socialized medical system, with “controlled” costs, and all manner of other things. Yeah, we’ll hear how the US has “crappy” medical coverage, or country X is so much better because everyone gets coverage.

I was having lots … and I mean LOTS of trouble with apache 2.2 on the new web server. It simply refused to do vhosts no matter what I did. Debugging it was painful. I’d tried lighttpd in the past, and while I liked some aspects of it better than Apache, it still was hard to debug. So I figured I’d give nginx a try. Its an up and comer in the web serving business, and seems to be one of fastest growing on the net.

Talking about rt. Our support site. Thankfully most of the stuff is in the database with a little customization. Thankfully we want to move from 3.x to 4.x. Annoyingly, this is more work. Thankfully, our web server design is now far more intelligent than in the past. We may simply run it on the web frontend directly, rather than running it as a VM. There’s really little advantage to the VM, and we keep having to do a reset of the VM.

Dear Red Hat: You put out a good product in RHEL 6.x. Ignoring the (often massive) performance regressions, other things are better/more stable. Dracut, is growing on me. Actually liking being able to debug startup. But, this said … I have to inquire … Why on earth did you include an End-Of-Lifed version of Perl (5.10.x) in RHEL 6.x? What … exactly … was the thought process behind this? Have a look here: and search for “Latest releases in each branch”.

Enjoyed this read. Some of the take away snippets Ok, there is a combination of humor, and a possible simple test to determine if you are one of them thar bad “right-wingers” (note: tongue firmly planted in cheek here). Just ask a) education level, and b) opinion of AGW. But even more than this … this study was drive by the soft science folks wondering about some attitudes and levels of scientific literacy and numeracy.

Kyril Faenov of Microsoft passed away several days ago. He was one of the visionaries and leaders behind Microsoft’s HPC effort. He was also a nice guy, one whom I had a chance to talk with several times over the last few years. One of the bright folks you like to challenge. I respected him and his efforts, even if I didn’t agree with them. More information here, and I found this originally at InsideHPC.

c.f. this post at ZeroHedge. In case you haven’t guessed it, ZeroHedge does not like HFT aka algorithmic trading. Its an informative blog … sometimes bordering on alarmist … but for the most part, a good read.

We are working on a project for a consulting customer. They’ve hired us to help them figure out where their performance is being “lost”. Obviously, without naming names or revealing information, I note something interesting about this, that I’ve alluded to many times before. There is an often profound mismatch between expectations for a system and what it actually achieves. This is in large part, why we benchmark and test our systems in as real configurations as possible, and report real numbers, while many (most) of our competitors make WAGs at best case/best effort/best condition theoretical numbers.

We’ve been tuning our siFlash. Not done yet … not done, but look where we are. 24 simultaneous streaming (non-cached) reads. Run status group 0 (all jobs): READ: io=193632MB, aggrb=7781.4MB/s, minb=7781.4MB/s, maxb=7781.4MB/s, mint=24884msec, maxt=24884msec Yeah. Baby. Added another almost GB/s to the read performance. Streaming write performance is hovering around 2.6GB/s. Remember, this is a half configured system. Imagine what we could do with a fully configured system. Sustaining 147k random write IOPs (4k random writes, with 144 simultaneous threads), and 210k random read IOPs.