When Thunderbird synchronizes address books, it requests the ETag for each contact in the address book to detect changes:

PROPFIND /SOGo/dav/user/Contacts/public/ HTTP/1.1

<propfind
    xmlns="DAV:"
    xmlns:card="urn:ietf:params:xml:ns:carddav"
    xmlns:cs="http://calendarserver.org/ns/"
    xmlns:d="DAV:">
    <prop>
        <resourcetype/>
        <getetag/>
        <cs:getctag/>
    </prop>
</propfind>

In case of an LDAP-backed shared address book, SOGo then establishes a new connection to the LDAP server for each contact in order to answer the above request:

slapd: conn=1003 fd=16 ACCEPT from IP=127.0.0.1:49722 (IP=127.0.0.1:389)
slapd: conn=1003 op=0 BIND dn="cn=sogo,dc=example,dc=com" method=128
slapd: conn=1003 op=0 BIND dn="cn=sogo,dc=example,dc=com" mech=SIMPLE ssf=0
slapd: conn=1003 op=0 RESULT tag=97 err=0 text=
slapd: conn=1003 op=1 SRCH base="ou=users,dc=example,dc=com" scope=2 deref=0 filter="(uid=user1)"
slapd: conn=1003 op=1 SRCH attr=*
slapd: conn=1003 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text=
slapd: conn=1004 fd=17 ACCEPT from IP=127.0.0.1:49738 (IP=127.0.0.1:389)
slapd: conn=1004 op=0 BIND dn="cn=sogo,dc=example,dc=com" method=128
slapd: conn=1004 op=0 BIND dn="cn=sogo,dc=example,dc=com" mech=SIMPLE ssf=0
slapd: conn=1004 op=0 RESULT tag=97 err=0 text=
slapd: conn=1004 op=1 SRCH base="ou=users,dc=example,dc=com" scope=2 deref=0 filter="(uid=user2)"
slapd: conn=1004 op=1 SRCH attr=*
slapd: conn=1004 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text=
slapd: conn=1005 fd=18 ACCEPT from IP=127.0.0.1:49742 (IP=127.0.0.1:389)
slapd: conn=1005 op=0 BIND dn="cn=sogo,dc=example,dc=com" method=128
slapd: conn=1005 op=0 BIND dn="cn=sogo,dc=example,dc=com" mech=SIMPLE ssf=0
slapd: conn=1005 op=0 RESULT tag=97 err=0 text=
slapd: conn=1005 op=1 SRCH base="ou=users,dc=example,dc=com" scope=2 deref=0 filter="(uid=user3)"
slapd: conn=1005 op=1 SRCH attr=*
slapd: conn=1005 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text=
slapd: conn=1003 op=2 UNBIND
slapd: conn=1003 fd=16 closed
slapd: conn=1004 op=2 UNBIND
slapd: conn=1004 fd=17 closed
slapd: conn=1005 op=2 UNBIND
slapd: conn=1005 fd=18 closed
[…]

We observe a huge negative impact on performance due to this naive implementation. SOGo should reuse an existing connection to the LDAP server when performing multiple search operations.