Przeprowadziłem podstawowe testy wydajności zasobów udostępnianych przez mechanizmy glusterfs. Dane rozproszone były na 3 dyskach SSD (rpi4, 2xdell5070), sieć Gigabit LAN.
Test 1 z wykorzystaniem narzędzia dd wykazał 3x wolniejszy transfer na udziale glusterfs w stosunku do dysku. W sumie to trochę mnie to zaskoczyło – myślałem, że przez sieć Gigabit będzie lepsza wydajność. Sprawdziłem też transfer przez scp. Najwolniejszym węzłem w klastrze jest rpi4 (transfer przez scp jest porównywalny do tego przez udziały glusterfs).
dd if=/dev/zero of=/mnt/glusterfs/temp oflag=direct bs=128k count=8k status=progress
skopiowane 1058799616 bajtów (1,1 GB, 1010 MiB), 35 s, 30,5 MB/s
8192+0 przeczytanych rekordów
8192+0 zapisanych rekordów
skopiowane 1073741824 bajtów (1,1 GB, 1,0 GiB), 34,9696 s, 30,7 MB/s
dd if=/dev/zero of=/tmp/temp oflag=direct bs=128k count=8k status=progress
skopiowane 1012531200 bajtów (1,0 GB, 966 MiB), 11 s, 92,0 MB/s
8192+0 przeczytanych rekordów
8192+0 zapisanych rekordów
skopiowane 1073741824 bajtów (1,1 GB, 1,0 GiB), 11,9018 s, 90,2 MB/s
W teście 2 w Docker Swarm uruchomiłem service wordpress+mysql na udziałach glusterfs. Wyniki jeszcze bardziej mnie zaskoczyły strony odświeżały się z wielki opóźnieniem od 3-5 sek. Przy takich opóźnieniach niestety nie jest to rozwiązanie, które nadaje się do stosowania w takim układzie.