- lms - lists.lms.org.pl

Re: Wydajnosc 1.7.6 vs spora (?) baza
by A.L.E.C 22 Lis '05

22 Lis '05

Piotr Dobrzański wrote: > To nie takie latwe, zreszta nie moge porzucic danych juz > wprowadzonych, a konwersja na postgresql tez wymagalaby sporo roboty > .... Nie jest potrzebna żadna konwersja (chyba tylko ewentualnie kodowanie). Zakładasz pustą bazę w postgresie i przywracasz bazę z backupu LMSowego (ustaw odpowiednio długi czas wykonania skryptu), później VACUUM i powinno być przyspieszenie. -- Aleksander 'A.L.E.C' Machniak http://alec.pl gg-2275252 LAN Management System Developer http://lms.alec.pl

1 0

Re: Wydajnosc 1.7.6 vs spora (?) baza
by Tomasz Chilinski 22 Lis '05

22 Lis '05

On Tue, 22 Nov 2005 12:35:02 +0100, Piotr Dobrzański wrote > > > Zaraz bede patrzyl pod katem tuningu mojego sqla i php, ale nie sadze > > > abym wiele zyskal w stosunku do domyslnych ustawien. > > > > mysql->pgsql (to pierwszy element tuningu). > > To nie takie latwe, zreszta nie moge porzucic danych juz > wprowadzonych, a konwersja na postgresql tez wymagalaby sporo roboty > .... Kto mówi o porzucaniu danych? Ja robiłem to ręcznie i bez problemu poszło. Zawsze masz: http://silvercoders.com/index.php?page=SqlUnify Adrianku: ;) Pozdrawiam T.

1 0

Re: Wydajnosc 1.7.6 vs spora (?) baza
by Dariusz Kowalczyk 22 Lis '05

22 Lis '05

On Tue, 22 Nov 2005 12:33:21 +0100, Piotr Dobrzański wrote > > zapytanie do bazy danych powinno chyba dotyczyc tylko wyswietlanych i w miare > > przegladania stron powinna byc odpytywana baza o reszte inaczej kazda baza zarznie > > takim zapytaniem serwer,jak za kazdym razem bedzie orac po wszystkich tabelach i > > rekordach > > ...no chyba ze sie ze wzgledow konstrukcyjnych programu nie da zawezac zapytan do > > wyswietlanych na stronie dokumentow > > > > /etc/lms176/lms.ini > > ; Limit of displayed records on page on invoices list. Default: 50 > ; invoicelist_pagelimit = 50 > > Wiec 50, z tym, ze tego co wiem, najpierw jest tworzona lista danych a > dopiero pozniej jest ona przypisywana do szablonu, wiec podzial na > strony nie wplywa na zapytanie ... no a szkoda bo przez to wlasnie jest taki efekt Dariusz Kowalczyk

1 0

Re: Wydajnosc 1.7.6 vs spora (?) baza
by Piotr Dobrzański 22 Lis '05

22 Lis '05

> > Zaraz bede patrzyl pod katem tuningu mojego sqla i php, ale nie sadze > > abym wiele zyskal w stosunku do domyslnych ustawien. > > mysql->pgsql (to pierwszy element tuningu). To nie takie latwe, zreszta nie moge porzucic danych juz wprowadzonych, a konwersja na postgresql tez wymagalaby sporo roboty ....

1 0

Re: Wydajnosc 1.7.6 vs spora (?) baza
by Piotr Dobrzański 22 Lis '05

22 Lis '05

> zapytanie do bazy danych powinno chyba dotyczyc tylko wyswietlanych i w miare > przegladania stron powinna byc odpytywana baza o reszte inaczej kazda baza zarznie > takim zapytaniem serwer,jak za kazdym razem bedzie orac po wszystkich tabelach i > rekordach > ...no chyba ze sie ze wzgledow konstrukcyjnych programu nie da zawezac zapytan do > wyswietlanych na stronie dokumentow > /etc/lms176/lms.ini ; Limit of displayed records on page on invoices list. Default: 50 ; invoicelist_pagelimit = 50 Wiec 50, z tym, ze tego co wiem, najpierw jest tworzona lista danych a dopiero pozniej jest ona przypisywana do szablonu, wiec podzial na strony nie wplywa na zapytanie ...

1 0

Re: Wydajnosc 1.7.6 vs spora (?) baza
by Dariusz Kowalczyk 22 Lis '05

22 Lis '05

On Tue, 22 Nov 2005 12:17:46 +0100, Tomasz Chilinski wrote > On Tue, 22 Nov 2005 12:01:05 +0100, Piotr Dobrzański wrote > > Witam > > Witam. > > > Zaraz bede patrzyl pod katem tuningu mojego sqla i php, ale nie sadze > > abym wiele zyskal w stosunku do domyslnych ustawien. > > mysql->pgsql (to pierwszy element tuningu). > > > pozdrawiam > > Pozdrawiam. a ile jest dokumentow wyswietlanych na stronie ? zapytanie do bazy danych powinno chyba dotyczyc tylko wyswietlanych i w miare przegladania stron powinna byc odpytywana baza o reszte inaczej kazda baza zarznie takim zapytaniem serwer,jak za kazdym razem bedzie orac po wszystkich tabelach i rekordach ...no chyba ze sie ze wzgledow konstrukcyjnych programu nie da zawezac zapytan do wyswietlanych na stronie dokumentow Dariusz Kowalczyk

