Re: saslauthd performance anxiety
On Fri, 10 Jan 2003, Paul M Fleming wrote: Personally I have issues with dumping the contents of a password cache to a file. Especially in this case, they WILL be stored in cleartext. I had planned on keeping somes stats (hits,misses,etc) Fair enough. Even if you don't dump passwords, it might be useful to show info like the username, when its entry was added to the cache, and when it was last hit. This could be handy when answering questions like why did user X experience an auth failure at time T?. -- Simon Brady mailto:[EMAIL PROTECTED] ITS Technical Services University of Otago, Dunedin, New Zealand
Re: saslauthd performance anxiety
My current thinking is to use http://www.ossp.org/pkg/lib/mm/ for the shared memory stuff and http://256.com/sources/table/ for the hash table I haven't had a chance to look at: ftp://ftp.net.ohio-state.edu/pub/users/jrumpf/krbdirp-1.2.0.tar.gz yet Igor Brezac wrote: On Thu, 9 Jan 2003, Jeremy Rumpf wrote: On Thursday 09 January 2003 03:55 pm, Paul M Fleming wrote: Timing out the passwords is simple ( I think ) I would store the time when the entry is added and force a reauth if the password has been cached longer than a timeout (for example one hour ). That forces a reauth at least every timeout period of time. If an entry isn't in the cache (or if it is different the entry would be removed and ) a reauth would be forced. Every successfull auth would be added to the cache. Some time ago I wrote a plugin for the Netscape/iPlanet Directory server that intercepted bind authentications and passed them off to a kerberos backend. It allowed us to integrate LDAP services with our Kerberos environment. Anyhow, it implemented just this, with the timeouts and all. I also implemented a checkpoint feature where the hash table was periodically dumped to a file. That way if you restarted the LDAP server you wouldn't lose you're cached entries. You can grab a copy of the plugin at: ftp://ftp.net.ohio-state.edu/pub/users/jrumpf/krbdirp-1.2.0.tar.gz Look in the file krbdirp.c, specifically at the function validate_with_cache(). The text file CACHE also has some thoughts and ideas. The LDAP directory was used for an iPlanet mail setup to store user information. The idea of the credential cache has worked quite well. Implementing it for saslauthd would be a nice feature. I'd be more than willing to help/contribute to the effort. Cheers, Jeremy I agree. I know Simon would like this feature. :) Openldap APIs have client side cache, but I think it has some issues. saslauthd needs to remain a 'light' process. It is really a helper program for 'big' servers such as cyrus, sendmail, postfix, etc.. You might want to check out http://www.ossp.org/pkg/lib/mm/ for a portable IPC library. -- Igor
Re: saslauthd performance anxiety
This whole idea sounds great, especially as I'd expect a lot of the authentication load to come from a small number of users with their clients set to check mail every few minutes. For debugging it would help if there was a way to force a flush of the entire cache, and one to dump its contents. I'm not sure how you'd get saslauthd to recognise maintenance commands like this - maybe some method of out-of-band signalling, which seems better than tinkering with the socket protocol. -- Simon Brady mailto:[EMAIL PROTECTED] ITS Technical Services University of Otago, Dunedin, New Zealand How about SIGUSR1 and SIGUSR2? Cheers, Jeremy
Re: saslauthd performance anxiety
Personally I have issues with dumping the contents of a password cache to a file. Especially in this case, they WILL be stored in cleartext. I had planned on keeping somes stats (hits,misses,etc) Jeremy Rumpf wrote: This whole idea sounds great, especially as I'd expect a lot of the authentication load to come from a small number of users with their clients set to check mail every few minutes. For debugging it would help if there was a way to force a flush of the entire cache, and one to dump its contents. I'm not sure how you'd get saslauthd to recognise maintenance commands like this - maybe some method of out-of-band signalling, which seems better than tinkering with the socket protocol. -- Simon Brady mailto:[EMAIL PROTECTED] ITS Technical Services University of Otago, Dunedin, New Zealand How about SIGUSR1 and SIGUSR2? Cheers, Jeremy
Re: saslauthd performance anxiety
I always hashed the password as soon as they entered the cache. So the checkpoint dump would contain binary MD5, SHA hashes etc. They're not clear text per say, but I can see why some would not find even that ideal. Cheers, Jeremy On Friday 10 January 2003 11:07 am, Paul M Fleming wrote: Personally I have issues with dumping the contents of a password cache to a file. Especially in this case, they WILL be stored in cleartext. I had planned on keeping somes stats (hits,misses,etc) Jeremy Rumpf wrote: This whole idea sounds great, especially as I'd expect a lot of the authentication load to come from a small number of users with their clients set to check mail every few minutes. For debugging it would help if there was a way to force a flush of the entire cache, and one to dump its contents. I'm not sure how you'd get saslauthd to recognise maintenance commands like this - maybe some method of out-of-band signalling, which seems better than tinkering with the socket protocol. -- Simon Brady mailto:[EMAIL PROTECTED] ITS Technical Services University of Otago, Dunedin, New Zealand How about SIGUSR1 and SIGUSR2? Cheers, Jeremy
Re: saslauthd performance anxiety
Good point.. I don't have to store the cleartext version in order to do the compare.. if i save the hash and just hash what the user submits and compare them that would be sufficient.. just have to keep the cleartext password long enough to do an actual authentication if need be.. Jeremy Rumpf wrote: I always hashed the password as soon as they entered the cache. So the checkpoint dump would contain binary MD5, SHA hashes etc. They're not clear text per say, but I can see why some would not find even that ideal. Cheers, Jeremy On Friday 10 January 2003 11:07 am, Paul M Fleming wrote: Personally I have issues with dumping the contents of a password cache to a file. Especially in this case, they WILL be stored in cleartext. I had planned on keeping somes stats (hits,misses,etc) Jeremy Rumpf wrote: This whole idea sounds great, especially as I'd expect a lot of the authentication load to come from a small number of users with their clients set to check mail every few minutes. For debugging it would help if there was a way to force a flush of the entire cache, and one to dump its contents. I'm not sure how you'd get saslauthd to recognise maintenance commands like this - maybe some method of out-of-band signalling, which seems better than tinkering with the socket protocol. -- Simon Brady mailto:[EMAIL PROTECTED] ITS Technical Services University of Otago, Dunedin, New Zealand How about SIGUSR1 and SIGUSR2? Cheers, Jeremy
Re: saslauthd performance anxiety
On Wed, 1 Jan 2003, Igor Brezac wrote:
On Wed, 1 Jan 2003 [EMAIL PROTECTED] wrote:
[...]
Can anyone offer advice on tuning the saslauthd pool? Are there particular
options, either on the command line or in saslauthd.conf, which I should
be looking at?
Try using 'ldap_auth_method: custom'. It is up to three times faster
than the 'bind' method.
Thanks for the suggestion. Unfortunately 'custom' wasn't an option for
us, although we certainly could have benefited from it. The reason we
can't use it is that to support password migration our shell back-end does
mad things like:
try binding to new server;
if (failure) {
try binding to old server;
if (success)
update user password in new server for next time;
}
Don't look at me, I just inherited it :-)
This logic (to use the term loosely) makes it impossible to return a
sensible response to a search on userPassword. Instead, I committed a
gross hack and implemented a new method called auth_fastbind. It does away
with the search and extra anonymous bind in auth_bind by making two
assumptions:
1. Expanding the ldap_filter expression gives the fully-qualified DN
2. There is no cost to staying bound as a named user
These held for our shell back-end, but I don't know how applicable they
are to wider use. Still, if anyone's interested I've attached the patch
(against 2.1.10).
Simon Brady mailto:[EMAIL PROTECTED]
Systems Specialist Ph. +64 3 479-5217
ITS Technical Services Fax +64 3 479-5080
University of Otago, Dunedin, New Zealand Mobile +64 27 411-6045
diff -ru cyrus-sasl-2.1.10.orig/saslauthd/lak.c cyrus-sasl-2.1.10/saslauthd/lak.c
--- cyrus-sasl-2.1.10.orig/saslauthd/lak.c Fri Dec 6 02:54:58 2002
+++ cyrus-sasl-2.1.10/saslauthd/lak.c Fri Jan 10 00:19:45 2003
@@ -70,6 +70,7 @@
static int lak_search(LAK *, const char *, const char **, LDAPMessage **);
static int lak_auth_custom(LAK *, const char *, const char *, const char *);
static int lak_auth_bind(LAK *, const char *, const char *, const char *);
+static int lak_auth_fastbind(LAK *, const char *, const char *, const char *);
static int lak_result_add(LAK *lak, const char *, const char *, LAK_RESULT **);
static int lak_check_password(const char *, const char *, void *);
static int lak_check_crypt(const char *, const char *, void *);
@@ -179,6 +180,8 @@
} else if (!strcasecmp(key, ldap_auth_method)) {
if (!strcasecmp(p, custom)) {
conf-auth_method = LAK_AUTH_METHOD_CUSTOM;
+ } else if (!strcasecmp(p, fastbind)) {
+ conf-auth_method = LAK_AUTH_METHOD_FASTBIND;
}
} else if (!strcasecmp(key, ldap_timeout)) {
conf-timeout.tv_sec = lak_config_int(p);
@@ -917,6 +920,24 @@
}
+static int lak_auth_fastbind(LAK *lak, const char *user, const char *realm, const
+char *password)
+{
+ int rc;
+ char *dn = NULL;
+
+ rc = lak_filter(lak, user, realm, dn);
+ if (rc != LAK_OK || dn == NULL) {
+ syslog(LOG_WARNING|LOG_AUTH, lak_filter failed.);
+ return LAK_FAIL;
+ }
+
+ rc = lak_bind(lak, LAK_BIND_AS_USER, dn, password);
+
+ free(dn);
+ return rc;
+}
+
+
int lak_authenticate(LAK *lak, const char *user, const char *realm, const char
*password)
{
int rc;
@@ -932,8 +953,10 @@
if (lak-conf-auth_method == LAK_AUTH_METHOD_BIND) {
rc = lak_auth_bind(lak, user, realm, password);
- } else {
+ } else if (lak-conf-auth_method == LAK_AUTH_METHOD_CUSTOM) {
rc = lak_auth_custom(lak, user, realm, password);
+ } else {
+ rc = lak_auth_fastbind(lak, user, realm, password);
}
return rc;
diff -ru cyrus-sasl-2.1.10.orig/saslauthd/lak.h cyrus-sasl-2.1.10/saslauthd/lak.h
--- cyrus-sasl-2.1.10.orig/saslauthd/lak.h Fri Oct 18 10:30:58 2002
+++ cyrus-sasl-2.1.10/saslauthd/lak.h Fri Jan 10 00:19:45 2003
@@ -53,6 +53,7 @@
#define LAK_AUTH_METHOD_BIND 0
#define LAK_AUTH_METHOD_CUSTOM 1
+#define LAK_AUTH_METHOD_FASTBIND 2
typedef struct lak_conf {
char *path;
Re: saslauthd performance anxiety
On Wed, 1 Jan 2003, Kervin L. Pierre wrote: Maybe you should seriously consider moving from back-shell to back-perl, which you can optimize much more and is probably quicker right of the bat, since it does not spawn a separate process for the interpreter. Better still, have you thought of back-meta or back-ldap? These were designed for ldap routing. Hmmm, good suggestions. I'd looked at the OpenLDAP 2.1 Admin Guide early on, and nothing in it jumped out at me as justifying going beyond 2.0.27 (the words latest stable have a warm glow about them...). If I'd known about these other back-ends I would probably have decided differently. Given that 2.1 is a big unknown to us (and it seems to want things like DB4 which we don't have experience with), I'm not keen on dropping it into production without some serious testing. Still, it sounds like just what we need. (On the subject of OpenLDAP and back-shell, I should also mention that we uncovered a nasty race condition that can lead to deadlocked shell subprocesses. The bug report and fix are at http://www.OpenLDAP.org/its/index.cgi?findid=2262) I suspect you're optimizing the the wrong bottleneck. You are sooo right - I upped the saslauthd pool enough to prevent exhaustion, and we were fine for the first few days until the users came back. By about 9am Friday the CPU overhead of spawning all those perl processes had authentication timing out horribly (and the above-mentioned deadlock issue didn't help either). And that was just the start... In the end I reduced the load by hacking saslauthd (as described in my reply to Igor), which bought us time to write and test a C replacement for the perl. Of course the perl is much easier to understand and maintain, so going to a smart back-end is a better long-term solution. Oh well, live and learn... Thanks for the advice all the same! Simon Brady mailto:[EMAIL PROTECTED] Systems Specialist Ph. +64 3 479-5217 ITS Technical Services Fax +64 3 479-5080 University of Otago, Dunedin, New Zealand Mobile +64 27 411-6045
Re: saslauthd performance anxiety
On Fri, 10 Jan 2003 [EMAIL PROTECTED] wrote:
On Wed, 1 Jan 2003, Igor Brezac wrote:
On Wed, 1 Jan 2003 [EMAIL PROTECTED] wrote:
[...]
Can anyone offer advice on tuning the saslauthd pool? Are there particular
options, either on the command line or in saslauthd.conf, which I should
be looking at?
Try using 'ldap_auth_method: custom'. It is up to three times faster
than the 'bind' method.
Thanks for the suggestion. Unfortunately 'custom' wasn't an option for
us, although we certainly could have benefited from it. The reason we
can't use it is that to support password migration our shell back-end does
mad things like:
try binding to new server;
if (failure) {
try binding to old server;
if (success)
update user password in new server for next time;
}
Don't look at me, I just inherited it :-)
This logic (to use the term loosely) makes it impossible to return a
sensible response to a search on userPassword. Instead, I committed a
gross hack and implemented a new method called auth_fastbind. It does away
with the search and extra anonymous bind in auth_bind by making two
assumptions:
1. Expanding the ldap_filter expression gives the fully-qualified DN
2. There is no cost to staying bound as a named user
These held for our shell back-end, but I don't know how applicable they
are to wider use. Still, if anyone's interested I've attached the patch
(against 2.1.10).
I like this patch. This can work well for quite a few people. Rob, can
you apply this patch?
--
Igor
diff -ru cyrus-sasl-2.1.10.orig/saslauthd/lak.c cyrus-sasl-2.1.10/saslauthd/lak.c
--- cyrus-sasl-2.1.10.orig/saslauthd/lak.c Fri Dec 6 02:54:58 2002
+++ cyrus-sasl-2.1.10/saslauthd/lak.c Fri Jan 10 00:19:45 2003
@@ -70,6 +70,7 @@
static int lak_search(LAK *, const char *, const char **, LDAPMessage **);
static int lak_auth_custom(LAK *, const char *, const char *, const char *);
static int lak_auth_bind(LAK *, const char *, const char *, const char *);
+static int lak_auth_fastbind(LAK *, const char *, const char *, const char *);
static int lak_result_add(LAK *lak, const char *, const char *, LAK_RESULT **);
static int lak_check_password(const char *, const char *, void *);
static int lak_check_crypt(const char *, const char *, void *);
@@ -179,6 +180,8 @@
} else if (!strcasecmp(key, ldap_auth_method)) {
if (!strcasecmp(p, custom)) {
conf-auth_method = LAK_AUTH_METHOD_CUSTOM;
+ } else if (!strcasecmp(p, fastbind)) {
+ conf-auth_method = LAK_AUTH_METHOD_FASTBIND;
}
} else if (!strcasecmp(key, ldap_timeout)) {
conf-timeout.tv_sec = lak_config_int(p);
@@ -917,6 +920,24 @@
}
+static int lak_auth_fastbind(LAK *lak, const char *user, const char *realm, const
+char *password)
+{
+ int rc;
+ char *dn = NULL;
+
+ rc = lak_filter(lak, user, realm, dn);
+ if (rc != LAK_OK || dn == NULL) {
+ syslog(LOG_WARNING|LOG_AUTH, lak_filter failed.);
+ return LAK_FAIL;
+ }
+
+ rc = lak_bind(lak, LAK_BIND_AS_USER, dn, password);
+
+ free(dn);
+ return rc;
+}
+
+
int lak_authenticate(LAK *lak, const char *user, const char *realm, const char
*password)
{
int rc;
@@ -932,8 +953,10 @@
if (lak-conf-auth_method == LAK_AUTH_METHOD_BIND) {
rc = lak_auth_bind(lak, user, realm, password);
- } else {
+ } else if (lak-conf-auth_method == LAK_AUTH_METHOD_CUSTOM) {
rc = lak_auth_custom(lak, user, realm, password);
+ } else {
+ rc = lak_auth_fastbind(lak, user, realm, password);
}
return rc;
diff -ru cyrus-sasl-2.1.10.orig/saslauthd/lak.h cyrus-sasl-2.1.10/saslauthd/lak.h
--- cyrus-sasl-2.1.10.orig/saslauthd/lak.h Fri Oct 18 10:30:58 2002
+++ cyrus-sasl-2.1.10/saslauthd/lak.h Fri Jan 10 00:19:45 2003
@@ -53,6 +53,7 @@
#define LAK_AUTH_METHOD_BIND 0
#define LAK_AUTH_METHOD_CUSTOM 1
+#define LAK_AUTH_METHOD_FASTBIND 2
typedef struct lak_conf {
char *path;
Re: saslauthd performance anxiety
On Thu, 9 Jan 2003, Rob Siemborski wrote:
Done.
Someone should sanity-check the documentation I put in LDAP_SASLAUTHD.
Looks good.
I do not see when '2. There is no cost to staying bound as a named user'
would be false. Maybe for backends other then ldbm|bdb. It will cause
extra disconnect|reconnect to the ldap server for LDAPv2 connections.
Saslauthd will always try to connect LDAPv3 first. But this is the case
for the bind method as well.
-Igor
-Rob
On Thu, 9 Jan 2003, Igor Brezac wrote:
On Fri, 10 Jan 2003 [EMAIL PROTECTED] wrote:
On Wed, 1 Jan 2003, Igor Brezac wrote:
On Wed, 1 Jan 2003 [EMAIL PROTECTED] wrote:
[...]
Can anyone offer advice on tuning the saslauthd pool? Are there particular
options, either on the command line or in saslauthd.conf, which I should
be looking at?
Try using 'ldap_auth_method: custom'. It is up to three times faster
than the 'bind' method.
Thanks for the suggestion. Unfortunately 'custom' wasn't an option for
us, although we certainly could have benefited from it. The reason we
can't use it is that to support password migration our shell back-end does
mad things like:
try binding to new server;
if (failure) {
try binding to old server;
if (success)
update user password in new server for next time;
}
Don't look at me, I just inherited it :-)
This logic (to use the term loosely) makes it impossible to return a
sensible response to a search on userPassword. Instead, I committed a
gross hack and implemented a new method called auth_fastbind. It does away
with the search and extra anonymous bind in auth_bind by making two
assumptions:
1. Expanding the ldap_filter expression gives the fully-qualified DN
2. There is no cost to staying bound as a named user
These held for our shell back-end, but I don't know how applicable they
are to wider use. Still, if anyone's interested I've attached the patch
(against 2.1.10).
I like this patch. This can work well for quite a few people. Rob, can
you apply this patch?
--
Igor
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456
Research Systems Programmer * /usr/contributed Gatekeeper
--
Igor
Re: saslauthd performance anxiety
On Thursday 09 January 2003 03:55 pm, Paul M Fleming wrote: Timing out the passwords is simple ( I think ) I would store the time when the entry is added and force a reauth if the password has been cached longer than a timeout (for example one hour ). That forces a reauth at least every timeout period of time. If an entry isn't in the cache (or if it is different the entry would be removed and ) a reauth would be forced. Every successfull auth would be added to the cache. Some time ago I wrote a plugin for the Netscape/iPlanet Directory server that intercepted bind authentications and passed them off to a kerberos backend. It allowed us to integrate LDAP services with our Kerberos environment. Anyhow, it implemented just this, with the timeouts and all. I also implemented a checkpoint feature where the hash table was periodically dumped to a file. That way if you restarted the LDAP server you wouldn't lose you're cached entries. You can grab a copy of the plugin at: ftp://ftp.net.ohio-state.edu/pub/users/jrumpf/krbdirp-1.2.0.tar.gz Look in the file krbdirp.c, specifically at the function validate_with_cache(). The text file CACHE also has some thoughts and ideas. The LDAP directory was used for an iPlanet mail setup to store user information. The idea of the credential cache has worked quite well. Implementing it for saslauthd would be a nice feature. I'd be more than willing to help/contribute to the effort. Cheers, Jeremy
Re: saslauthd performance anxiety
On Thu, 9 Jan 2003, Jeremy Rumpf wrote: On Thursday 09 January 2003 03:55 pm, Paul M Fleming wrote: Timing out the passwords is simple ( I think ) I would store the time when the entry is added and force a reauth if the password has been cached longer than a timeout (for example one hour ). That forces a reauth at least every timeout period of time. If an entry isn't in the cache (or if it is different the entry would be removed and ) a reauth would be forced. Every successfull auth would be added to the cache. Some time ago I wrote a plugin for the Netscape/iPlanet Directory server that intercepted bind authentications and passed them off to a kerberos backend. It allowed us to integrate LDAP services with our Kerberos environment. Anyhow, it implemented just this, with the timeouts and all. I also implemented a checkpoint feature where the hash table was periodically dumped to a file. That way if you restarted the LDAP server you wouldn't lose you're cached entries. You can grab a copy of the plugin at: ftp://ftp.net.ohio-state.edu/pub/users/jrumpf/krbdirp-1.2.0.tar.gz Look in the file krbdirp.c, specifically at the function validate_with_cache(). The text file CACHE also has some thoughts and ideas. The LDAP directory was used for an iPlanet mail setup to store user information. The idea of the credential cache has worked quite well. Implementing it for saslauthd would be a nice feature. I'd be more than willing to help/contribute to the effort. Cheers, Jeremy I agree. I know Simon would like this feature. :) Openldap APIs have client side cache, but I think it has some issues. saslauthd needs to remain a 'light' process. It is really a helper program for 'big' servers such as cyrus, sendmail, postfix, etc.. You might want to check out http://www.ossp.org/pkg/lib/mm/ for a portable IPC library. -- Igor
Re: saslauthd performance anxiety
Correct.. John Alton Tamplin wrote: Paul M Fleming wrote: Timing out the passwords is simple ( I think ) I would store the time when the entry is added and force a reauth if the password has been cached longer than a timeout (for example one hour ). That forces a reauth at least every timeout period of time. If an entry isn't in the cache (or if it is different the entry would be removed and ) a reauth would be forced. Every successfull auth would be added to the cache. Also, if the authentication against the cached entry fails it should be refreshed and tried against the new one, so that if the user changes their password the caching is transparent. -- John A. Tamplin Unix System Administrator Emory University, School of Public Health +1 404/727-9931
Re: saslauthd performance anxiety
Paul M Fleming wrote: Timing out the passwords is simple ( I think ) I would store the time when the entry is added and force a reauth if the password has been cached longer than a timeout (for example one hour ). That forces a reauth at least every timeout period of time. If an entry isn't in the cache (or if it is different the entry would be removed and ) a reauth would be forced. Every successfull auth would be added to the cache. Also, if the authentication against the cached entry fails it should be refreshed and tried against the new one, so that if the user changes their password the caching is transparent. -- John A. Tamplin Unix System Administrator Emory University, School of Public Health +1 404/727-9931
Re: saslauthd performance anxiety
--On Wednesday, January 01, 2003 9:21 PM -0500 Igor Brezac [EMAIL PROTECTED] wrote: [...] If you are on Solaris, I highly recommend the doors IPC method over the UNIX socket method, since we began to see very bizarre problems under load. You might run into problems if you use ldap api and doors, ldap module may not be thread safe. In addition, thread safe ldap libs need to be used when saslauthd-doors is built. I'd like to enhance saslauthd to use loopback interface at some point, this will solve the problem with unix sockets and you do not need to worry about thread safety. Solaris doors are really the ideal form of IPC for saslauthd. They have the problem that code has to be thread-safe and thus it isn't for everybody, but for high performance sites it really is a good deal. Using the loopback interface will probably cause more people to raise security flags (as it is, people seem to worry about saslauthd and Unix sockets, which have much more obvious access control). Larry
Re: saslauthd performance anxiety
On Wed, 1 Jan 2003 [EMAIL PROTECTED] wrote: Since it's hard to predict peak usage, I'm tempted to run the daemon with the -n0 option so it can spawn as required. However, a colleague has pointed out that if something blows up then spawn-on-demand could kill the server - with a fixed-size pool, auth requests would fail but the system would keep going. At CMU, before we went to using the doors IPC method (due to unix domain socket issues under load on solaris), we used a value for -n of 2x our 5 minute connection rate peak (which we have from historical graphs). If you are on Solaris, I highly recommend the doors IPC method over the UNIX socket method, since we began to see very bizarre problems under load. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: saslauthd performance anxiety
[EMAIL PROTECTED] wrote: directory it's binding to is quite slow (it's actually a slapd instance running a shell backend which routes bind requests to different places depending on the usercode - don't ask...). Because saslauthd makes Maybe you should seriously consider moving from back-shell to back-perl, which you can optimize much more and is probably quicker right of the bat, since it does not spawn a separate process for the interpreter. Better still, have you thought of back-meta or back-ldap? These were designed for ldap routing. I suspect you're optimizing the the wrong bottleneck. -- = Kervin Pierre [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: saslauthd performance anxiety
On Wed, 1 Jan 2003 [EMAIL PROTECTED] wrote: I've just upgraded to imapd 2.1.11, and while it's going fine so far I'm a bit concerned about how it will cope under load when our students return. The problem is that I'm using the saslauthd native LDAP mechanism, and the directory it's binding to is quite slow (it's actually a slapd instance running a shell backend which routes bind requests to different places depending on the usercode - don't ask...). Because saslauthd makes synchronous bind calls, it's doesn't take many concurrent requests to exhaust the default pool of five instances. Since it's hard to predict peak usage, I'm tempted to run the daemon with the -n0 option so it can spawn as required. However, a colleague has pointed out that if something blows up then spawn-on-demand could kill the server - with a fixed-size pool, auth requests would fail but the system would keep going. How many concurrent authentications do you need? You can use testsaslauthd (in $cyrus-sasl/saslauthd) to verify the performance of saslauthd. Can anyone offer advice on tuning the saslauthd pool? Are there particular options, either on the command line or in saslauthd.conf, which I should be looking at? Try using 'ldap_auth_method: custom'. It is up to three times faster than the 'bind' method. -Igor
