Transcript Shamardin

LCG/gLite BDII performance measurements
Lev Shamardin
[email protected]
Scobeltsyn Institute of Nuclear Physics, Moscow State University
What is BDII really?

OpenLDAP with LDBM backend

Three running servers with role rotation:
Lev Shamardin

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
2
BDII users


Lev Shamardin
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.
3
lfc utilities


Typcal query:

(GlueSEUniqueID=<se_name>)

(&(GlueServiceURI=*<hostname>*)
(GlueServiceType=srm_v1))
Results:

Lev Shamardin
Several rows for each query
4
WMS cache update

Typcal query:


Results:

Lev Shamardin
(|(objectClass=gluevoview)
(|(objectClass=gluecesebind)
(|(objectClass=gluece)
(|(objectClass=gluecluster)
(objectClass=gluesubcluster)))))
Huge dump of grid resources, ~15-20 Mbytes.
5
Testing method




Lev Shamardin
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 memoryhungry, so written in C with openldap-client
6
SE search queries
There is almost no
dependence of the
response time from the
number of sequential
queries
Lev Shamardin
7
SE search queries (2)
Lev Shamardin
8
SE search queries (3)
Lev Shamardin
9
WMS queries
Lev Shamardin
10
WMS queries (2)
Lev Shamardin
11
Conclusion



Lev Shamardin
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.
12
Conclusion (2)

Numbers for the modeling (next talk).

Net::LDAP is very slow.
Lev Shamardin
13
Acknowledgements

Lev Shamardin
The research was partially supported by

INTAS-CERN Grant 2005-7509

RFBR Grant 06-07-89199
14