Satya's blog - 2009/12/

At last, a simple easy to use profiling option:

require 'profiler'
Profiler__::start_profile
do_stuff
Profiler__::stop_profile
Profiler__::print_profile($stderr)

Yay! Bog-slow, though. Without the profiling, the code ran in about 15 seconds. With profiling, 8 minutes! And then all I get is a dump of internal ruby functions getting called. I need to know which of *my* functions are slow. Oh, well.

Suppose you you Rails fragment caching. Fast and easy right? Now you have a model method which you call from cron to update your data. So you want to expire those fragments from cache. Well, according to this stackoverflow.com post it's next to impossible to cause the cached data to expire without breaking MVC. Solutions/workarounds involve instantiating controller objects or calling a controller method via HTTP. Rails Fail. Some things do NOT need to run via HTTP.

Either that, or I'm doing the wrong after_update method.

Or, it's a permissions issue. (Hint: this is the correct answer. after_update was being triggered but couldn't delete the cache files in /tmp.)

The point stands, though: advising people to muck with the controller, for a cron job to expire cached data, is wrong.

The Postfix SASL documentation says:

The "submission" destination port tells Postfix to send mail via TCP network port 587, which is normally reserved for email clients. The default is to send mail to the "smtp" destination port (TCP port 25), which is used for receiving mail across the internet.

So when my Postfix was trying to send to my (non-ISP) smart host on port 25, and my DSL provider was blocking 25, I had to add the port in main.cf:

relayhost = relayhost.example.com:587
smtp_sasl_password_maps = hash:/etc/postfix/sasl_map

And in my sasl password map file, instead of just relayhost.example.com, I needed to add the ":587" part, and then regenerate the db file:

postconf /etc/postfix/sasl_map