System mobilny Gemini

[adam]

Czy może ktoś z Was miał doczynienia z systemem sprzedaży mobilnej Gemini firmy Mobilebox ?

[wojtek]

Używamy EcodAgent, całkiem sensownie się integruje z XL'em, szkoda tylko że jest trochę niedopracowany i co chwile wychodzą jakieś błedy. Używamy go prawie 2 lata i sami zgłaszaliśmy już przez ten okres kilkanaście poważnych błedów. Dzieki nam Comarch ulepszył swój produkt Powinniśmy zostać Beta testerami

[adam]

Jakiego rodzaju były te błędy? Czy Twój system oparty jest na triggerach?

[wojtek]

EcodAgent posiada własną bazę, która przy pomocy specjalnych plików wymienia informację z XL (synchronizacja)
Co do błedow to mozna by wymieniac dlugo, do najwazniejszych nalezaly:
1. znikajace dzialania po synchronizacji na IPAQ (wskutek przepisywania klientow podmiedzy poszczegolnych PH)
2. problemy z trasowkami
3. bledne dane w raportach sprzedazy
4. czesto wysypuje sie baza na Ipaq
5. Aktualizacja do nowej wersji to "nieporozumienie" (nie mozna zdalnie, trzeba miec wszystkie urzadzenia na miejscu)
itd..

Pocieszajace jest to ze wychodza poprawki, szkoda tylko ze dlugo trzeba na nie czekac

Reasumujac aplikacja nie jest taka zla, fajny interface, prosta w obsludze tylko strasznie niedopracowana.

[adam]

Z jaką częstotliwością odbywa się synchronizacja?
Moja baza ma już ponad 30GB, CDN dość poważnie zwalnia. Sprzętowo jesteśmy mocni. Czy istnieje jakiś "myk" na przyspieszenie?

[wojtek]

Z jaką częstotliwością odbywa się synchronizacja?

Z taką częstotliwością z jaką sobie ustawimy w harmonogramie zadań (np co 15 minut o odstepach 5 minutowych na kazdy plik) , synchronizacja polega na uruchomieniu trzech plików po kolei
1. export do xl
2. inport z xl
3. platnosci

[mikey]

Z jaką częstotliwością odbywa się synchronizacja?
Moja baza ma już ponad 30GB, CDN dość poważnie zwalnia. Sprzętowo jesteśmy mocni. Czy istnieje jakiś "myk" na przyspieszenie?

"Myków" jest wiele, pewnie nawet setki To co stosujesz zależy do tego gdzie masz wąskie gardła. To, że baza przyrosła Ci o 30 GB w 10 miesięcy może być wynikiem tego np. że wykorzystujecie binarne załączniki w kartotekach ... przypisując np. film video do towaru Wtedy np. dzielisz bazy na partycje i inwestujesz w macierze, macierze, macierze.
Jeśli wspomniane przyrosty generujecie na samych transakcjach i dokumentach ... to możesz sobie poprawić mechanizmy związane z przechowywaniem stanów towarów, obliczaniem cen (cdn.MacierzRabatowa) itp. itd. tak by uwzględniały tylko te elementy które wykorzystujecie. Choć z drugiej strony mało to możliwe by XL pozwolił wystawić ręcznie 30 tys pozycji na dokumentach handlowych dziennie - a tyle ich na mój gust potrzeba by baza rosła 3GB miesięcznie.

[adam]

Gust Masz niezły, bazka na dzień dzisiejszy ma 28GB. Dziennie generujemy ponad 32000 pozycji (jak klepać to klepać)
Nie używamy żadnych danych binarnych. Wyłączyliśmy stany magazynowe (PM,WM).
Inny problem to triggery. System mobilny wykorzystuje je do pracy. Zdaniem firmy obsługującej moją instalację, wykorzystanie triggerów jest błędem, z drugiej strony producent systemu mobilnego zarzeka się że nie pierwszy raz instaluje swoje oprogramowanie na CDNXL i tylko u nas występują błędy (wydajnościowe). Mamy zainstalowaną standartową wersję SQL. Może przejście na Enterprise coś pomoże? Firma obsługujaca nas twierdzi że na wydajność CDNXL typ SQL nie ma wpływu.
Konfiguracja Serwera:
- 2 x Intel Xeon 5140 - 2.33 Ghz (dwu rdzeniowy)
- 2 dyski SAS, RAID 1 na System operacyjny, 4 dyski SAS w konfiguracji RAID10 dla bazy danych
- 12 GB ramu
- silnik - SQL 2005 Std SP2 x64
- System operacyjny Windows Server 2003 Standard x64 SP2

[mikey]

Sam fakt istnienia triggera nie determinuje większego lub mniejszego spadku wydajności. Zależy jeszcze co on tam ma w środku, ale większości przypadków nie zmniejszy to wydajności bardziej niż częste, okresowe zapuszczanie zapytań w poszukiwaniu zmian w tabelach.
32000 pozycji to sporo - ręcznie - to miałem na myśli interface CDN XL, który by sobie po prostu z tym nie poradził, jeśli zamówienia tworzone są offline w innym systemie, to ich import na tym poziomie jest już całkiem prawdopodobny
Do dużej liczby transakcji zalecałbym:

• nie wiem czy to jeszcze jest, ale kiedyś XL miał opcję, która domyślnie powodowała zapisywanie zmian stanów historycznych przy każdej transakcji, lepiej to wyłączyć i aktualizować je raz na dobę
• jeśli zamówienia dostajesz gotowe z palmtopów z przeliczonymi cenami to możesz popracować nad procedurą "MacierzRabatowa", przynajmniej w wersji 5 to duży potencjał do optymalizacji (u mnie ok. 1 sek. na pozycję sprzedaży)
• zamiast enterprise'a zainwestowałbym najpierw w prostą skrzynkę z 14 szybkimi dyskami SAS 15k (razem 20-25 tys. zł), podzielił je na 2xRAID10 (10 i 4 dyski) i posadził bazę na 10 dyskach, logi na 4, a baze tmp na obecnych 4

i to tyle na początek - po opisie sprzętu myślę, że dyski są teraz najsłabszym ogniwem.