Zrobilem parę experymentów i wyszło nieco ciekawych rzeczy. Linijka z db_orders_products przed: a:6:{s:8:"iElement";s:1:"1";s:6:"iOrder";i:100;s:8:"iProduct";s:1:"1" ;;s:9:"iQuantity";s:1:"2";s:6:"fPrice";s:6:"199.89";s:5:"sName";s:6:&q uot;Argent";} i jeszcze raz takie samo zamówienie po kilku zmianach w kodzie: a:6:{s:8:"iElement";i:6;s:6:"iOrder";i:101;s:8:"iProduct";i:1;s:9:"iQuantity"; i:1;s:6:"fPrice";d:199.89;s:5:"sName";s:6:"Argent";}
Różnice: 1. Kilkanaście bajtów mniej (przy setkach i tysiącach zamówień ma to swoje znaczenie); 2. Deczko szybsze przy czytaniu: liczby (integer i float) są już w swoim formacie; 3. Owszem, nieco wolniejszy zapis - trzeba wymusić format liczb przed ich serializacją - ale są to jednorazowe milisekundy przy składaniu zamówienia. Przy listingu zamówień w panelu admina - same korzyści.
Warto wrzucić floatval() czy int() na odpowiednie zmienne przed ich serializacją.
boboo - wykorzystanie serializacji było wg mnie krokiem milowym w Quick.Cart
Kiedys pisałem. że strona z częsciowa serializacją (products i files) wytrzymywała 10 tys. unikalnych wizyt w ciągu dnia. Jeszcze raz podkreslam: wizyt a nie odsłon. I to nie jest strona testowa ale "prawdziwa" cały czas działajaca
Zawsze miałem "bzuma" na punkcie szybkości i wydajności QC.
Teraz QC jest szybszy i wydajniejszy ale oczywiście oczywiście mozna coś ulepszyc. Oszczednosci szukałbym bym jednak nie w zamówieniach ale w samych produktach. Moze sa branże w których 1000 wizyt = 1000 zamówień (i tu im zazdroszczę) Normalnie zeby uzyskac 1000 zamówień to trzeba "przezyc" 10-100tys wizyt a czasami jezscze wiecej.
Kiedyś , na początku serializacji Quick.Carta zrobilem 2 testy dla 1 tys i 16 tys produktów Produkt testowy miał w krótkim opisie 35 znaków a w pelnym 1300 znaków
1000 produktów: time 0,025s memory ok 8MB (wg mojej oceny to ok 3 razy mniej niz potrzebuje np Wordpress) 16000 produktów: time: 0,15s, memory ok70MB (tu jeszcze miałem duzy zapas ale sa serwery z memory_limit 32MB)
Krótko mówiac. Nie neguje szukania oszczedności w każdym miejscu ale przeżyjmy najpierw najazd klientów a dopiero potem martwym sie co zrobić z zamówieniami.
Kiedy to, co opisałem daje plus tylko adminowi. Dziwnym trafem tylko db_orders_products miał kilka "fałszywek" (integer i float zapisywane jako string). No, jeszcze db_products ma pole mPrice jako string, ale jest przewidziane też do zapisu textu. Pracowałem kilka lat z gościem, który był współtwórcą www (podczas jego kariery w CERN). On mnie też nauczył oszczędności bajtów :-) A na ten problem zwróciłem uwagę tylko z powodu tego tematu: http://opensolution.org/Quick.Cart/forum/numeracja-zlecen,7853.html gdzy zmieniając numer (jakby nie patrzeć liczba całkowita) ostatniego zamówienia musiałem zmienić deklarację długości stringu. s:6:"iOrder";s:1:"9"; aby przerobić na "100", trzeba było zadeklarowć s:3:"100";
Owszem, dzięki serializacji "zapieprza jak mały samochodzik" ale... http://de.php.net/manual/de/function.serialize.php pierwszy komentarz zaczynający się od: "please! please! please!" W szczególności jego ostatnie zdanie.
1. Konieczność deklaracji długości stringu to już "urok" serializowanej bazy. Cos za cos 2. "Ostatnie zdanie"na forum php ? Problem wyolbrzymiony. Instalujac QuickCart nie planuję "za miesiac" migrowac np do osCommerce, a jesli juz, to można zaadaptować funkcje exportu danych itp.
Toż ja nie pisałem o konieczności deklaracji długości stringa, tylko "zapytałem bez pytajnika" dlaczego coś takiego jak np. 'iOrder' jest zapisywane jako string, a nie jako integer.
Najnormalniej w świecie zapytam: dlaczego? Tym bardziej, że w db_orders 'iOrder' jest zapisany jako "i" - integer, a w tylko w db_orders_products jako "s" - string
Widze, ze ciekawa dyskusja sie zrobila. A przyczyna pewnie lezy w tym, ze nie ustawilismy po prostu dla iOrder wymuszenie inta. Dzieki za sugestie.
Fakt, ze te kilka znakow nie zmienia wiele bo znajac zycie przy wartosci krytycznej z powodu tych znakow przepelnienie pamieci bedzie przy 15 000 zamowien a nie 15 050.
Jednak warto optymalizowac i tak tez sie zrobi w nastepnej wersji.
boboo, to był tylko przykład (ale prawdziwy), ze klienci maja czasami nietypowe zachcianki. Tu klient chce numerację dzienną ale prawde mówiac nie wiem czy to jest wygodny wariant. Moze przy duzej ilosci zamówień. Detal, hurt i jeszcze jakas trzecia opcja. Czyli "numer zamówienia" będzie sie składał z 3 zmiennych: numer kolejny + data + opcja. Zobaczymy.
Osobiście nie robiłbym tego w jednym stringu. Dodałbym tylko jedno pole na /hurt/detal/trzeciaopcja. Owszem, przy wyświetlaniu na liście czy potwierdzeniu zamówienia połączyć. Ogólnie: bułka z masłem :-)
Troszkę nie w temacie... Czy macie może bazę danych (roboczą) do » freeware Quick.Cart v5.x z 1000 albo więcej produktów? Potrzebował bym do podmiany w moim nowo powstającym sklepie, aby przetestować działanie sklepu i serwera. Z góry dzięki
