From jacek w erp5.pl Mon Nov 26 08:54:11 2007 From: jacek w erp5.pl (Jacek Medrzycki) Date: Mon, 26 Nov 2007 08:54:11 +0100 Subject: [Erp5-poland] safety In-Reply-To: <4748439E.5030303@brzezina.pl> References: <4748439E.5030303@brzezina.pl> Message-ID: <474A7BA3.6000302@erp5.pl> Tomasz Brzezina pisze: > > > procedura normalna: > 1. backupujemy skrypty ERP5 raz na dzień (żeby było szybciej niż > instalowanie od zera) Jeśli przez "skrypty" rozumiemy zawartość INSTANCE_HOME (bez data.fs) , to w zasadzie nie ma takiej potrzeby. Tam coś zmienić może jedynie developer i wtedy można zrobić backup instance home. Z drugiej strony, to co zajmuje gros miejsca to data.fs. Reszta nie jest taka duża. > 2. backupujemy dwa razy dziennie plik data.fs No, powiedzmy tyle razy ile jest to wymagane przez politykę bezpieczeństwa. Może wystarczać raz, może być konieczność backupowania kilka razy dziennie. Nb., jest narzędzie (nazywa się to-to repozo.py, nie pamiętam czy jest w standardzie czy musiałem doinstalować) co umożliwia robienie incrementalnych i pełnych backupów data.fs bez zatrzymywania zope'a. Więc jak ktoś chce, to inkrementalki można i co dziesięć minut puszczać. Niestety, nie ma czegoś takiego jak online log w informixie czy redo log w Oraclu, że transakcje spadają do loga (który może być na taśmie albo innej maszynie) praktycznie na bieżąco i co umożliwia odzysk danych up to date. > > procedura awaryjna - w razie awarii dysku > 1. kupuję nowy dysk > 2. instaluję system, odtwarzam backup systemu > 3. odtwarzam drzewo ERP5 (skrypty) > 4. kopiuję z backupa plik data.fs 5a. Jeśli backup systemu nei zawierał mackupu bazy mysql, robię bazę mysql, przydzielam uprawnienia i tworzę niezbędne tabele bo czasami erp5 sobie z tym (zrobieniem tabel) nie radzi. A czasami sobie radzi. Poza tym, jeśli erp5 miał jakieś nie przerobione activities, to informacja o tym jest w bazie mysql tylko (IMHO). Więc dobrze dumpować jest bazę myslq. Haczyk - jeśli erp5 ostro miele activitiesami, to prawdopodobnie backupy zope-a i mysql będą out of sync. Dobrze jest robić backup Data.fs wtedy, kiedy mamy pewność, że zope nie pracuje - albo faktycznie go zatrzymać, mimo możliwości robienia backupu online. > 5. odpalam skrypt ZrobMiDobrzeIOdtworzSystem.sh W praktyce, jeśli był zrobiony dump bazy (albo baza nie ucierpiała) i baza jest sync z Data.fs, to może nie być konieczne robienie niczego. > 6. czekam X minut czasu, gdzie X jest mniej niż 600 Tu nie ma gwaracji. Reideksacja dużego sajta pewnie może trwać z godzinę. > 7. restartuję system dla pewności > 8. I'm ALIVE! (brakuje mi tylko danych od ostatniego backupu) > No w sumie się zgadza. J. From tomasz w brzezina.pl Mon Nov 26 09:09:43 2007 From: tomasz w brzezina.pl (Tomasz Brzezina) Date: Mon, 26 Nov 2007 09:09:43 +0100 Subject: [Erp5-poland] safety In-Reply-To: <474A7BA3.6000302@erp5.pl> References: <4748439E.5030303@brzezina.pl> <474A7BA3.6000302@erp5.pl> Message-ID: <474A7F47.90800@brzezina.pl> Jacek Medrzycki pisze: > Tomasz Brzezina pisze: >> >> procedura normalna: >> 1. backupujemy skrypty ERP5 raz na dzień (żeby było szybciej niż >> instalowanie od zera) > Jeśli przez "skrypty" rozumiemy zawartość INSTANCE_HOME (bez data.fs) , > to w zasadzie nie ma takiej potrzeby. Tam coś zmienić może jedynie > developer i wtedy można zrobić backup instance home. Ok. Ok. (wyszedłem z założenia że będę tam grzebał jako developer ;D W sensie częstych upgrejdów. > Z drugiej strony, to co zajmuje gros miejsca to data.fs. Reszta nie jest > taka duża. >> 2. backupujemy dwa razy dziennie plik data.fs > No, powiedzmy tyle razy ile jest to wymagane przez politykę > bezpieczeństwa. Może wystarczać raz, może być konieczność backupowania > kilka razy dziennie. > Nb., jest narzędzie (nazywa się to-to repozo.py, nie pamiętam czy jest w > standardzie czy musiałem doinstalować) co umożliwia robienie > incrementalnych i pełnych backupów data.fs bez zatrzymywania zope'a. > Więc jak ktoś chce, to inkrementalki można i co dziesięć minut puszczać. O, to jest dobre, ale w kontekście problemu mysqla poniżej akceptowalne jest zatrzymanie zope na czas backupu. czyli procedura backupu: 1. zatrzymanie zope 2. dump mysql'a 3. backup pliko data.fs 4. włączenie zope 4. rsync reszty dysku w tym INSTANCE_HOME (z pominięciem niektórych katalogów /dev, /tmp, /proc etc. >> procedura awaryjna - w razie awarii dysku >> 1. kupuję nowy dysk >> 2. instaluję system, odtwarzam backup systemu >> 3. odtwarzam drzewo ERP5 (skrypty) >> 4. kopiuję z backupa plik data.fs > 5a. Jeśli backup systemu nei zawierał mackupu bazy mysql, robię bazę > mysql, przydzielam uprawnienia i tworzę niezbędne tabele bo czasami erp5 > sobie z tym (zrobieniem tabel) nie radzi. A czasami sobie radzi. > Poza tym, jeśli erp5 miał jakieś nie przerobione activities, to > informacja o tym jest w bazie mysql tylko (IMHO). Więc dobrze dumpować > jest bazę myslq. > Haczyk - jeśli erp5 ostro miele activitiesami, to prawdopodobnie backupy > zope-a i mysql będą out of sync. Dobrze jest robić backup Data.fs wtedy, > kiedy mamy pewność, że zope nie pracuje - albo faktycznie go zatrzymać, > mimo możliwości robienia backupu online. >> 5. odpalam skrypt ZrobMiDobrzeIOdtworzSystem.sh > W praktyce, jeśli był zrobiony dump bazy (albo baza nie ucierpiała) i > baza jest sync z Data.fs, to może nie być konieczne robienie niczego. >> 6. czekam X minut czasu, gdzie X jest mniej niż 600 > Tu nie ma gwaracji. Reideksacja dużego sajta pewnie może trwać z godzinę. noo 600 minut to raczej więcej niż godzina ;D >> 7. restartuję system dla pewności >> 8. I'm ALIVE! (brakuje mi tylko danych od ostatniego backupu) > No w sumie się zgadza. procedura awaryjna: 1. kupuję nowy dysk 2. instaluję system, odtwarzam backup systemu w tym instance_home 3. kopiuję z backupa plik data.fs 4. restore mysql 5. restart sytemu dla pewności 6. oczekiwanie na reindexację X minut czasu gdzie X < 600 7. UFF! Po kłopocie -- T. -------------- następna część --------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3327 bytes Desc: S/MIME Cryptographic Signature URL: From jacek w erp5.pl Mon Nov 26 09:14:46 2007 From: jacek w erp5.pl (Jacek Medrzycki) Date: Mon, 26 Nov 2007 09:14:46 +0100 Subject: [Erp5-poland] safety In-Reply-To: <474A7F47.90800@brzezina.pl> References: <4748439E.5030303@brzezina.pl> <474A7BA3.6000302@erp5.pl> <474A7F47.90800@brzezina.pl> Message-ID: <474A8076.7020108@erp5.pl> Tomasz Brzezina pisze: > > czyli procedura backupu: > 1. zatrzymanie zope > 2. dump mysql'a > 3. backup pliko data.fs > 4. włączenie zope > 4. rsync reszty dysku w tym INSTANCE_HOME (z pominięciem niektórych > katalogów /dev, /tmp, /proc etc. No coś w ten deseń. > noo 600 minut to raczej więcej niż godzina ;D Uuuups! :D Nie wiem dlaczego mi się zera poprzestawiały. J. From bartek w erp5.pl Mon Nov 26 10:30:30 2007 From: bartek w erp5.pl (bartek) Date: Mon, 26 Nov 2007 10:30:30 +0100 Subject: [Erp5-poland] =?utf-8?q?testowanie_wydajno=C5=9Bci=2C_szukanie_w?= =?utf-8?q?=C4=85skich_garde=C5=82_-_UI_i_odczucia_user=C3=B3w?= In-Reply-To: <20071123165729.0f15fdf6@tank.ventis.local> References: <20071123165729.0f15fdf6@tank.ventis.local> Message-ID: <474A9236.8030503@erp5.pl> Łukasz Nowak wrote: > Witam, > > Wstępem - czy wydaje mi się, czy Zope-2 jest szybkościowo-wydajnościowy > słaby? I wcale się nie skaluje - bez użycia ZEO czy clusteringu? > Zakładam, że tak. Nie wiem czy to jest akurat zope-2 (tj nie wiem czy zope-1 i zope-3 są jakoś znacząco szybsze), ale generalnie rzeczywiście rakieta to nie jest. > > Mamy coraz więcej różnorodnie powiązanych ze sobą danych w systemie. Od > pewnego czasu zaczynają być problemy z wydajnością. Np. wyświetlanie > accounting_module listboxa trwa...8 sekund. Niektóre raporty generują > się po 20 sekund, a sposób ich używania czy potrzeby firmy zakładają, > że powinny być dostępne w 1-2 sekundy. > Można by spróbować przechowywać wartości które są często wyliczane. Np wyliczenie stanu magazynowego dla produktu to jest sporo pracy dla systemu, a prawdopodobnie robisz to bez przerwy do prawie każdego raportu. Można by więc wyliczać stan przy pomocy interaction workflow i przechować go gdzieś - GuidelinesForCodingCrimes podają dwa rozwiązania, poza tym być może można by wykorzystać cache (jeżeli tylko da się odświeżyć cache dla konkretnej wartości a nie od razu cały, trzeba by zajrzeć do API). Bartek > Mam ogólne pytanie - w jaki sposób - nie uciekając się do technologii > testowania UI w stylu mechanize, etc - wytestować wydajność formatek? > Byłbym wdzięczny za URI na sieci do analizy problemu. Na razie moje > profilery są dość proste: > > ==SNIP== > ## Script (Python) "profik" > ##bind container=container > ##bind context=context > ##bind namespace= > ##bind script=script > ##bind subpath=traverse_subpath > ##parameters= > ##title= > ## > for i in range(1,6): > b = DateTime().timeTime() > context.accounting_module.view() > e = DateTime().timeTime() > > print i,e-b > > request=context.REQUEST > request.RESPONSE.setHeader('Content-type', 'text/plain') > return printed > ==SNIP== > > Mam zamiar potworzyć sobie klasy, które wyliczą średnie czasy generacji > różnych formatek na portal type'ach, z ewentualnym testowaniem wywołań > okrojonych (np. listbox z mniejszą ilością kolumn, aby stwierdzić, czy > jakaś konkretna nie kładzie systemu na kolana). > > Jeśli jesteście zainteresowani współpracą, macie propozycje, uwagi czy > znacie już temat byłbym wdzięczny za sugestie. > > Miłego weekendu, > Łukasz > -- "feelings affect productivity. (...) unhappy people write worse software, and less of it." Karl Fogel, "Producing Open Source Software"