Lately, I’ve been using Aperture more than ever because several recent trips I’ve gone on have left me with a ton of pictures to go organize. If it wasn’t for the fact that I’ve got 8+ years of photos and associated metadata, I would have jumped ship months ago.  I’ve tried all of Aperture’s First Aid options (accessed by holding Option-Command when opening the app): rebuilding permissions (this shouldn’t cause performance issues, but hey, I was desperate), repairing the database and finally resorting the the rebuild database option. I felt like the speed increased slightly after repairing the database and was optimistic that my problems were solved. Yet, I still had issues. I’ve been convinced that this has been a disk related as my memory and CPU are never loaded very heavily when I sit and wait for Aperture to do “stuff.” I began to think I needed a 7200 RPM disk drive instead of my 5400 RPM drive just to use Aperture.

Finally, I found an article that talked about removing the old com.apple.Aperture.plist file in ~/Library/Preferences to gain back some performance.  Today I decided to try that. But before I wiped the old .plist file, I went ahead and made a backup of it.  All I can say is, whoa. That actually worked. Aperture is actually snappy again. It’s ridiculous. I don’t even remember when I last experienced a responsive Aperture interface. Since I had a before and after .plist file, I did some diffing to figure out what was going wrong. While viewing the diff, I removed some of the options that seemed like they had no way of contributing to the slowness (things like default window locations, background colors, etc). That left me with the following diff:

1a2,3
> "" = "";
> "61-2" = "2008-08-03T19:05:02Z";
2a5,6
> "addCurrentSelectedVersions" = YES;
> "allProjectsSortMenuTag" = 1;
18a23,27
> "DotMacConfigurationDictionary" = {
> };
> "DotMacConfigurationLastUpdate" = "2010-08-17T15:44:23Z";
> "DotMacConfigurationLastURL" = "https://configuration.apple.com/configurations/internetservices/iapps/publishConfiguration08.plist";
> "ExportAttachmentsWithMastersKey" = YES;
19a29,32
> FacesEnabled = NO;
> fastBrowse = NO;
> FileHandling = 1;
> filesystemBatchSize = 10;
23c36
< projectSortingMode = 0;
---
> projectSortingMode = 1;
25a39
> fullscreenAvoid = NO;
27c41,42
< "fullscreenWhichWindow" = NO;
---
> "fullscreenWhichWindow" = YES;
> fullSizeJPEGQuality = 0.5;
35a51
> icaBatchSize = 5;
43a60
> "limitPreviewSubsample" = 1920;
46a64,67
> mainSecondaryMode = 3;
> "MetadataPresetSelectedPreset" = 0;
> "moveCurrentSelectedVersions" = NO;
> MUPhotoSize = 100;
48a70
> primaryOnly = NO;
55a78,79
> "showProjectVersionCount" = YES;
> "showUnplacedImagesOnly" = NO;
56a81,83
> subsequentLaunch = YES;
> UseEmbeddedJPEG = NO;
> ViewerPropertySet = 2;
64a92
> "WebKitEnableFullDocumentTeardown" = YES;


Immediately, there were two things that stood out to me: fastBrowse = NO and filesystemBatchSize = 10 . Seeing as I felt there was a disk issues, I decided to test out the issue. I opened the current .plist file and added in filesystemBatchSize = 10 and opened Aperture. It didn’t seem quite as slow as before, but it was noticeably slower for me. Now, I have no idea what the default filesystemBatchSize should be, but I do know that for me, removing it from the .plist file sped up Aperture considerably.  I didn’t do any objective measurements (ie. stopwatch tests), but so far, I’m not sitting waiting around hating Aperture for stealing my time.  What is the take away here? If you are having issues with Aperture’s performance, make a backup of your Aperture preferences .plist and delete the one in ~/Library/Preferences to try and get some improvement.

I then started looking into PHP clients as our current environment is mostly PHP. We require that the client support consistent hashing, and, from a quick search, a couple turned up. PRedis seemed to offer the most potential, and after some quick tests, also seemed to offer the greatest performance. So I set up a more elaborate benchmark of the the client and server package.

My test setup involved using 5 servers with between 2 and 5 enabled at a time on the clients (ie. I disabled up to 3 of the servers in the client configurations). For performance, I configured the servers to never write to disk, though periodically syncing to disk should not cause too much of a performance loss. In fact performance was most greatly affected by forcing an fsync after every write. I then had 9 other client boxes running the same code base, with all 9 enabled for each test.

Each client would start a master PHP process that forked 20, 30 or 40 child processes to simulate greater and greater load. Each forked PHP process then did 10,000 SETs on random keys with 4 byte payloads (early tests showed that payload size didn’t drastically affect the results). I was using the PHP 4.2.6 branch of the PRedis client, and had optimized it a bit so that it did fewer counts of the consistent hash array. I made the optimizations based on some results after profiling the code. I then had the master PHP process on each box repeat the test 5 times to help to average the test results.

I used dsh to start the test simultaneously on all the clients, timing how long it took the dsh process to start and finish executing. This was the amount of time it took to execute (5 repeats) * (9 client boxes) * (20, 30 or 40 client processes / box) * (10,000 requests) = X total requests. I then graphed the results below.

Graphing Requests / Second With Redis and PRedis

This ended up showing that with 9 clients, going up to 4 servers was the point of diminishing returns. Adding the fifth server (with that client box count) did not increase throughput, but rather, the throughput went down. The reason for this is most likely a combination of network interface contention on each client and higher overhead from consistent hashing. So with 9 clients, I found that the sweet spot, with my setup, was 4 servers. By adding more clients, along with more servers, the throughput would increase, instead of the decrease I was starting to see.