LCG/gLite BDII performance measurements

1

• LCG/gLite BDII performance measurements
• Lev Shamardin
• shamardin_at_theory.sinp.msu.ru
• Scobeltsyn Institute of Nuclear Physics, Moscow
  State University

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
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
lfc utilities

• Typcal query
• (GlueSEUniqueIDltse_namegt)
• ((GlueServiceURIlthostnamegt)
  (GlueServiceTypesrm_v1))
• Results
• Several rows for each query

5
WMS cache update

• Typcal query
• ((objectClassgluevoview) ((objectClassgluece
  sebind) ((objectClassgluece)
  ((objectClassgluecluster)
  (objectClassgluesubcluster)))))
• Results
• Huge dump of grid resources, 15-20 Mbytes.

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 NetLDAP
  appeared to be amazingly slow and memory-hungry,
  so written in C with openldap-client libs.

7
SE search queries
There is almost no dependence of the response
time from the number of sequential queries
8
SE search queries (2)
9
SE search queries (3)
10
WMS queries
11
WMS queries (2)
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 gt1000 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
Conclusion (2)

• Numbers for the modeling (next talk).
• NetLDAP is very slow.

14
Acknowledgements

• The research was partially supported by
• INTAS-CERN Grant 2005-7509
• RFBR Grant 06-07-89199