Well, don’t have to worry about cooling my systems lately! Went downstairs last night and it was about 29F in the basement.
I figure since my main systems have two PIII processors, there should be no problem with them getting too cold!
Well, don’t have to worry about cooling my systems lately! Went downstairs last night and it was about 29F in the basement.
I figure since my main systems have two PIII processors, there should be no problem with them getting too cold!
I changed the info at Feedburner to reflect the new name of this blog. Please update your subscriptions.
Peter Lin has a Web performance paper here. Focuses on Java and Tomcat. Comments here.
Too bad he misses the point of external monitoring, because some of the other points he makes are very good. Too much focus on the data, not enough on how this improves performance.
Appears that he lives in the area. Peter, if you read this, say hi!
Watched Auschwitz on PBS tonight. It is terrifying to see this happening, but a historical perspective must be jarred to reality by the knowledge that the over-arching goals of the extermination camps still apears in human activity.
Sometimes I wonder if we are fit to consider ourselves the primary species on this world.
I have decided to change the name of this blog. This new title reflects what I do…as well as my personal philosophy.
It is also a great song by Husker Du.
Hang Around…fun ride ahead.
Ok, know that I have discovered the beauty of FULLTEXT indices, I know have discovered their dark side: even set for "IN BOOLEAN MODE", I get way more results than I was expecting.
Using the logic of the FULLTEXT search, it makes total sense. If I pass "/compression/" as a variable to the listing page, it returns everything that matches that string, including the sub-pages.
Time to haul out a regular expression. Using PHP’s ereg function, I perform a case insensitive match on the string.
if (ereg("^$page$","$row[DATABASE_URL]")) {
…
}
So I am skipping all of the overzealous returns, and displaying only the exact matches. And, believe it or not, this process is still far faster than using the REGEX engine in the MySQL query to start off with the exact matches.
If anyone has a less brain-damaged way to get MySQL to quickly return exact string matches, let me know.
Addendum: I found yet another brain-damaged thing with FULLTEXT searches: if you search to match against "/", exactly zero results are returned, even with "IN BOOLEAN MODE" turned off. This baffled me for a while, and is important enough for me to waste some mental energy on, as all requests for the root document in an Apache log file are referenced as "/".
After trying a few things, I actually had to write a corner-case "if" statement, that, if the passed URL exactly matches "/^/$/", use the REGEX method to pull the pages. All other pages are processed using FULLTEXT matching.
This behaviour is very weird.
I re-wrote the data inserting mechanism for the GrabPERF script. Previously, I had been looping through the measurements, then looping through the results to insert them.
Now I open two database connections, loop through the measurements and insert them after the data is collected. Much more efficient, although I am still a hack programmer.
I will be glad to share a sanitized version of the measurement script with anyone who asks.
As Darren states: Universe Collapses — Picasso on sale at Costco.
I hang my head in shame and seek a South Pacific Island to flee to.
I insert all of my Web server hits into a MySQL database, and a few of the queries I run were really slow. Then I discovered that using FULLTEXT Searches, as opposed to LIKE or REGEXP, were far superior.
Cut the query time by 80%. Ouch.
If you use non-binary CHAR, VARCHAR, or TEXT columns, consider a FULLTEXT Index on those columns.
Dave Winer points to Paolo’s site: Vintage iPods Club
Sort of like driving a vintage Prius, I guess.
Copyright © 2025 Performance Zen
Theme by Anders Noren — Up ↑