Serializacja bazy

boboo

Avatar: boboo

2012-05-12 14:40

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ą.

» Quick.Cart v5.x

qc-plugins.kimla.de

openzibi

Avatar: openzibi

2012-05-12 20:18

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.


-------------------------------------------------------
hosting-domeny-strony - http://www.rhh.pl

openzibi

Avatar: openzibi

2012-05-12 20:43

Mała korekta. Pierwszy test to 2000 a nie 1000 produktów


-------------------------------------------------------
hosting-domeny-strony - http://www.rhh.pl

boboo

Avatar: boboo

2012-05-13 06:39

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.

qc-plugins.kimla.de

openzibi

Avatar: openzibi

2012-05-13 08:53

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.

-------------------------------------------------------
hosting-domeny-strony - http://www.rhh.pl

boboo

Avatar: boboo

2012-05-13 09:33

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.

qc-plugins.kimla.de

openzibi

Avatar: openzibi

2012-05-13 10:05

Może są jakieś plany związane ze sposobem prezentacji numeru zamówienia. Zgadzam się, ze trzeba walczyć o każdy bajt ale tu zostawiłbym string.

-------------------------------------------------------
hosting-domeny-strony - http://www.rhh.pl

boboo

Avatar: boboo

2012-05-13 10:43

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

qc-plugins.kimla.de

openzibi

Avatar: openzibi

2012-05-13 11:03

W szkole Pani pytała: "Co poeta(programista) miał na myśli"
Moja odpowiedź była zawsze jednakowa: "nie wiem, proszę zapytać poety"

To był mój post nr 2012/05/13/266/ZIBI :)


-------------------------------------------------------
hosting-domeny-strony - http://www.rhh.pl

boboo

Avatar: boboo

2012-05-13 11:26

Przecież nie zapytałem, co OS miał na myśli, tylko dlaczego TY zostawiłbyś string.

qc-plugins.kimla.de

treewood (OpenSolution)

Avatar: treewood

2012-05-14 06:33

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.

openzibi

Avatar: openzibi

2012-05-14 08:17

A ja mam klienta, który zastanawia sie nad formatem zapisu zamówienia
266/2012/05/13/HURT


-------------------------------------------------------
hosting-domeny-strony - http://www.rhh.pl

boboo

Avatar: boboo

2012-05-14 09:19

Czy te przykładowe 266 zacznie od zera, gdy data przeskoczy na 14 maja?
Czy ma być też opcja /DETAL, czy tylko /HURT?

qc-plugins.kimla.de

openzibi

Avatar: openzibi

2012-05-14 09:48

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.

-------------------------------------------------------
hosting-domeny-strony - http://www.rhh.pl

boboo

Avatar: boboo

2012-05-14 10:06

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 :-)

qc-plugins.kimla.de

selekcjoner

Avatar: selekcjoner

2012-06-15 18:50

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

simlution.org

Back to top
about us | contact