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....
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ś?
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 :(
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.
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
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.
uczestnicy (5)
-
A.L.E.C -
Andrzej Banach -
Dariusz Kowalczyk - Webvisor -
Jaroslaw Czarniak -
Przemysław 'Repcio' Gubernat