Powolne połączenie z serwerem poczty

01mail server sync

Artykuł ten jest podyktowany jednym z problemów jakie zgłosił użytkownik na GitHub [https://github.com/YetiForceCompany/YetiForceCRM/issues/318]. Przez ostatnie kilka miesięcy mieliśmy kilku klientów, którzy optymalizowali system YetiForce do granic możliwości, dlatego pewne zależności byliśmy zmuszeni rozłożyć na części pierwsze. Opis poniżej jest efektem doświadczenia we wdrażaniu systemu w dużych firmach, mam nadzieje, że pomoże on wielu innym firmom.

Problem

Zapewne często spotykacie się z sytuacją, w której używając aplikacji Outlook, Thunderbird lub innego klienta pocztowego działającego offline, komunikacja wydaje się działać prawidłowo (nie widać żadnego spowolnienia w działaniu aplikacji). W przypadku Roundcube (czyli domyślnie wbudowanego klienta pocztowego w YetiForce) sytuacja jest odmienna, ponieważ aplikacja ta nie działa offline tylko online.

W Outlook sytuacja wygląda następująco: mail pobrany z serwera pozostaje zapisany lokalnie w Outlooku, każde wejście w pobranego maila lub jego wyszukiwanie odbywa się w ramach Outlooka i nie ma nic wspólnego z serwerem poczty. Każde łączenie się z serwerem służy tylko w celu synchronizacji i pobraniu niepobranych elementów. W wielu sytuacjach mechanizm taki jest optymalny, ponieważ nie obciąża on ani serwera ani łącz internetowych. Rozwiązanie takie ma też swoje minusy, lecz nie będzie to przedmiotem tego artykułu, ponieważ punkt widzenia zależy od punktu siedzenia :].

Zupełnie odmiennie wygląda sytuacja w przypadku Roundcube. W tym przypadku każde odświeżenie klienta pocztowego powoduje komunikacje z serwerem poczty. Jeżeli przeglądasz kolejno wiadomości mailowe, to przy każdym podglądzie maila są pobierane dane z serwera. Główną zaletą takiego rozwiązania jest praca w czasie rzeczywistym. Jeżeli usuniemy coś na jednym urządzeniu np. w telefonie, możemy być pewni, że przy kolejnym odświeżeniu strony element nie będzie już widoczny w interfejsie klienta pocztowego. Najważniejszą zaletą Roundcube jest brak konieczności instalowania czegokolwiek po stronie użytkownika (wystarczy przeglądarka WWW), a największą wadą tego rozwiązania jest brak dostępu do maili, gdy nie mamy dostępu do internetu [oczywiście i temu można zaradzić].

Testowanie

Ale jaki ma to związek z prędkością działania poczty? Największy problem stanowią sprzętowe serwery poczty lub mało wydajne serwery pocztowe na współdzielonych hostingach. W rzeczywistości takie serwery pocztowe są mało wydajne i przy dużej ilości odpytań zaczynają bardzo spowalniać. Można to w bardzo prosty sposób przetestować, jeżeli korzystacie z takiego rozwiązania, to niech wszyscy pracownicy w swoim programie pocztowym w tym samym czasie odbierają i wysyłają wiele wiadomości mailowych, tak aby każdy pracownik maksymalnie co 3-5 sekund łączył się z serwerem. Taki prosty eksperyment pozwoli nam zaobserwować znaczne spowolnienie serwera. Najprawdopodobniej zachowanie takie będzie można zaobserwować na urządzeniach typu NAS, gdzie producent próbuje upchnąć wiele funkcjonalności w serwerze o niskich parametrach wydajnościowych.

Jeżeli eksperyment powyżej się nie powiedzie, proponujemy rozwiązanie drugie. Należy włączyć debugowanie w Roundcube, tak aby śledzić każde zapytanie wysyłane do serwera i czas po jakim uzyskuje się odpowiedź, jeżeli przy korzystaniu z Roundcube odpowiedzi od serwera są coraz wyższe, oznacza to, że serwer ten się nie wyrabia. Najczęściej będą one stanowiły ponad 90% czasu ładowania całego CRM. 

Przy okazji własnych doświadczeń i testów, domyślnie ustawiliśmy Roundcube tak, aby pracował możliwie najszybciej, zgodnie z zaleceniami producenta, jeżeli uznasz za słuszne, to konfiguracje tą możesz zmodyfikować pod wymagania własnej firmy, rozwiązania open source nie ograniczają, dają wiele możliwości i wiele dróg.

Rozwiązanie

Tutaj nie mam niestety dobrych wiadomości, ponieważ problem wynika z założeń na jakich jest oparty Roundcube i korzystając z tego rozwiązania, należy dopasować sobie odpowiednie środowisko, które pracuje wydajnie i jest zoptymalizowane. W praktyce nie ma znaczenia, czy serwer aplikacji i serwer poczty są na tym samym serwerze, czy też są na dwóch różnych serwerach fizycznych, czy też serwer aplikacji jest na serwerze fizycznym, a serwer pocztowy na serwerze wirtualnym, istotna jest optymalna komunikacja i odpowiednio zoptymalizowane serwery. W przypadku, gdy aplikacja i serwery poczty są na tym samym serwerze to rozwiązanie, to jest najszybsze i wydajniejsze o 10-30% w porównaniu do dwóch pozostałych rozwiązań, jednakże czas odpowiedzi to czas wynoszący ułamki sekundy, więc dla zwykłego użytkownika nie będzie to odczuwalne.

Należy pamiętać, że aby rozwiązać problem, należy zdiagnozować wąskie gardło, a następnie je wyeliminować i zastąpić optymalniejszym rozwiązaniem!

  • poniedziałek, 07 sierpień 2017