Tak więc - mamy wewnętrzną bazę danych firmy, zwykłe rzeczy: zarządza klientami, rozmowami telefonicznymi, umowami sprzedaży i umowami / programami dla klientów.
Jest to interfejs programu Access 2000 i zaplecze programu SQL Server 2000 Standard. Pojedynczy serwer, podwójny Xeon 3.2GHz, 2GB RAM, Windows Server 2003, dostaje około 40% obciążenia procesora przez cały dzień, rozłożony na 4 rdzenie widoczne dla systemu operacyjnego (HT).
Baza danych zaplecza jest źle zaprojektowana i rozwijała się organicznie przez ponad 10 lat, prowadzona przez osoby o niskich kwalifikacjach. Jest źle znormalizowany, a niektóre z oczywistych problemów obejmują tabele z dziesiątkami tysięcy wierszy bez klucza podstawowego lub indeksu, które są również intensywnie używane w połączeniach wielostolikowych dla niektórych najczęściej używanych części systemu (np. aplikacja menedżera połączeń, która siedzi na drugim monitorze każdego człowieka przez 8 godzin dziennie i uruchamia duże, nieefektywne zapytanie co kilka sekund).
Interfejs nie jest dużo lepszy, jest to typowy bałagan setek formularzy, zagnieżdżone zapisane zapytania, źle napisane osadzone SQL w kodzie VBA, dziesiątki „dziwactw” itp., A przy każdej zmianie wydaje się, że coś niezwiązanego znika. Zdecydowaliśmy się na jeden MDB, który działa „wystarczająco dobrze”, a teraz mamy politykę bez zmian, ponieważ nie mamy wewnętrznych ciężarów Access (i nie planujemy też ich zatrudnić).
Firma powoli się rozwija, rośnie liczba klientów, połączeń itp., A także niewielki wzrost liczby równoczesnych użytkowników, a wydajność wyraźnie się ostatnio pogorszyła (oczekiwanie na przejście między formularzami, oczekiwanie na wypełnienie list itp.) )
Perfmon mówi:
- Transfer dysków na sekundę: od 0 do 30, średnio 4.
- Aktualna długość kolejki dyskowej: unosi się wokół 1
Profiler programu SQL Server widzi setki tysięcy zapytań co minutę. Zużycie procesora przez klientów jest prawie zerowe, co oznacza, że oczekuje na wykonanie zapytań po stronie serwera. Obciążyłem to zadanie Doradcą dostrajania silnika DB, zastosowałem jego sugestie do testowej kopii zapasowej, ale tak naprawdę nie miało to większego znaczenia.
Nawiasem mówiąc, mamy połączenie 100 MB i Gigabit Ethernet, wszystkie w jednej podsieci, 40 użytkowników na dwóch piętrach.
Do pytania.
Widzę, że mamy dwie możliwości rozwiązania / poprawy tej sytuacji.
- Możemy go złomować i zastąpić całkowicie nowym systemem CRM, na zamówienie lub częściowo na zamówienie
- Możemy przedłużyć żywotność tego systemu, mocując do niego sprzęt.
Możemy zbudować system Intel i7 z szalonymi liczbami wydajności za rząd wielkości mniejszy koszt niż wymiana oprogramowania.
Kiedy w końcu opracowywany jest nowy system, można go hostować na tym urządzeniu, więc nie ma zmarnowanego sprzętu. Nowy system CRM ciągle się odkłada, odsuwa i odsuwa - nie widzę tego przez co najmniej rok.
Wszelkie przemyślenia na temat tej sytuacji, szczególnie jeśli sam tu byłeś, byłyby bardzo mile widziane.
Dzięki