Connecting to legacy AFP services

http://support.apple.com/kb/HT4700???

Older, less secure authentication methods are not enabled by default in OS X Lion and Mountain Lion. You can enable one or more of these methods to support legacy devices or protocols by following these steps:

    1. Open Terminal.
    2. Execute the following commands:
      sudo chmod o+w /Library/Preferences
      sudo defaults write /Library/Preferences/com.apple.AppleShareClient afp_host_prefs_version -int 1

 

  1. Make an AFP connection to another system so that the AFP Client preference file will be filled in with the default set of values. Note: You must connect as a registered user, not as a guest.
  2. Execute the following command to see a list of the disabled User Authentication Methods (UAMs) 
    defaults read /Library/Preferences/com.apple.AppleShareClient afp_disabled_uams

    By default the disabled UAMs are “Cleartxt Passwrd”, “MS2.0”, “2-Way Randnum exchange”, and “DHCAST128”.Note: If you don’t see a list, restart your computer and repeat step 3.

  3. To enable one of these UAMs, remove it from the list of disabled UAMs. For example, this command enables DHCAST128 by removing it from the list of disabled authentication methods: 
    sudo defaults write /Library/Preferences/com.apple.AppleShareClient afp_disabled_uams -array "Cleartxt Passwrd" "MS2.0" "2-Way Randnum exchange"
  4. After the desired changes have been made, restore the permissions on the Preferences folder with this command: 
    sudo chmod o-w /Library/Preferences

RabbitMQ performance chart

http://www.rabbitmq.com/blog/2012/04/25/rabbitmq-performance-measurements-part-2/

Some Simple Scenarios

auto-ack44824msg/s

This first scenario is the simplest – just one producer and one consumer. So we have a baseline.

no-consume53710msg/s

Of course we want to produce impressive figures. So we can go a bit faster than that – if we don’t consume anything then we can publish faster.

max publish149910msg/s
This uses a couple of the cores on our server – but not all of them. So for the best headline-grabbing rate, we start a number of parallel producers, all publishing into nothing.
max consume64315msg/s
 Of course, consuming is rather important! So for the headline consuming rate, we publish to a large number of consumers in parallel.

Of course to some extent this quest for large numbers is a bit silly, we’re more interested in relative performance. So let’s revert to one producer and one consumer.

mandatory22402msg/s
 Now let’s try publishing with the mandatory flag set. We drop to about 40% of the non-mandatory rate. The reason for this is that the channel we’re publishing to can’t just asynchronously stream messages at queues any more; it synchronously checks with the queues to make sure they’re still there. (Yes, we could probably make mandatory publishing faster, but it’s not very heavily used.)
immediate22035msg/s
 The immediate flag gives us almost exactly the same drop in performance. This isn’t hugely surprising – it has to make the same synchronous check with the queue.
ack32005msg/s
Scrapping the rarely-used mandatory and immediate flags, let’s try turning on acknowledgements for delivered messages. We still see a performance drop compared to delivering without acknowledgements (the server has to do more bookkeeping after all) but it’s less noticeable.
ack-confirm26103msg/s
Now we turn on publish confirms as well. Performance drops a little more but we’re still at over 60% the speed of neither acks nor confirms.
a-c-persist4725msg/s
Finally, we enable message persistence. The rate becomes much lower, since we’re throwing all those messages at the disk as well.