June 4, 2004
Friday realizations
Running on the treadmill the last few days I've had some revelations of how terribly I'm doing things on this site:
- I've been cron-ing jpegoptim to automatically run lossless optimizations to the images that I post. It hadn't occured to me until yesterday that all my monitors are optimzed with custom color profiles. I didn't noticed that the jpegoptim option "stripe-all" wasn't just removing EXIF and previews from the images, but it was also striping the embedded color profiles out of the jpegs-- so EVERYONE hasn't been seeing the same quality images I have been. Doh!
- Double whammy. Using ecto to create the thumbnails (via MT, via imagemagick) creates shitty thumbnails. Clicking the thumbnail and popping up the original is the only way to see a decent image. (I've known this since day one, but my laziness had gotten the better of me. Much eaiser for MT to make thumbnails on the fly than for me to play pixel monkey once a day.)
- Studio2f's Movable Type is slowing down. Static pages serve fast thanks to a well oiled apache and gzip. CGI based actions are another story. It's taking over 30sec for a comment to be posted. I think I've tracked the problem down to the billion crap sites MT-Blacklist has to check every comment for. Not sure how to speed that up, while keeping the crap-flooders at bay. I'm looking into using either speedy:cgi or mod_perl (which should be the default in the first place). Dunc fired up speed:cgi on his server and it work fine with minimal MT modification (replacing all the shebangs). the ultimate solution is probably upgrade the horsepower on this Sawtooth from 500mhz to 1ghz+...or better.
So what to do? The comment posting speed is going to take time to figure out and speed up. The images-- I'm going to start caring less about the size of this site. If you're still using a 56k dialup, tough luck, I'm going to start pushing some large jpegs out the door. Soon (may not be for a bit) I'm going to stop the heavy handed optimization and crappy thumbnails. I need sometime to rethink my new workflow, so these changes won't happen for a bit.
I can account for 20% of your regular readers that there's no 56k here.
that's great, but what about the new sam bisbee video!
I know you might be "married" to movable type... but have you considered switching from MT to Wordpress? It uses php/mysql instead of generating static pages. Just a thought. :)
I've been watching scripty-goddess' conversion to wordpress (http://www.scriptygoddess.com/) after the MT 3.0 licensing fiasco. It's been a little rough at times for her, and although I whole-hearty support open source, it sounds like wordpress needs a little maturity to develop into the same sort of CMS that MT is. I'm going to install wordpress on my development server and give it a whirl, but I think I'm going to be sticking with MT for a while- unless wordpress blows me away.
Aside from the perl speed, I'm happy with MT generating static files. By using static html, I can handle mild slashdotting with ease. On this 500Mhz server, php making repeated mysql requests to build completely dynamic pages would overload everything. As it is now, I've optimized my php and have minimal mysql requests on these pages. they load wicked fast, and can handle a serious swamping of heaps of requests at a time. It's the perl component that's the problem. And I really thing the fact that by default MT doesn't use mod_perl is the problem.
MT needs to launch perl every-time it's requested, if it was using mod_perl, perl would be memory resident and could handle persistent use.
testing mod_perl. 1, 2, 3
test2
Standardized tests favor the white man. I can't believe that this is a racist site!
test3
testing again