Synchronizacja z serwisami - Zmiany

[Ks. Robak 314]

 

10.000 transakcji dziennie robi wrażenie.

Choć trochę mnie dziwi, że tak wielka firma, korzysta z oprogramowania półkowego 

 

 

[PanBanBan Marcin 185]

10.000 transakcji dziennie robi wrażenie.

Fakt - robi wrażenie 

 

Choć trochę mnie dziwi, że tak wielka firma, korzysta z oprogramowania półkowego 

1. Mnie też to dziwi przy tej liczbie transakcji ale wychodzi na to, że Sello to niezły kombajn więc po co przepłacać za rozwiązania na zamówienie

A czy ktoś zna teoretyczny limit Sello - jaka jest maksymalna ilość aukcji, transakcji, którą Sello jest w stanie płynnie na bieżąco obsługiwać? Czy wynika to wyłącznie z mocy komputera i szybkości łącza? W ogóle czy serwery Allegro potrafią płynnie obsługiwać takich dużych sprzedawców i współpracować z Sello?

 

2. Zapewne dotyczy to raczej kilku kont, a nie jednego więc ze swojej strony zasugeruję, że przy tak dużej liczbie transakcji można by pomyśleć nad podzieleniem bazy danych na dwa komputery serwery i np. z części kont odbierać dane na jednym komputerze, a kolejne konta na drugim. Lub podzielić bazę ze względu na towary.

 

[tadeusz 0]

10.000 transakcji dziennie robi wrażenie.

Choć trochę mnie dziwi, że tak wielka firma, korzysta z oprogramowania półkowego  

Nie do końca z półkowego. Tu mowa o Sello w połączeniu z Navireo. Zmiany w Sello tez nie są małe:) Triggery i możliwości zastosowania kodu w wydrukach dają całkiem spore możliwości.

Co do komfortowej pracy to 300000 to za dużo. Ilość spadła dość znacząco, rozbicie na parę kont. Kilka baz. Konieczne praktycznie zmniejszenie logu bazy do minimum (w ciągu miesiąca log potrafił przekroczyć 20gb co się odbijalo na wydajności). Bieżąca obsługa i defragmentacja indeksów.

Temat rzeka:) Ale da się ogarnąć w pewnym stopniu. Wciąż największym problemem okazuje się pobranie danych z Allegro.

[PanBanBan Marcin 185]

Nie do końca z półkowego. Tu mowa o Sello w połączeniu z Navireo. Zmiany w Sello tez nie są małe:) Triggery i możliwości zastosowania kodu w wydrukach dają całkiem spore możliwości.

No i nie zapominajmy o polach własnych w Sello

Spoko, jak będę miał 5.000 transakcji dziennie to zgłoszę się do Ciebie

 

 

A jeszcze jak wygląda pakowanie 10.000 paczek dziennie. Przecież to musi być linia logistyczno - pakowawcza, jak w tych nowych centrach logistycznych, co Amazon buduje w Polsce

[Ks. Robak 314]

 

Spoko, jak będę miał 5.000 transakcji dziennie to zgłoszę się do Ciebie

 

 

Ja się zgłoszę jak będę miał 500 dziennie 

[zata 1]

Już przy 500 transakcjach dziennie utrzymanie sello to zmora

Największym problemem dla mnie są wycieki pamięci Sello po 4-5h działania pożera 2GB RAMu i przestaje cokolwiek robić.

 

Poza tym dzięsiątki dodatkowych indeksów w bazie danych, regularna "konserwacja", czyszczenie danych, mechanizmy kontrolujące "czy sello działa" itp ogólnie temat rzeka, a przygotowanie sello na listopad i grudzień już powoli trzeba zaczynać (pobranie kilku tysięcy transakcji dziennie w grudniu na "dużym" koncie to 10h bo pobieranie na podstawie dziennika w grudniu już się nie sprawdza - tak pokazują doświadczenia z zeszłego roku )

[Ks. Robak 314]

