Hi, Whilst tracking down an AFP performance issue - our home directories are on an AFP server, the Parallels image is stored on the local hard disk - we are seeing thousands of the following entries in our AFP log. IP 10.1.1.95 - - [09/May/2007:03:12:39 0000] "OpenFork com.parallels.Parallels.plist" 0 0 0 IP 10.1.1.95 - - [09/May/2007:03:12:39 0000] "OpenFork com.parallels.Parallels.plist" 0 0 0 IP 10.1.1.95 - - [09/May/2007:03:12:41 0000] "OpenFork com.parallels.Parallels.plist" 0 0 0 IP 10.1.1.95 - - [09/May/2007:03:12:41 0000] "OpenFork com.parallels.Parallels.plist" 0 0 0 IP 10.1.1.95 - - [09/May/2007:03:12:42 0000] "OpenFork com.parallels.Parallels.plist" 0 0 0 IP 10.1.1.95 - - [09/May/2007:03:12:42 0000] "OpenFork com.parallels.Parallels.plist" 0 0 0 IP 10.1.1.95 - - [09/May/2007:03:12:44 0000] "OpenFork com.parallels.Parallels.plist" 0 0 0 Seems pretty excessive if this truely is opening the same file every few seconds. If anybody else is seeing this or has an explanation it would be greatly appreciated. --- Regards David Knight OneStep Solutions plc
Are you just seeing this just with Parallels or with other apps, too? I'm guessing that you already know that a .plist file is just an app's preferences file (they tend to reside under ~/Library/Preferences). It doesn't strike me as too odd that an app would regularly access its .plist file. Perhaps I'm overlooking something? I'd expect that many apps read their .plist files when starting up and only access them while running if a setting is changed by the user, but there's no strict rule requiring an app to work this way. One advantage of reading preferences on an as-needed basis is that any changes made externally to the .plist file are immediately reflected in the running app. Sometimes this can be useful.
Just Parallels is exhibiting this behaviour. Parallels is a single user application (though it might host a multi-user environment) so once it has read its own preferences there should be no need for it to read them again as these are preferences not state information. If a user updates their preferences then Parallels would write them back out but should have the values in memory so no need to re-read... Umm, maybe I have an answer and another question. A number of us run simultaneous emulations, is Parallels re-reading the prefs in case another session is changing them or is each emulation updating the preferences (with state information) and thus forcing a re-read ? Could somebody from Parallels comment ? --- Regards David Knight OneStep Solutions plc
So it sounds like most of the apps you're running read their .plists when starting up and that further access occurs only when users change preferences. That's the way I typically construct my own apps (I'm a .Net dev., but I imagine that the .config files I use are conceptually on par with Cocoa's .plist files), but I've built a few which had to respect preference changes while they were running. What you're seeing w/Parallels does seem a bit excessive, however. And you're right. It's not state information that's being stored in the .plist files. My guess is their code is using the most-reliable, but least-efficient, approach of reading from the .plist file every time a preference setting is needed. It's not an issue when the home directory resides on a local disk, and perhaps they never tested the scenario that you're using. That's an interesting question re: simultaneous sessions. I just popped open Parallels' .plist file and it appears to contain only global preferences. VM-specific prefs reside in the corresponding .pvs file (verified by opening it in a text editor). I guess I don't have much in the way of an answer to your question, but now I know a little more than I did before about how Parallels stores its config information. I second the motion for clarification from Parallels. There have been a number of interesting questions posted about some of the internal workings of the product. We're not asking for proprietary information, of course, but some of us would like to better understand the product in order to maximize its usefulness.
Have investigated further by enabling write logging on the AFP server and making sure users are only running a single instance of Parallels. What we see is "OpenFork com.parallels.Parallels.plist" per user every 1-2 seconds and no writes to the file so for some reason Parallels is re-reading the file continually ! Could somebody from Parallels comment ? --- Regards David Knight OneStep Solutions plc
