Testowanie bazy wiedzy - Omega-PSIR

R
Ω-Ψ
Uczelniana Baza Wiedzy
Testowanie Bazy Wiedzy
Wersja 1.0
Wydział Elektroniki i Technik Informacyjnych
i Biblioteka Główna
Page
1
Politechnika Warszawska
Historia dokumentu
wersji
wersji
Opis zmian
Autor
2
Data
Page
Numer
Spis treści
1
Wprowadzenie .............................................................................................................. 4
2
Testy funkcjonalne......................................................................................................... 5
2.2
Testowanie interfejsu redaktora........................................................................................ 6
Badanie wydajności systemu repozytoryjnego ............................................................ 27
3.1
Cel badań ...................................................................................................................... 27
3.2
Narzędzia....................................................................................................................... 27
3.3
Charakterystyka ruchu portalu WEiTI ............................................................................. 27
3.4
Założenia dotyczące obciążenia .................................................................................... 28
3.5
Scenariusze testowe ...................................................................................................... 28
3.6
Wyniki badań i wnioski ................................................................................................... 29
Wnioski i dalsze kroki .................................................................................................. 32
3
4
Założenia ......................................................................................................................... 5
Page
3
2.1
1 Wprowadzenie
W okresie 01.2012-07.2012 w ramach etapu B26 realizowano prace nad zagadnieniami
związanymi z budową Repozytorium Uczelnianego. Zadanie jest realizowane przez zespół
pracowników z II, WEiTI oraz BG PW.
Prace nad uczelnianą bazą wiedzy są prowadzone przede wszystkim z zastosowaniem
wyników etapu B3, ale także etapów B11 i B12.
W raportowanym okresie skoncentrowano się na następujących zagadnieniach:
1. Metody testowania wybranych kategorii zasobów informacyjnych
2. Metody testowania wybranych elementów funkcjonalnych
3. Przeprowadzenie testów wydajnościowych
W pracach wykorzystano doświadczenia zespołu w realizacji wydziałowego repozytorium
REPO zaimplementowanego w roku 2010 dla Wydziału Elektroniki i Technik
Informacyjnych Politechniki Warszawskiej. Analiza pokazała możliwość szybkiego
zaadaptowania systemu do potrzeb uczelnianej bazy wiedzy. Dlatego też dokonano adaptacji
w systemie REPO. Zmiany te miały na tyle zasadniczy charakter, że postanowiono wyróżnić
uzyskane oprogramowanie jako system o nowej nazwie Omega.
Na niniejsze opracowanie składa się 4 rozdziałów. Rozdział 2 jest przedstawione są analizy
Page
4
funkcjonalne systemu, zaś Rozdział 3 prezentuje badania wydajnościowe systemu.
2 Testy funkcjonalne
2.1 Założenia
Do ogólnych założeń konstrukcyjnych przyjętych przy realizacji systemu zaliczyć należy tu w
szczególności:
1. Elastyczność traktowania metadanych – tak, aby możliwe było dostosowanie opisów
bibliograficznych do potrzeb istniejących już systemów, w tym w szczególności
systemu BIBLIO Biblioteki Głównej oraz bibliotek wydziałowych wykorzystujących
oprogramowanie Aleph, przy jednoczesnym umożliwieniu eksportu i importu danych
do systemów zewnętrznych (w tym w szczególności do systemu dLibra, stosowanego
przez Federację Bibliotek Cyfrowych; np. docelowy system także stanowić mógłby
element FBC);
2. Elastyczność w zakresie możliwości rozszerzania systemu, w szczególności
definiowania większości parametrów systemu bez potrzeby ingerowania w kod
systemu i przeprogramowywania go. W szczególności dotyczy to:
a. definiowania (i redefiniowania) struktur danych, oraz towarzyszących im
formularzy do wprowadzania danych, warunków integralności danych
b. definiowanie ekranów wyszukiwania dla poszczególnych typów obiektów
(i/lub grup) oraz definiowanie sposobów prezentacji wyników, sortowania, w
tym także definiowanie struktur na potrzeby eksportu danych, np. w formie
Excela, BIBTEXa, itp;
c. definiowanie reguł dostępu
d. definiowanie reguł oceny parametrycznej
Narzędzia pozwalające definiować możliwości systemu zostały zrealizowane w ten
sposób, że nie ma potrzeby wprowadzania zmian w oprogramowaniu systemu w
przypadkach zmieniających się wymagań co do systemu. Zmiany takie mogą być
przeprowadzane przez administratora systemu. Zrealizowane narzędzia są opisane w
niniejszym rozdziale w p. 3.2.
Page
przypadkach – w pełni automatycznej) weryfikacji metadanych oraz deduplikacji
5
3. Stworzenie mechanizmów półautomatycznej (lub nawet – w uzasadnionych
obiektów
składowanych
w
repozytorium,
w
tym
zastosowaniem
metod
automatycznego przetwarzania języka naturalnego i eksploracji danych;
4. Wykorzystanie otwartych formatów danych, w tym w szczególności formatu PDF/A
i/lub Pub dla dokumentów tekstowych, oraz Ogg Vorbis / Theora dla dokumentów
audiowizualnych;
5. Wykorzystanie uznanych za standardy dla bibliotek cyfrowych protokołów transmisji
danych (OAI-PMH, OAI-ORE) i organizacji meta danych (Dublin Core).
6. Elastyczna konstrukcja repozytorium, pozwalająca użytkować system w wersji
rozproszonej, jak też w wersji scentralizowanej;
W niniejszym rozdziale pokrótce omówiona zostanie architektura systemu OMEGA,
rozwiązania w zakresie przyjętych struktur danych oraz podstawowe narzędzia administratora
zrealizowane w systemie.
2.2 Testowanie interfejsu redaktora
Testy przeprowadziła M. Sadowska-Hinc, mająca doświadczenie i umiejętności związane z
pracą w Ośrodku Informacji Naukowej BG PW, ale nie przeszkolona w zakresie
oprogramowania. Wybór taki miał pomóc w ocenie trudniej uchwytnych cech, jak
intuicyjność.
Test miał dwie części: w pierwszej części chodziło o wyszukiwanie informacji, bez jej
wprowadzania, w części drugiej doszło wprowadzanie.
2.2.1
Wyszukiwanie informacji. Ocena ogólna
Page
6
1. Na etapie wyszukiwania proste i intuicyjne okienko. Jak się domyślam w okienku
Szukaj możemy wpisać dowolny element z opisu rekordu. Na co dzień tyle wystarczy,
ale może warto wprowadzić wyszukiwanie zaawansowane, gdzie będzie można
wyszukiwać w każdym z pól opisu z osobna. Na przykład będziemy chcieli szybko
stworzyć listę książek Kowalskiego z lat 2000- ale tylko z punktacją 5
2. W nawiązaniu do poprzedniego wyszukiwania mogą nas interesować tylko publikacje
z punktacją co najmniej 5
3. Literówka w słowie książki, artykuły i tłumaczenia w lewym menu
4. Warto dodać możliwość sortowania wyników w zależności od obranego kryterium,
tzn. szukam publikacji od 2000 roku, w tej chwili otrzymuje 3388. Są uszeregowane
wg pierwszego autora. Może warto dodać możliwość szeregowania wg chociażby
tytułu, roku, punktacji, wydawcy
Page
7
itp.
5. Brakuje możliwości przeskoku do konkretnej strony – można przesuwać się tylko
suwakiem, co w przypadku 200 stron jest bardzo niewygodne.
6. Przydałaby się możliwość ustawienia – każdy użytkownik sam wybiera ile rekordów
wyświetla się na stronie np. 20 czy 50
7. Dodatkowo jak przejdę suwakiem do danej strony, wejdę np. w Info lub Pokaż a
następnie wycofam się do strony poprzedniej to system wraca na pierwszy ekran.
Jest to bardzo niewygodne bo ponownie muszę przedzierać się do wybranej strony.
8. Po najechaniu na autora w Info otrzymuję tylko informacje o Instytucie, ale bez
nazwy wydziału (domyślam się że to będzie dodane).
Page
8
9. W przypadku osób z innych placówek może lepiej dopisać informację np. osoba z
zewnątrz czy spoza uczelni, zamiast kreski. Kreska wprowadza wahanie, czy znaczy
brak danych, błąd osoby wprowadzającej czy właśnie afiliację zewnętrzną.
10. Czym różni się Gość od Osoby z zewnątrz? (brak tutaj polskich liter w słowie gość i
zewnątrz)
Page
9
11. Odnośnie powyższego zrzutu – czy nie lepiej zamienić Dyplomant na Student? Może
zdarzyć się, że coś opublikuje.
12. Literówka powyżej – Imie na Imię , a po Akronim jednostki organizacyjnej spacja i
dopiero nawias
13. W doktoratach – domyślam się że akronim PE dotyczy zakładu, ale dla osoby
niezwiązanej z wydziałem to taki akronim nic nie mówi – może gdzieś obok powinien
być wykaz.
14. Szkoda że tekst streszczenia nie rozciąga się na cały ekran – pewnie zależy to od
monitora,
Page
10
15. Dlaczego jak w Doktoratach wpisałam Arabas Jarosław to otrzymuje 5 pozycji z czego
w dwóch widzę, że wpisany pracownik był promotorem i autorem pracy doktorskiej,
a pozostałe jak są powiązane z zapytaniem?
16. W przypadku afiliacji wygodniej by było wybrać wydział i od razu przejść do jego
publikacji – lub zakład i do jego publikacji. Teraz trzeba w tym celu wejść jeden krok
dalej do Info.
17. Po wejściu w wydział w Info system bardzo długo szuka danych do pola Liczba wersji
danego rekordu (sprawdzałam dla WEiTI)
Page
11
18. Dlaczego po wpisaniu nazwiska Rybinski w Autorzy i pracownicy system wyświetla 5
rekordów, w dodatku właściwa osoba jest na końcu (rozumiem że alfabetycznie); ale
nie intuicyjnie.
Page
12
19. Jeżeli te pozostałe osoby wymienione powyżej to doktoranci profesora, to powinni to
być gdzieś wskazane. (patrz wyżej)
Page
13
20. Wg jakiego klucza uszeregowani zostali autorzy instytucjonalni?
Page
14
21. Wg jakiego klucza uszeregowano konferencje?
22. Jak szeregować tytuły czasopism – czy brać pod uwagę rodzajniki, np. ‘the’?; ja bym
wolała bez, przykład jak jest obecnie poniżej (The Anatolian Journal of Cardiology)
Page
15
23. Przydała by się możliwość zawężania do dokumentów, do których dołączono pełny
tekst w PDF.
24. W jaki sposób ustalane są nazwy klików PDF?
25. Czy jest jakaś możliwość wyeksportowania uzyskanych rezultatów do innych
programów, czy to już będzie w interfejsie zwykłego użytkownika?
26. Do czego służy zaznacz/odznacz wszystko – próbuję zaznaczyć ale nie widzę różnicy?
Page
28. „Nazwa algorytmów punktujących”? Domyślam się co to znaczy ale skomplikowane
sformułowanie
16
27. Czy jest możliwość wprowadzenia pracy, w której redaktorem jest nasz pracownik i
dodatkowo nasi pracownicy są też redaktorami? Czy rolę autora można ustawić tylko
albo tak albo tak?
Page
17
29. Wygodniej by było, żeby przy każdym polu do wprowadzania danych były dwa zdania
co i jak tam wpisać, szczególnie jeżeli dużo osób będzie uzupełniać dane.
30. book.field ? Co to znaczy?
2.2.2
Wprowadzanie danych
Page
18
1. Wprowadziłam pierwszą z brzegu książkę, pt. Vademecum organizacji europejskich –
dwa rekordy do usunięcia id - WUT13442 i WUT13443. Po zakończeniu edycji
połączyłam oba rekordy wybierając jeden poprawny – wiodący.
Page
b) Przy wprowadzaniu danych do pola Autor próbowałam wprowadzić jako redaktora
osobę z PW, a następnie zmieniłam rolę na Autor, jako autora dodałam kolejną osobę
z PW. W trakcie wprowadzania danych nie widzę, czy dobrze oznaczyłam role.
19
a) Przy wprowadzaniu danych brakowało mi instrukcji, a nie byłam przeszkolona w tym
zakresie stąd zapewne wiele wątpliwości. Nie zajmuję się w Bibliotece opracowaniem
dlatego nie jest dla mnie oczywiste jakiego typu danych oczekuje się w
poszczególnych polach.
Po zapisaniu rekordu wydaje się że system pozwala albo tylko wprowadzić
redaktorów albo tylko autorów. Rolę wybiera się raz. Nie ma możliwości
wprowadzenia w jednym rekordzie obu tych ról.
c) Brakuje możliwości zapisania wersji roboczej rekordu. Chciałam na chwilę zawiesić
wprowadzanie danych, a następnie powrócić do rekordu ale nie został zapisany,
ponieważ w roboczym opisie były elementy niepoprawne.
d) Może zamiast „Adres wydawcy” – „Miejsce wydania”
e) Może zamiast „Paginacja” – Strony lub ewentualnie Liczba stron, chociaż w
artykułach będzie do zakres stron
f) Może zamiast Pick file – Wybierz plik
g) Dodałam okładkę książki – Czy nazwa pliku może być dowolna? Ja nazwy nie
zmieniłam, dodałam domyślną, nadaną przez księgarnie internetową - Vademecumorganizacji-europejskich_J-Gajewski,images,6,83-87545-50-3.jpg
h) Obiekt dodany w polu Plik - to pewnie np. pełny tekst dokumentu o ile jest dostępny?
i) Czy lepiej pozostawić „Data wydania”, czy po prostu „Rok” lub ewentualnie Rok
wydania
20
Po zapisaniu rekordu i odszukaniu go – w wierszu wprowadzonego przeze mnie
rekordu pojawia się nieco więcej funkcji, niż w przypadku pozostałych rekordów. Nie
Page
j)
wiem dlaczego?
k) wprowadziłam drugi rekord – tą samą książkę ale z nieco zmienionym opisem. Bez
problemu połączyłam oba rekordy wybierając jeden wiodący.
Page
21
l) wprowadziłam dowolny artykuł z czasopisma, do usunięcia - id WUT13451. Czy w
zakładce „Opis” nie przydałaby się funkcja sprawdzania, która koryguje lub zwraca
uwagę na to czy słowa kluczowe są rozdzielone tym samym znakiem interpunkcyjnym
– ja wprowadziłam i średnik i przecinek i obie formy zostały przyjęte. Może w tej
chwili nie jest to istotne ale w przypadku automatycznej konwersji danych do innego
programu, może okazać się ważne.
Page
22
m) Dlaczego przy dodawaniu tłumaczeń niektóre pola są oznaczone gwiazdką, a w
przypadku wprowadzania książek i artykułów nie ma takich oznaczeń? Podobnie w
zakładce Projekty
n) Czy taki podział na rodzaje książek jest zawsze wystarczający? – tzn. Monografia,
Podręcznik akademicki, Skrypt. Pewnie wynika to z przydzielanej punktacji, ale mogą
zdarzyć się takie publikacje jak tablice dziedzinowe, encyklopedie, słowniki –
pracownik może być chociażby redaktorem.... ? Jak je klasyfikujemy?
Page
23
o) W zakładce Tłumaczenia kilka pól do przetłumaczenia, np. translation.URL,
translation.journal, translation.field
Funkcje Redaktorskie.
p) Czy powinno być Nazwisko edytora czy Nazwisko redaktora?
q) Najpierw zaznacza się Redakcja Czasopisma, Redakcja wydania specjalnego
czasopisma lub Redakcja serii książkowej a później pojawia się pole o nazwie
„Czasopismo”???
r) W opisie „Funkcji redaktorskich” dwa razy pojawiają się pola punktacji – czy to
oznacza, że stosuje się dwie punktacje – jedna odnosi się do tytułu, a druga do osoby?
Page
24
s) Czy dane w polu „Funkcja” nie powinny być w jakiś sposób ujednolicone, pobierane
z listy? W jednym z rekordów ktoś podał Funkcja: red., a w innych jest poprawniej
np. Senior Editor
t) Brakuje możliwości przechodzenia do kolejnych rekordów za pomocą np. Następny.
Po wejściu w Pokaż lub w Info mogę tylko powrócić do zbiorczej tabelki, a nie mogę
przejść bezpośrednio do kolejnej pozycji z tabeli.
2.2.3
Funkcje pomocnicze
Brak polskich znaków lub tłumaczenia w różnych miejscach, np. Afiliacja nadrzedna, Imie,
Page
25
Pokoj, authorprofile.field, journalseries.type, Typy projektow
Page
26
3 Badanie wydajności systemu repozytoryjnego
3.1 Cel badań
Celem badań było oznaczenie czasów odpowiedzi systemu w zależności od liczby
równoległych użytkowników a także wskazanie komponentów systemu które należy
niezwłocznie lub w przyszłości zaktualizować w celu poprawy wydajności. Badania związane
są z przeniesieniem instalacji repozytorium z poziomu wydziałowego na poziom uczelniany.
3.2 Narzędzia
Testy
obciążeniowe
zostały
przeprowadzone
z
użyciem
narzędzia
JMeter
(http://jmeter.apache.org/) które umożliwia min:





nagrywanie scenariuszy testowych na podstawie aktywności użytkownika, przez podłączenie
do przeglądarki internetowej
parametryzację scenariuszy testowych z użyciem zewnętrznych źródeł danych
uruchamianie scenariuszy testowych w sposób równoległy dla wielu symulowanych
użytkowników
uruchamianie testów rozproszonych
raportowanie
Badanie wąskich gardeł zostało zrealizowane przy użyciu wtyczki Java Monitor dla
środowiska Eclipse.
3.3 Charakterystyka ruchu portalu WEiTI
Maksymalna odnotowana liczba odsłon portalu WEITI w ciągu doby wynosi 20000 przy
4000 użytkownikach. Maksymalna liczba odsłon w ciągu godziny wynosi 1356 przy 359
użytkownikach. Średni czas trwania sesji użytkownika wynosi 5 min. Daje to w przybliżeniu
Page
27
6 użytkowników w ciągu minuty i 23 odsłony w ciągu minuty.
3.4 Założenia dotyczące obciążenia
Statystyki przytoczone dotyczą całego portalu. Ruch w obrębie repozytorium to na razie
około 5 promili całego ruchu wydziałowego. Zakładać należy jednak iż przyjęcie jako
wartości odniesienia ruchu dla całego wydziału będzie gwarantować bezpieczną ocenę
zdolności systemu do udźwignięcia ruchu całej uczelni w zakresie świadczenia dostępu do
repozytorium.
Środowisko testowe
Pamięć RAM: 8GB
Dysk twardy: 160GB
Procesor: 4-rdzeniowy 2666 Mhz
3.5 Scenariusze testowe
Do badań zostały wybrane dwa scenariusze testowe, bazujące na zrachowaniach edytorów i
gości portalu.
Scenariusz 1. Scenariusz polega na wyszukiwaniu w pełnej bazie publikacji za pomocą
wyszukiwania pełno tekstowego przez użytkownika niezalogowanego. Jest to możliwie
najbardziej czasochłonny proces realizowany przez system ze względu na konieczność
przeszukania wszystkich rekordów, wszystkich typów, w tym po treści dokumentów.
W bazie danych w chwili testów występowało około 10 tys. publikacji.
Frazy zapytań zostały przygotowane tak, by zbadać zależność prędkości od liczby
zwracanych wyników, a także by każdy wątek mógł operować na różnej frazie, co
minimalizuje wpływ mechanizmów cache’owania bazy danych i silnika indeksowania na
obserwowalną wydajność systemu.
Scenariusz 2. Scenariusz ten odzwierciedla pracę edytora. Polega na uwierzytelnieniu się w
systemie autoryzacji CAS, przejścia do ekranu artykułów – wyszukania autora z pomocą
Page
28
automatycznego podpowiadania. Wyszukiwanie właściwe. Scenariusz ten jest mniej istotny,
gdyż ruch w sekcji dla zalogowanych edytorów powinien być istotnie niższy niż publiczny
dostęp do repozytorium.
3.6 Wyniki badań i wnioski
3.6.1
Badanie czasu odpowiedzi
Eksperyment 1: Badanie czasu odpowiedzi przy obciążeniach zbliżonych i kilkukrotnie je
przekraczających. Czas uruchomiania wątków: 60s, każdy wątek zadaje inne zapytanie inne
niż „pokaż wszystkie”. (wg scenariusza 1)
l.
Łączna
użytkowników liczba
odsłon
25
100
25
100
Czas
minimalny
odpowiedzi
[ms]
200
83
Czas średni Czas
odpowiedzi maksymalny
[ms]
odpowiedzi
[ms]
810
2300
835
5562
Wniosek: wyniki pokazują iż przy założonym ruchu i kilkukrotnie go przekraczającym
system jest w stanie reagować w czasie umożliwiającym użytkownikom wygodną pracę
3.6.2
Badanie wpływu mechanizmu „cache”
Eksperyment 2: Badanie wpływu mechanizmów „cache”. Czas uruchomiania wątków: 60s,
100 użytkowników, każdy zadaje jedno pytanie inne niż „pokaż wszystkie” (wg scenariusza
1)
Nr
Czas
uruchomienia minimalny
odpowiedzi
[ms]
Pierwsze
83
uruchomienie
Kolejne
79
uruchomienia
Czas średni Czas
odpowiedzi maksymalny
[ms]
odpowiedzi
[ms]
835
5562
179
454
Wniosek: wyniki pokazują duże znaczenie mechanizmów cache’u, które działają nawet przy
Page
29
wielu różnych zapytaniach generowanych przez użytkowników.
3.6.3
Badanie zachowania systemu przy przeciążeniach
Eksperyment 3: Badanie zachowania systemu przy przeciążeniach (wg scenariusza 1)
l.
Łączna
użytkowników liczba
odsłon
100
1000
1000
1000
Czas
minimalny
odpowiedzi
[ms]
83
25
Czas średni Czas
odpowiedzi maksymalny
[ms]
odpowiedzi
[ms]
6401
73251
67000
301000
% błędnych
odpowiedzi
(np.
timeout)
0%
50%
Wniosek: system reaguje w rozsądnym czasie przy 1000 odsłonach na minutę pod warunkiem
iż żądania nie pochodzą od 1000 różnych użytkowników. Wykres skalowania w zależności od
ilości odwołań prezentowany jest poniżej. W drugim przypadku system odrzuca połączenia.
Jest to spowodowane tym iż każda sesja musi być zarządzana przez serwer przez 30 min od
pierwszego zgłoszenia, co powodowałoby ataki typu DOS. Przed taką sytuacją chroni
konfiguracja serwera. Zwiększenie parametrów serwera jest możliwe, ale dodatkowe prace
Na podstawie czasów odpowiedzi można zaobserwować, że zablokowanie serwera musiałoby wystąpić.
Page
1
30
musiałby być wykonane (np. skracanie czasu sesji) celem uniknięcia zatkania serwera1.
3.6.4
Badanie wydajności interfejsu edytora
Eksperyment 4: Badanie wydajności interfejsu edytora dla różnych czynności (wg
scenariusza 2). Liczba użytkowników: 100.
Optymalizacje:
W trakcie prac dokonano 5-krotnego przyspieszenia działania systemu dzięki korekcie
mechanizmu sortowania, a prezentowane wyniki odzwierciedlają stan po wykonanej
optymalizacji. Zidentyfikowano dodatkowy czynnik, którego wyeliminowanie może
przynieść dodatkową kilkukrotną poprawę. Ze względu na satysfakcjonujące wyniki –
Page
31
optymalizacja ta nie została na razie zaimplementowana.
4 Wnioski i dalsze kroki
Od testów minęło ponad rok. Usterki funkcjonalne są usuwane na bieżąco. Ze względu na
ciągły rozwój systemu istnieje konieczność jego ciągłego testowania zwłaszcza w okresach
zmiany wersji. Od momentu realizacji opisanych tu testów – dokonane zostały liczne
optymalizacje podnoszące wydajność systemu takie jak odchudzenie sesji użytkownika,
poprawa mechanizmów sortowania, skrócenie czasu sesji dla użytkowników zewnętrznych i
wiele innych. Niezbędny będzie dalszy monitoring pracy systemu w miarę zwiększania liczby
użytkowników zewnętrznych. Spodziewać się można iż liczba użytkowników wewnętrznych
PW zostanie zwiększona nieznacznie w stosunku do możliwości systemu. Istnieje jednak
możliwość, iż ruch generowany z wyszukiwarek może rosnąć w miarę zwiększania się liczby
zasobów udostępnianych przez repozytorium. W tym kontekście kluczowe jest zapewnienie
jakości pracy użytkownikom PW w szczególności w okresach sprawozdawczych, tak aby
nasilony ruch z zewnątrz obniżał czasy odpowiedzi dla użytkowników z zewnątrz, zaś dla
Page
32
użytkowników wewnętrznych pozostawał na niezmienionym poziomie.