W lms.class.php siedzi funkcja GetCustomerNames() o takiej zawartosci:
function GetCustomerNames() { return $this->DB->GetAllByKey('SELECT id, '. $this->DB->Concat('UPPER(lastname)',"' '",'name').' AS customername FROM customersview WHERE status > 1 AND deleted = 0 ORDER BY customername asc', 'id'); }
przy 13.000 klientow wejscie w edycje komputera potrafi zamulic nawet na 15-30 sekund. Z czego samo zapytanie wykonuje sie w szczytach do 17 sekund!
Z jakiegos (dla mnie na pierwszy rzut oka bezsensownego powodu - bo to jest select, a nie insert czy update) zapytanie wykonuje sie na widoku, a nie na tabeli.
Prosta zmiana z: FROM customersview na: FROM customers
powoduje wykonanie zapytania w max 2 sek (95% przypadkow ponizej) a wyswietlenie calej strony do 5 sekund.
Wiec moze by ktos to w kodzie poprawil bo usuniecie 4 literek daje w efekcie 600% przyspieszenie tej funkcji....
Pokaż odpowiedzi według wątków
Jaroslaw Czarniak wrote:
przy 13.000 klientow wejscie w edycje komputera potrafi zamulic nawet na 15-30 sekund. Z czego samo zapytanie wykonuje sie w szczytach do 17 sekund!
Z jakiegos (dla mnie na pierwszy rzut oka bezsensownego powodu - bo to jest select, a nie insert czy update) zapytanie wykonuje sie na widoku, a nie na tabeli.
Powodem jest sprawdzenie uprawnień użytkownika do grup klientów, żeby wyświetlić listę tylko tych do których ma prawo użytkownik.
Prosta zmiana z: FROM customersview na: FROM customers
powoduje wykonanie zapytania w max 2 sek (95% przypadkow ponizej) a wyswietlenie calej strony do 5 sekund.
Wiec moze by ktos to w kodzie poprawil bo usuniecie 4 literek daje w efekcie 600% przyspieszenie tej funkcji....
Zgłoś do BTSu, bo poprawić to trzeba ale oczywiście w inny sposób.
Jaroslaw Czarniak wrote:
Zgłoś do BTSu,
A co to za czort ?
Wejdź na google.pl i wpisz "bts lms"
On Tue, Jul 28, 2009 at 03:17:24PM +0200, A.L.E.C wrote:
Jaroslaw Czarniak wrote:
przy 13.000 klientow wejscie w edycje komputera potrafi zamulic nawet na 15-30 sekund. Z czego samo zapytanie wykonuje sie w szczytach do 17 sekund!
Z jakiegos (dla mnie na pierwszy rzut oka bezsensownego powodu - bo to jest select, a nie insert czy update) zapytanie wykonuje sie na widoku, a nie na tabeli.
Powodem jest sprawdzenie uprawnień użytkownika do grup klientów, żeby wyświetlić listę tylko tych do których ma prawo użytkownik.
AFAIR dodanie kilku indeksów załatwia sprawę (26k klientów w bazie). No i przy tej ilości klientów, lepiej włączyć "big_networks" :D
Przemysław 'Repcio' Gubernat wrote:
AFAIR dodanie kilku indeksów załatwia sprawę (26k klientów w bazie).
No to może podasz jakie to indeksy dodałeś?
Jaroslaw Czarniak wrote:
przy 13.000 klientow wejscie w edycje komputera potrafi zamulic nawet na 15-30 sekund. Z czego samo zapytanie wykonuje sie w szczytach do 17 sekund!
Jaka baza/wersja bazy?
Wednesday 29 July 2009 08:23:41 A.L.E.C napisał(a):
Jaroslaw Czarniak wrote:
przy 13.000 klientow wejscie w edycje komputera potrafi zamulic nawet na 15-30 sekund. Z czego samo zapytanie wykonuje sie w szczytach do 17 sekund!
Jaka baza/wersja bazy?
mysql Ver 14.12 Distrib 5.0.51a, for debian-linux-gnu (i486) using readline 5.2
Wersja LMS: 1.11.7 Bastet (1.962/1.23) Wersja LMSDB: 1.11.7 Bastet (1.47/1.54) Wersja MySQL: 5.0.51a-3ubuntu5.4-log Wersja PHP: 5.2.4-2ubuntu5.6 Wersja Smarty: 2.6.22
Wednesday 29 July 2009 00:21:02 Przemysław 'Repcio' Gubernat napisał(a):
AFAIR dodanie kilku indeksów załatwia sprawę (26k klientów w bazie).
jakie to indeksy i na jakich tabelach?
No i przy tej ilości klientów, lepiej włączyć "big_networks" :D
juz dawno mam wlaczone :(
Jaroslaw Czarniak wrote:
mysql Ver 14.12 Distrib 5.0.51a, for debian-linux-gnu (i486) using readline 5.2 Wersja MySQL: 5.0.51a-3ubuntu5.4-log
Ok, mam tą samą wersję, wygenerowałem sobie 15000 klientów i strona edycji komputera generuje mi się w czasie 1,5 sek. Albo masz kiepski/obciążony serwer, albo masz coś nie tak. Nie wiem czy uda się zoptymalizować to zapytanie bardziej. Po za tym dla tej ilości to proponowałbym zdecydowanie postgresa.
On Wed, Jul 29, 2009 at 11:28:29AM +0200, Jaroslaw Czarniak wrote:
Wednesday 29 July 2009 00:21:02 Przemysław 'Repcio' Gubernat napisał(a):
AFAIR dodanie kilku indeksów załatwia sprawę (26k klientów w bazie).
jakie to indeksy i na jakich tabelach?
Używam MySQL'a i mam założone następujące indeksy:
customers: PRIMARY KEY (`id`), KEY `zip` (`zip`), FULLTEXT KEY `lastname` (`lastname`), FULLTEXT KEY `name` (`name`), FULLTEXT KEY `address` (`address`)
Nie są to wszystkie, gdyż założyłem je wieki temu i oczywiście nie zapisałem na których założyłem indeksy :/
W dniu 02.08.2009 09:10, Przemysław 'Repcio' Gubernat pisze:
On Wed, Jul 29, 2009 at 11:28:29AM +0200, Jaroslaw Czarniak wrote:
Wednesday 29 July 2009 00:21:02 Przemysław 'Repcio' Gubernat napisał(a):
AFAIR dodanie kilku indeksów załatwia sprawę (26k klientów w bazie).
jakie to indeksy i na jakich tabelach?
Używam MySQL'a i mam założone następujące indeksy:
customers: PRIMARY KEY (`id`), KEY `zip` (`zip`), FULLTEXT KEY `lastname` (`lastname`), FULLTEXT KEY `name` (`name`), FULLTEXT KEY `address` (`address`)
Nie są to wszystkie, gdyż założyłem je wieki temu i oczywiście nie zapisałem na których założyłem indeksy :/
zobacze jaki efekt to bedzie mialo u mnie. Z tym ze FULLTEXT nie dziala na innodb, a na myisam nie chce zamieniac tabeli....
!DSPAM:4a75b3f1282827818312239!
On Sun, Aug 02, 2009 at 05:42:33PM +0200, Jaroslaw Czarniak wrote:
W dniu 02.08.2009 09:10, Przemysław 'Repcio' Gubernat pisze:
On Wed, Jul 29, 2009 at 11:28:29AM +0200, Jaroslaw Czarniak wrote:
Wednesday 29 July 2009 00:21:02 Przemysław 'Repcio' Gubernat napisał(a):
AFAIR dodanie kilku indeksów załatwia sprawę (26k klientów w bazie).
jakie to indeksy i na jakich tabelach?
Używam MySQL'a i mam założone następujące indeksy:
customers: PRIMARY KEY (`id`), KEY `zip` (`zip`), FULLTEXT KEY `lastname` (`lastname`), FULLTEXT KEY `name` (`name`), FULLTEXT KEY `address` (`address`)
Nie są to wszystkie, gdyż założyłem je wieki temu i oczywiście nie zapisałem na których założyłem indeksy :/
zobacze jaki efekt to bedzie mialo u mnie. Z tym ze FULLTEXT nie dziala na innodb, a na myisam nie chce zamieniac tabeli....
Przy częstych selektach myisam będzie szybszy, przy częstych updatach innodb będzie efektywniejsze. MyISAM przy insertach/updatach blokuje całą tabelę, gdy innodb blokuje tylko wstawiany/aktualizowany rekord. Dlatego też przy częstych updatach sugeruje się użycie innodb, natomiast przy częstych selektach MyISAM. Ostatnio to przerabiałem z jednym serwisem. IMHO MyISAM dla tabeli customers sprawdzi się lepiej.
Jaroslaw Czarniak wrote:
customers: PRIMARY KEY (`id`), KEY `zip` (`zip`), FULLTEXT KEY `lastname` (`lastname`), FULLTEXT KEY `name` (`name`), FULLTEXT KEY `address` (`address`)
Nie są to wszystkie, gdyż założyłem je wieki temu i oczywiście nie zapisałem na których założyłem indeksy :/
zobacze jaki efekt to bedzie mialo u mnie. Z tym ze FULLTEXT nie dziala
LMS nie używa wyszukiwania pełnotekstowego, więc nic to nie da.
na innodb, a na myisam nie chce zamieniac tabeli....
Dlaczego używasz innodb? Słyszałem opinię, że właśnie w wersji 5.0.51a są jakieś problemy z wydajnością innodb. Poza tym, LMS nie wykorzystuje zalet innodb i nie widzę powodu żeby go używać (z LMSem). Zmigruj do postgresa.
On Mon, Aug 03, 2009 at 08:10:21AM +0200, A.L.E.C wrote:
Jaroslaw Czarniak wrote:
customers: PRIMARY KEY (`id`), KEY `zip` (`zip`), FULLTEXT KEY `lastname` (`lastname`), FULLTEXT KEY `name` (`name`), FULLTEXT KEY `address` (`address`)
Nie są to wszystkie, gdyż założyłem je wieki temu i oczywiście nie zapisałem na których założyłem indeksy :/
zobacze jaki efekt to bedzie mialo u mnie. Z tym ze FULLTEXT nie dziala
LMS nie używa wyszukiwania pełnotekstowego, więc nic to nie da.
A szukanie klienta po imieniu, nazwisku, adresie ?
Przemysław 'Repcio' Gubernat wrote:
zobacze jaki efekt to bedzie mialo u mnie. Z tym ze FULLTEXT nie dziala
LMS nie używa wyszukiwania pełnotekstowego, więc nic to nie da.
A szukanie klienta po imieniu, nazwisku, adresie ?
Widzę, że następnego trzeba doedukować ;)
http://dev.mysql.com/doc/refman/5.0/en/fulltext-search.html
Chyba że ja czegoś nie wiem, nie używam wyszukiwania pełnotekstowego. LMS używa LIKE do wyszukiwania.
On Mon, Aug 03, 2009 at 11:26:14AM +0200, A.L.E.C wrote:
Przemysław 'Repcio' Gubernat wrote:
zobacze jaki efekt to bedzie mialo u mnie. Z tym ze FULLTEXT nie dziala
LMS nie używa wyszukiwania pełnotekstowego, więc nic to nie da.
A szukanie klienta po imieniu, nazwisku, adresie ?
Widzę, że następnego trzeba doedukować ;)
najwidoczniej ;-)
http://dev.mysql.com/doc/refman/5.0/en/fulltext-search.html
Chyba że ja czegoś nie wiem, nie używam wyszukiwania pełnotekstowego. LMS używa LIKE do wyszukiwania.
Czyli "zwykły" indeks wystarczy.
Poza tym, LMS nie wykorzystuje zalet innodb i nie widzę powodu żeby go używać (z LMSem). Zmigruj do postgresa.
-- Aleksander 'A.L.E.C' Machniak http://alec.pl gg:2275252 LAN Management System Developer http://lms.org.pl Roundcube Webmail Project Developer http://roundcube.net
A jak łatwo zmigrować do postgresa ? :-)
pozdrawiam Dariusz Kowalczyk
!DSPAM:4a76cb8e223881913455709!
Dariusz Kowalczyk - Webvisor pisze:
Poza tym, LMS nie wykorzystuje zalet innodb i nie widzę powodu żeby go używać (z LMSem). Zmigruj do postgresa.
-- Aleksander 'A.L.E.C' Machniak http://alec.pl gg:2275252 LAN Management System Developer http://lms.org.pl Roundcube Webmail Project Developer http://roundcube.net
A jak łatwo zmigrować do postgresa ? :-)
Latwo nigdy nie bedzie, ale jak ja laik w dziedzinie php i baz danych sobie poradzilem to i Wy dacie rade :P Jako dobra rade podpowiem by zrobic porzadne backupy. A jak ktos laik jak ja to nawet backupy z roznym kodowaniem danych.
uczestnicy (5)
-
A.L.E.C -
Andrzej Banach -
Dariusz Kowalczyk - Webvisor -
Jaroslaw Czarniak -
Przemysław 'Repcio' Gubernat