1 0

Re: Wydajnosc 1.7.6 vs spora (?) baza
by Tomasz Chilinski 22 Lis '05

22 Lis '05

On Tue, 22 Nov 2005 12:01:05 +0100, Piotr Dobrzański wrote > Witam Witam. > Zaraz bede patrzyl pod katem tuningu mojego sqla i php, ale nie sadze > abym wiele zyskal w stosunku do domyslnych ustawien. mysql->pgsql (to pierwszy element tuningu). > pozdrawiam Pozdrawiam.

1 0

Wydajnosc 1.7.6 vs spora (?) baza
by Piotr Dobrzański 22 Lis '05

22 Lis '05

Witam Udal mi sie w koncu upgrade z 1.4.1 do 1.7.6. Czesc problemow, ktore wiazalem z samym upgradem wynika z wydajnosci systemu. Mam Celerona 2.9GHz, 512RAM, plyte Gigabyta, dysk 7200RPM. System: Wersja LMS: 1.7.6 Grannus (1.751/1.12) Wersja LMSDB: 1.7.6 Grannus (core: 1.36 / driver: mysql 1.34) Wersja MySQL: 4.0.24_Debian-10ubuntu2-log Wersja PHP: 4.4.0-3 Wersja Smarty: 2.6.10 Wersja systemu: Linux 2.6.12-9-686 (Linux) Poza samym LMSem chodzi Gnome. Info o bazie: uzytkownicy liczeni w tysiacach, podobna ilosc komputerow, okolo 20000 wystawionych dokumentow. 2 najbardziej uciazliwe rzeczy: W przypadku, gdy konieczne jest wybranie uzytkownika z listy (np finanse->wydruki) wygenerowanie strony trwa nawet do 30s. Propozycja rozwiązania: uzyć tego samego mechanizmu jak w polu wyszukiwania, tzn zawezanie rezultatu w miare wpisywania kolejnych znakow. Wygenerowanie listy faktur (Finanse->list faktur) jest koszmarem. Samo zapytanie przez konsole mysqla zajmuje 9min, zrobienie tego samego przez LMSa rowna sie 20 minutowej przerwie na kawe. Propozycja rozwiazania: Wyswietlenie filtra danych jako pierwszego, bez koniecznosci generowania calej listy faktur (o ile sie da to zrobic), rzadko kiedy generuje sie wydruk wszystkich faktur, predzej np liste faktur dla danego klienta. Zaraz bede patrzyl pod katem tuningu mojego sqla i php, ale nie sadze abym wiele zyskal w stosunku do domyslnych ustawien. pozdrawiam

1 0

Re: Mysql 4.1.15, kodowanie - problem
by Łukasz Wojciechowski 22 Lis '05

22 Lis '05

Łukasz Wojciechowski napisał(a): > Witam > > Cały dzień już w plecy i dalej gryzę biurko ze złości. > > Postanowiłem sobie zupgradować apache'a, php'ka i mysql'a. > > Zrobiłem tak: > 1. mysqldump -A > zrzut.sql > 2. apache 1.3.x => apache 2.0.x > 3. php 4.3.11 => php 5.0.5 > 4. mysql 4.1.9 => mysql 4.1.15 > 5. mysql..... -> source zrzut.sql > > Efekt jest taki, że niektóre polskie znaki, np "ę" mam jako "krzaczki". > Kodowanie w lmsie mam ustawione na latin2, w mysql również. > > Po wyedytowaniu takiego klienta i wpisaniu ę zamiast krzaka - nadal > pojawia się krzak. > > Wielce się zdziwiłem, kiedy odtwarzając kopię bazy zrobioną wcześniej > przez LMS'a i będąc pewnym, że krzak zniknie - nie znknął :/ > > Pomóżcie bo już mnie trafia powoli. > > z góry dzięki Problem rozwiązałem wywołując tóż po nawiązaniu połączenia zapytanie: SET NAMES latin2 I moje pytanie - czy da się to jakoś ustawić "ładniej"? Tak żebym nie musiał modyfikować źródeł LMS'a. ?? -- pozdrawiam Łukasz Wojciechowski

1 0

Mysql 4.1.15, kodowanie - problem
by Łukasz Wojciechowski 22 Lis '05

22 Lis '05

Witam Cały dzień już w plecy i dalej gryzę biurko ze złości. Postanowiłem sobie zupgradować apache'a, php'ka i mysql'a. Zrobiłem tak: 1. mysqldump -A > zrzut.sql 2. apache 1.3.x => apache 2.0.x 3. php 4.3.11 => php 5.0.5 4. mysql 4.1.9 => mysql 4.1.15 5. mysql..... -> source zrzut.sql Efekt jest taki, że niektóre polskie znaki, np "ę" mam jako "krzaczki". Kodowanie w lmsie mam ustawione na latin2, w mysql również. Po wyedytowaniu takiego klienta i wpisaniu ę zamiast krzaka - nadal pojawia się krzak. Wielce się zdziwiłem, kiedy odtwarzając kopię bazy zrobioną wcześniej przez LMS'a i będąc pewnym, że krzak zniknie - nie znknął :/ Pomóżcie bo już mnie trafia powoli. z góry dzięki -- pozdrawiam Łukasz Wojciechowski

1 0