1. LCG/gLite BDII performance measurements Lev Shamardin shamardin@theory.sinp.msu.ru Scobeltsyn Institute of Nuclear Physics, Moscow State University

2. Lev Shamardin 2 What is BDII really? OpenLDAP with LDBM backend Three running servers with role rotation:  One is updated every minute with a set of processed ldapsearch results from any grid site.  One is used to serve the requests via a port forwarding proxy  One is setteling down

3. Lev Shamardin 3 BDII users Primary users:  lfc-* utilities looking for storage elements  Resource Brokers updating grid information cache Some other grid utilities, but these are much less popular then the first two.

4. Lev Shamardin 4 lfc utilities Typcal query:  (GlueSEUniqueID= )  (&(GlueServiceURI=* *) (GlueServiceType=srm_v1)) Results:  Several rows for each query

5. Lev Shamardin 5 WMS cache update Typcal query:  (|(objectClass=gluevoview) (|(objectClass=gluecesebind) (|(objectClass=gluece) (|(objectClass=gluecluster) (objectClass=gluesubcluster))))) Results:  Huge dump of grid resources, ~15-20 Mbytes.

6. Lev Shamardin 6 Testing method A number of parallel quering processes, with synchronized start. Each process runs a number of query sets in a random sequence. Results from each process are collected. First implementation in perl using Net::LDAP appeared to be amazingly slow and memory- hungry, so written in C with openldap-client libs.

7. Lev Shamardin 7 SE search queries There is almost no dependence of the response time from the number of sequential queries

8. Lev Shamardin 8 SE search queries (2)

9. Lev Shamardin 9 SE search queries (3)

10. Lev Shamardin 10 WMS queries

11. Lev Shamardin 11 WMS queries (2)

12. Lev Shamardin 12 Conclusion Seems to scale linearly. Just throw in more CPUs? High loads cause connection timeouts, but our test show that „high load“ for a production BDII means >1000 simulteneous queries! Protocol and implementation are quite inefficient. Network delay for the transfer of WMS dump data is ~2 sec, so could be the response time for the sequential same queries.

13. Lev Shamardin 13 Conclusion (2) Numbers for the modeling (next talk). Net::LDAP is very slow.

14. Lev Shamardin 14 Acknowledgements The research was partially supported by  INTAS-CERN Grant 2005-7509  RFBR Grant 06-07-89199