Przy tak dużej ilości transakcji powinniście zainwestować w porządny serwer, z profesjonalnym podziałem bazy na partycje, każda na osobnym dysku, najlepiej SSD.

http://technet.microsoft.com/pl-pl/library/akademia-sql---czesc-16-partycjonowanie-tabel---informacje-podstawowe.aspx

No i dużo pamięci.

Koszt raczej duży, myślę, że ponad 10.000 zł na same dyski by poszło, ale zakładam, że zyski też macie duże przy takiej ilości transakcji.

 

Poza tym piszesz o dodatkowych indexach, czy były prawidłowo przemyślane ?

Sello raczej ma dobrze zaindeksowaną bazę na starcie.

A każdy dodatkowy index zamula bazę podczas zapisu, czyli np. pobierania danych, operacji na transakcjach.

[Bartosz Rosa 1 783]

Z serwerami jest taki problem, że potrafią one różnie dobierać sobie optymalny plan wykonania zapytania w zależności od różnych czynników (zwłaszcza na dużych bazach jest to widoczne). Stąd może się okazać, że nagle zapytanie wykonuje się 10s zamiast 0,01s - mieliśmy taki przypadek w Sello kilka wersji temu (problem długiego łikendu )

[zata 1]

Przy tak dużej ilości transakcji powinniście zainwestować w porządny serwer, z profesjonalnym podziałem bazy na partycje, każda na osobnym dysku, najlepiej SSD.

http://technet.microsoft.com/pl-pl/library/akademia-sql---czesc-16-partycjonowanie-tabel---informacje-podstawowe.aspx

No i dużo pamięci.

Koszt raczej duży, myślę, że ponad 10.000 zł na same dyski by poszło, ale zakładam, że zyski też macie duże przy takiej ilości transakcji.

 

Poza tym piszesz o dodatkowych indexach, czy były prawidłowo przemyślane ?

Sello raczej ma dobrze zaindeksowaną bazę na starcie.

A każdy dodatkowy index zamula bazę podczas zapisu, czyli np. pobierania danych, operacji na transakcjach.

 

Serwer SQL ma przydzielone 64 GB Ramu bo więcej nie weźmie wersja standard i dwa świeże Xeony Octa-core, baza leży na dedykowanej macierzy złożonej z 5 dysków SAS 15K (oczywiście logi są na innej i tempdb też na innej , baza ma raptem 5GB - jedno konto i odcinane ok marca (założna świeża baza). Tak więc sprzęt ani konfiguracja nie jest tutaj problemem, sello mam do zarzucenia tak naprawdę tylko wieceki pamięci po kilku godzinach działania na tej bazie pochłania 1,7GB ramu i przestaje cokolwiek robić, więc mam skonfigurowany automat który sprawdza zużycie ramu i restartuje Sello jak przekroczy granicę. A największym problemem jest pobieranie danych z Allegro - dzienniki gubią dane a pełne pobieranie trwa różnie ale minimum 5h, chcąc utrzymać standard wysyłki na poziomie 24h takie kilkugodzinne opóźnienie ma już znaczenie.

 

A co do indeksów to wiele zależy od ilości danych i sposobu korzystania z filtrów itp - sello jest na tyle konfigurowalne że nie ma uniwersalnych indeksów a przy pewnym rozmiarze danych już niezależnie od systemu indeksy trzeba dodawać (i dotyczy to każdego systemu z jakim miałem do tej pory do czyenienia), zreszta nawet teraz mamy niedzielę więc nikt na sello nie pracuje biorę 2 najdłużej wykonujące się zapytania i co:

 

The Query Processor estimates that implementing the following index could improve the query cost by 99.9592%.

The Query Processor estimates that implementing the following index could improve the query cost by 99.9694%.

 

i to indeksy tego typu:

CREATE NONCLUSTERED INDEX [<Name of Missing Index, sysname,>]

ON [dbo].[em__Email] ([em_MessageId])

 

nie analizuje już tego bo szkoda mi czasu ale tu aż jestem zdziwiony że na em_MessageId nie ma indeksu skoro z tego co widzę masa selectów po tym idzie