W teorii system Koha powinien d ziałać na każdej platform ie serw ero wej, na której działa Unix/Linux i dla której dostępne są (tzn. dają się skom pi lować oraz funkcjonują prawidłowo) w cześniej wym ienione podstawowe kom ponenty program owe system u. W praktyce, analogicznie do wcześniej omówionych zagad nień dotyczących system u operacyjnego, niestandardo we w ersje sprzętu w charakterze se rw era Koha nie są za lecan e . W szczegól ności na nietypowych platform ach sprzętowych (o architekturze C PU odbie gającej fundam entalnie od IA -3 2 /x8 6 -6 4 /A M D 6 4 ) m ożna się spodziew ać określonych trudności w ynikających m.in. z innego e n d ia n n ess2. O ile można z dużym praw dopodobieństwem liczyć na to, że sam interpreter Perla (plus dys trybuow ane w ra z z nim tzw. core m o d ules) będzie działać bezproblem owo, to in ne w ym ag ane przez Koha moduły Perla z CPAN w w aria n tach XS (tj. kompilowal- ne częściowo z języka C) - ju ż niekoniecznie.
W yjściow e w ym ag an ia system u Koha w zakresie w ydajności se rw era , ilości pa mięci RAM , niezbędnego m iejsca na dysku itp. są raczej m inim alne (przynajm niej teoretycznie). Konkretne, realne w ym ag a n ia uzależnione są w za sad n iczy sposób od wielkości i charakteru biblioteki w d ra ża ją ce j. W szczególności od takich kwestii ja k : wielkość zbiorów (liczba opisów bibliograficznych i rekordów K H W w bazie), liczba obsługiwanych użytkowników, oraz od przewidywanego obciążenia poszcze gólnych modułów i silnika w yszukiw aw czego (średniego obciążenia, a także sza cowanego „szczytowego" obciążenia w dających się przewidzieć okresach w zm o żonego ruchu, charakterystyczneg o m .in. dla bibliotek akadem ickich, w których obciążenie system u przez 2 -3 określone m iesiące w roku może być naw et o rząd wielkości większe niż średnia z całego roku).
Poniżej przedstaw ione zostały w zarysie dwie przykładowe konfiguracje serw e ra Koha („m inim alna rozsądna" i „kom fortowa, o ptym alna"), które rozw ażane były z m yślą o wdrożeniu tego system u w Bibliotece PK:
• c a se stu d y (Biblioteka PK): około 130 tys. opisów, 90 tys. rekordów KHW ,
3 0 0 tys. rekordów egzem plarzy, 30 tys. rekordów użytkowników (aktyw nych około 4 0 - 5 0 % ),
• konfiguracja system u: sam system (serw er W W W + skryp ty Perla), baza M YSQ L oraz silnik w yszukiw aw czy d ziałające na pojedynczym (tym s a mym) fizycznym serw erze,
• rozm iar danych po m igracji ze starego system u - baza M ySQ L: oko ło 2.5 GB (+ 1 GB pliki ib logfile* InnoDB); spodziew any przyrost rzę du 1 -1 .5 G B rocznie (zależnie od tego, ja k ie dane archiw aln e i ja k dale ko w stecz sięg ające za m ie rzam y przechow yw ać, oraz na jak im poziomie szczegółowości skonfigurowane je s t logowanie zdarzeń); indeksy Zebry: 4 .5 G B,
• „m inim aln a rozsądna" konfiguracja (w rozum ieniu: taka, na jak ie j dałoby się pracow ać, ale niekoniecznie płynnie/kom fortowo w okresie w zm ożone go ruchu): 2 4 - 3 2 G B RAM ; procesor(y): 6 - 8 rdzeni, 2.0+ G H z,
• „kom fortowa, optym alna" konfiguracja (z uwzględnieniem pewnego za p a su na przyszłość, rzędu 3 0 % ): 4 8 - 6 4 G B RAM , C PU 8 - 1 0 rdzeni / 2 x 4 - 6 rdzeni, 2.4+ G H z; kontroler dysków z w łasn ą, podtrzym yw aną bateryjnie p am ięcią cache 1 GB+ (i/lub dyski SSD).
M ożna zauw ażyć, że konfiguracja określona powyżej jako „kom fortowa, opty m alna" zaw iera stosunkowo dużą ilość pam ięci RAM (naw et do 50% w iększą niż w niektórych przykładowych oszacow aniach dla bibliotek o zbliżonej wielkości i po dobnym charakterze, ja k ie m ożna zn aleźć w Internecie, na stronach społeczności Koha itp.). Je st to pochodna testów obciążeniowych i w ydajnościow ych przepro w adzanych przez Bibliotekę PK przed w drożeniem , z których wnioski (w pewnym uproszczeniu) w skazyw ały na to, że ilość RAM je st czynnikiem m ającym w prakty ce najw iększy wpływ na szybkość, płynność działania i czas reakcji system u, zw łasz cza pod średnim i dużym o bciążeniem . Testy te w yp ad ały zdecydow anie bardziej za d o w alająco w sytuacjach , kiedy za p as dostępnej wolnej pam ięci RAM był w y sta rcza jąco duży na to, aby w szystkie pliki sam ego system u (1 G B), pliki Zebry (4.5 G B), pam ięć przew idziana dla szeroko pojętej obsługi bazy danych (2 x 2.5 GB + 1.5 G B + 1 G B + 1 G B), we w szystkich przewidywalnych okolicznościach mogły w m iarę możliwości rezydow ać w pam ięci cache (buforach zapisu/odczytu) syste mu operacyjnego. Innymi słowy, im rzadziej zachodziła konieczność odwoływania się do danych przechow yw anych na fizycznych dyskach, tym w yraźnie lepsze były efekty testów obciążeniow ych.
4 .2 . Kom putery pracow ników i stanow iska O PA C
W y m a g a n ia sprzętowe i program owe po stronie użytkownika (tj. w rozw aża nym przypadku dotyczące de facto p rzeglądarek W W W , w ykorzystyw anych na kom puterach pracowników oraz na stanow iskach O PAC ) nie są dla system u Ko ha zbyt w ygórow ane. W a rto jed n ak, zw łaszcza przy szacow aniu niezbędnych na kładów na sprzęt przed w drożeniem system u, w ziąć pod uwagę m.in. następują ce kwestie:
• interfejs bibliotekarza: jako stacje robocze zalecan e są kom putery z zain sta lo w an ą „typową" p rzeg ląd arką W W W (Firefox, C hrom e, IE 9.0+) w moż
liwie aktualnej w ersji,
• system operacyjny: obojętnie ja k i, liczy się w ersja przeglądarki i jej zgod ność ze stan d ard am i W 3 C ,
• szybkość działan ia, ilość pam ięci RAM : Koha po stronie klienta dość inten syw nie korzysta m.in. z rozm aitych funkcji i bibliotek Ja v a sc rip t (JQ u ery + D ataTab les), stąd strony W W W , które system generuje, mogą być miej scam i dość „ciężkie" - na słabych kom puterach takie strony się w praw dzie prędzej bądź później w czytają i w yśw ietlą, ale ju ż np. filtrow anie, stronico w anie i sortow anie wyników w tabelach generowanych przy pomocy D a ta Tables może działać niezbyt zad o w alająco ,
• istotna je s t również rozdzielczość ekranów (ew. konieczność przewijania stron w przeglądarce, zw łaszcza w poziomie, zn acząco w pływ a na kom fo rt pracy) - dobrze, aby były to m onitory o rozdzielczości co najm niej
1 6 8 0 x 1 0 5 0 (W SXGA+), w szczególności w oddziale udostępniania, • stanow iska O PA C : w ym ag a n ia co do w ydajności urządzeń oraz zgodno
ści p rzeglądarek W W W ze stan d ard am i są zdecydow anie łagodniejsze niż dla stacji roboczych; w obecnej w ersji Koha, O PA C funkcjonuje w oparciu o fram ew o rk Bootstrap - fram ew o rk ten kładzie duży nacisk na zgodność z m ożliwie ja k n ajw iększą liczbą rozm aitych w ersji przeg ląd arek i w aria n tów urządzeń klienckich, tradycyjnych czy mobilnych, i nieźle się spraw dza w praktyce w zasto sow an iach, w których rozrzut param etrów sprzętowych czy w ersji przeglądarek W W W bywa stosunkowo duży,
• czytelnicy u żyw ający p rzeglądarek W W W z w yłączonym Ja va S crip t i/lub zablokow aną obsługą „ciasteczek" m ogą (w najlepszym razie) korzystać z system u jedynie w bardzo ograniczonym zakresie.