I came across an interesting tool – Which loads faster?, which allows you to load two web sites side-by-side and measure which one of those loads faster. If you reload the sites several times, you’ll also get the average statistics across all runs.
Tag: performance
Cloud performance comparison
O’Reilly Radar runs the blog post comparing performance of several cloud services. While everyone should run their own tests and benchmarks before deciding which one is better, the article provides a nice summary. Here is the graph based on their results.
Zip vs. Bzip2
While investigating an unrelated issue on our backup server, I came across an interesting discussion about gzip vs. bzip2. I was surprised to read on how much slower bzip2 is. I even tested it on our server. And as expected, I saw the huge difference.
$ du -sh home 819M home $ time tar czf test.tar.gz home real 3m29.741s user 1m4.026s sys 0m5.629s $ time tar cjf test.tar.bz2 home real 11m38.751s user 6m19.259s sys 0m7.237s $ ll test.tar* -rw-r--r-- 1 leonid users 365987716 2010-06-29 13:08 test.tar.bz2 -rw-r--r-- 1 leonid users 390655750 2010-06-29 12:56 test.tar.gz
For such a small difference in size, the compression time difference is huge! Of course, I should play with more parameters, repeat the tests several times, and test the decompression time too. But the above test is still a good indication. Way too many scripts out there use the default parameters and substitute gzip with gzip2 without any testing. That’s obviously asking for trouble.
Fixing advanced search performance in RT3
It’s been bugging me for a while now that advanced search is extremely slow in our RT3. I thought it was something related to the famous Perl bug, but apparently it wasn’t. Then I was I waiting for Fedora 10 to come out, so that we’d upgrade our RT3 installation to version 3.8. And that didn’t solve the problem either. Finally, we got bored and annoyed enough by this problem to actually do soemthing about it. The solution was, as often, just a Google search away. Here is the quote from this discussion:
Faulty rights on a specific queue caused the owner list to be quite long, which RT didn’t like. (By mistake someone had given the own ticket right on the queue to all unprivileged users)
I went through all the queues to check the rights, and there it was – a test queue had “Own Ticket” assigned to “Everyone”. Immediately, after remove this access levels things got back to normal.
InnoDB is better for SugarCRM
After SugarCRM was deployed, we were experiencing some lock ups. Not frequent or dangerous, but annoying. About once a week or every ten days or so, SugarCRM would lock up and won’t answer any queries at all. Not even the login was possible. A brief investigation showed that somehow it was locking up the MySQL database – about 15 processes (using “show full processlist”) in Locked state, with no data being sent back or forth. All locked queries were rather complex, with several JOINs. The load on the system was somewhat high, since we have about a few dozen operators working on it at the same time.
A similarly brief Google search suggested (see here and here) and explained converting MySQL tables from InnoDB to InnoDB. A test has been performed and everything went OK. Our SugarCRM database is about 600 MBytes and it was converted from MyISAM to InnoDB in under 20 minutes. The best part is that it takes even less to convert back to MyISAM, in case you change your mind.
It’s been a few days now since we did the conversion and it looks OK. Also, the CRM itself feels a bit faster.