That's what I get for being too darned busy -- MT eventually ages things off to nothing. Gotta dig into CSS at some point to see if I can't get it to keep the right column of stuff over on the right hand side, rather than do that nasty slide-over thing. (The one that's especially bad if there's more stuff in the side column than in the main text)
Anyway, for those keeping track at home, last weekend's workshop went reasonably well. There were 20-25 people if I counted right, without too many people bailing by the end. It may not have been what everyone was expecting, as it was lighter on the perl & python than I think was generally figured. Still, went well. I'm now pretty sure that a lot of parrot's fundamentals are sound, and I'm equally sure that there's a lot of stuff we still need to work on. Some of it's arguably library code, like IO, but we've got a really fuzzy core/library boundary. (Which, bluntly, is the way it ought to be. The distinction is far less necessary when dealing with an all-software setup than it is with hardware)
Given time, I think I could easily work up a full week "programming parrot" class. The slides I had could've been done in 6 hours rather than three with no loss of anything. With more explanations, examples, and exercises a 5 day class wouldn't be at all out of line. You, too, can learn what you need to write a compiler for your own in-house 4GL-from-hell that you're looking to replace with something that doesn't suck! Which is a task not to be over-looked, BTW. A lot of places have a large mass of code in one dead language or another, and being able to keep that code base going while allowing callouts to other languages is a really useful thing. (Imagine taking all your in-house RPG or MUMPS code and being able to refactor it to perl or python, or keep it as-is and do new work in something else)
Parrot, meanwhile, rolls on. There should be a 0.1.1 release this weekend. 0.1.0 was done back in the early spring, and a lot's happened since then. We don't think about it much, since we're all used to just sync-ing up to the CVS server (which anyone can do -- there's full anon CVS access and rsync access to the repository) but a lot of folks like having a stable release. So... 0.1.1. A lot's happened since 0.1.0, so it ought to be fun to read the release notes.
I've also done a little bit of maintenance on the back end here. All posts older from 2003 and before have been closed to comments. I got smacked by what amounted to a DDOS attack today, with spam posts hitting about every 20 seconds. MT-Blacklist caught them all (which was really nice) but between the load it places on the server and the load from the constant stream of inbound viruses and spam (which are also caught by ClamAV and SpamAssassin) the box got tipped over into swap and performance was shot to hell. Which I can generally cope with, but the box is the NAT gateway and name server for the machines at the house, so there wasn't much web surfing and mail pickup going on. That needed fixing. (At some point soon I'm going to throw another half-gig of memory into the server box to help cope with the next inevitable wave of internet vandalism or crapstorm)
Posted by Dan at October 6, 2004 01:42 PM | TrackBack (0)If your excessive CPU load is directly caused by incoming traffic, why not use a traffic shaper to put bandwidth limits on the spammers?
Posted by: ziggy at October 7, 2004 10:32 AMIt's not so much the incoming traffic as the result of that traffic. The blog here's backed by Postgres and the blacklist is darned big, so each comment post consumes a fair amount of CPU time and, more importantly, memory. (Perl not exactly being the most svelte of programs when it comes to memory use :)
The mail scanning is also relatively CPU and memory intensive -- ClamAV's not too bad, but SpamAssassin's not the lightest-weight of scanners, so each inbound mail message triggers off another process which snags memory and CPU.
Either one of them's not too bad on their own, and the mail server does manage its own internal resources relatively well. (I keep the number of queue runners down, so when another virus-driven crapstorm fires off the server doesn't fall over, though the queue can take ages to process) There's no real good limit on pending 'heavyweight' web requests, and the mail and web server software don't talk so the server sometimes gets into the situation where either one is OK, but together they swap the machine to its knees.
Part of the problem is that the system's set up for normal load but not provisioned too well for spikes, which the extra memory would help with. (Getting things running under mod_perl would probably help some too)
So the short answer is that bandwidth limiting won't buy me anything, and that it wouldn't tackle the real problem. Which is a pity -- if it were that easy...
Posted by: Dan at October 7, 2004 11:11 AMYou can use, for instance, in your main index template to display a fixed number of previous entries instead of the default behavior of going by date. Then your front page may get old but it won't get empty.
Hunh. The MTEntries lastn="23" tag following 'for instance', above, that I lovingly enclosed with ampersand lt and ampersand gt, showed up in my previewing, but was thoughtfully elided for the actual posting.
Posted by: Zed at October 7, 2004 01:57 PM