Day 59 of 60: Final thoughts
This system will be going back to Sun soon, while I wait to find out whether or not they’ve decided to grant me the system. In the meantime, here are some final thoughts on the last 59 days.
Day 59 of 60: Developer benchmarks (pt 4)
Yesterday’s tests show that using gcc on both FreeBSD and Solaris yields a marked improvement in the time taken to compile Perl.
However, despite the big difference in compile times, the run-times of Perl’s test suite aren’t dramatically affected. The worst performer, Perl running on Solaris, compiled with Sun’s cc and optimisation is 6% slower than the best performer, Perl running on FreeBSD, compiled with gcc and optimisation. This test involved a great deal of IO and process creation, and I thought that that might be part of the reason for the differences. So I’ve been using a Perl based application, SpamAssassin, to test whether or not there are big differences between the run times of the various Perl interpreters.
Day 58 of 60: Developer benchmarks (pt 3)
Yesterday I looked at performance compiling Sendmail on Solaris and FreeBSD using Sun’s compiler (on Solaris) and gcc (on both systems).
In the tests gcc come out handily ahead, with gcc on FreeBSD being 16% faster than gcc on Solaris with low optimisation options, and 12% faster than gcc on Solaris with optimisation turned on. Sun’s compiler was over twice as slow as gcc on either system.
Today I’ve been looking at the time taken to compile Perl on both systems, using both compilers, with and without optimisation.
Day 57 of 60: Developer benchmarks (pt 2)
As I explained on day 55, I’ve been comparing GCC and the Sun Studio compiler on Solaris, to GCC running on FreeBSD to see if there are any significant differences in the time taken to compile the applications, and if there is, whether that difference is reflected in the time taken by the applications to run. I used gcc 3.4.3 on both systems.
Day 46 of 60: Queue sort strategies
I’ve been looking at different queue sort strategies to see what their overhead is. Since all the messages are going to be delivered to a single host these results aren’t necessarily going to be indicative of what you would see on a production server. However, they should serve to illustrate any inherent speed advantages of one sort strategy over another.
Read on for the resuls.
Day 43 of 60: Multiple queues, multiple queue runners (pt 3)
It’s definitely a bug.
Specifically, in the default case, and contrary to the documentation, sendmail does not run one queue runner for every queue directory. It runs precisely one. I brought this up on the Sendmail mailing list, sendmail-2006@support.sendmail.org. The most recent message in that discussion (at the time of writing) follows.
Continue reading…
Day 31 of 60: Queues and connections
Back on day 28 I looked at the effect of multiple queue directories with concurrent senders.
These results showed that there was considerable benefit with 10 senders and 10 queue directories. The benefit going to 20 queue directories with 10 senders was negligible.
At the time I wondered whether this was a general rule — i.e., is anything more than 10 queue directories overkill? Or is there a correlation between the number of queue directories compared to the number of simultaneous sending systems.
Day 28 of 60: Instrumenting Sendmail queue file creation (pt 4)
Yesterday I looked at the effect of multiple queue directories when processing messages over a single connection.
Today I’ve been looking at how multiple queue directories can help when processing concurrent connections.
The methodology was identical to the previous tests. The only change was to the smtp-source(1) command line. The previous tests were run with -s 1, indicating one concurrent connection. These tests were run with -s 10, to force 10 concurrent connections.
Day 27 of 60: Instrumenting Sendmail queue file creation (pt 3)
I’ve commited the first sets of results to the repository in the aptly named results/ directory.
To refresh your memory, the question I intended to answer was:
does the number of queue directories (on a single disk) make a significant impact on the time taken to create new entries in the queue?
They’re quite surprising.