Wydajność Firebird + PHP procesor i7 Linux 64bit

witam Was,

mam taki problem z wydajnością PHP+Firebird i nie wiem jak sobie z tym poradzić. Może dla jasności opiszę w podpunktach:

1. Maszyna Linux 32bit z procesorem Core 2 Quad, PHP wersja 5.2.8, Firebird Classic wersja 1.5.6, dysk SSD, Apache2, Mysql,
2. Maszyna Linux 64bit z procesorem i7 Haswell, PHP wersja 5.4.20, Firebird Classic wersja 1.5.6, dysk SSD, Apache profork, MariaDB

a) Jak uruchomię na maszynie 1 aplikację w PHP to działa szybko i wykazuje pełne obciążenie procesora(rdzeni).
b) Jak uruchomię na maszynie 2 aplikację w PHP to działa wolno i wykazuje obciążenie procesora (rdzeni) rzędu kilku %.
c) PHP+Mysql działa błyskawicznie na maszynie 2, na 1 względnie.
d) Eksperymentalnie uruchomiłem Firebird i bazy Firebirda na maszynie 2, a aplikację PHP na maszynie 1, ustanawiając połączenie do baz Firebirda na maszynie 2 - działa błyskawicznie.
e) Eksperymentalnie uruchomiłem Firebird i bazy Firebirda na maszynie 1, a aplikację PHP na maszynie 2, ustanawiając połączenie do baz Firebirda na maszynie 1 - działa błyskawicznie.

Podsumowanie:
Wychodzi na to, że PHP i Firebird na jednej maszynie z procesorem i7 nie działa sprawnie. Przeniesienie baz Firebird na inny dysk, w obrębie tej samej maszyny tez nic nie daje. Zapytanie w PHP do bazy firebirda, które wykonuje się na maszynie 1 (o słabszych parametrach) wykonuje się szybciej o 5-10 razy niż na maszynie nowszej. Za to PHP+Mysql wykonuje się szybciej o 6 razy.
Skrypt PHP jest to select bez JOIN-ów chodzący w pętli i dla 100 razy trwa to 65 sekund na maszynie nowej, na starej jakieś 5 sekund.

Ogólnie sytuacja jest związana z przenosinami na nowszy sprzęt i o ile PHP+Mysql działa wydajniej, to PHP+Firebird mniej wydajnie.

Poza tym jak do bazy jest ścieżka do innego kompa to na nowym działa również szybko, a na localhost wolno.

Proszę o pomoc co może być przyczyną i co zrobić aby to płynnie chodziło?

Do poczytania:
http://wildcat.huzar.pl/serwis/pomoc/index.php?a=powolna-praca

zrób testy z pod jakiegoś klienta sqlowego dla FB, choćby tego, który się instaluje z FB. Przede wszystkim trzeba porównać plany zapytania.

dziekuje za odpowiedzi:

rafal_w - oj czytałem wielokrotnie, drobiazgowo zastosowalem i nic z tego, rezultat ten sam,,

abrakadaber - a jak taki test zrobic - może masz link do instrukcji "krok po kroku"? przyznam, ze nie jestem biegly, a do czynienia z tym mam raz na "wymianę na nowszy sprzęt", czyli w tym przypadku 6 lat temu,

z rzeczy ciekawych co znalazlem w necie było opisane, ze:

firebird 1.5.6 - problem jest, że 32bit firebird nie potrafi racjonalnie korzystać z pamięci systemu 64bit, ale czy to prawda, chodzi o firebird cache, jak to ewentualnie ominąć? czy da się ominąć?

chodzi o to, żeby wziąć to zapytanie, które Ci muli na i7 i odpalić je nie z PHP ale z programu (nie pamiętam jak się on nazywa, ale pewnie będzie w nazwie SQL) i zobaczyć czy też będzie wolno. Jeśli tak to wiesz, ze to nie połączenie PHP-FB jest przyczyną. Wtedy możesz wyświetlić plan zapytania (w dokumentacji masz) na obu maszynach TEGO SAMEGO ZAPYTANIA i NA TYCH SAMYCH DANYCH, wkleić np. tutaj i ktoś rzuci okiem i powie co o tym sądzi

Przetestuj wszystko osobno.

• komputer: system plików, CPU, RAM
• sam PHP
• same bazy (przez lokalnego klienta bazy: batch lub Stored Proc)

Potem, jeśli wyniki są zgodne z oczekiwaniami, możesz przetestować interfejsy - np. PHP z Firebird.
A potem samą aplikację.
Firebird 32-bitowy może nie wykorzystywać 64-bitowej maszyny, może być trochę wolniejszy na niej, ale nie aż tak.
Chyba że mają jakiegoś solidnego buga.

tak, jest ten program instalowany z Firebirdem, nazywa się isql tylko jak to zrobić, bo mam zapytanie w pliku php - ale ono idzie w pętli, i każde wykonanie tego zapytania zajmuje 0,04s na nowej maszynie, tylko, że petla przechodzi np. 1000 razy, pomijam fakt, że program pisany w PHP ma takich zapytań sporo w różnych modułach, poki co wykonałem veryfikację cache Firebirda i wyglada to tak:

CON> Current memory = 624128
CON> Delta memory = -4784
CON> Max memory = 648104
CON> Elapsed time= 0.00 sec
CON> Cpu = 0.00 sec
CON> Buffers = 75
CON> Reads = 2
CON> Writes = 2
CON> Fetches = 2

czy to daje jakiś pogląd?

ad.
Przetestuj wszystko osobno.

• komputer: system plików, CPU, RAM - wszystko nowe, linux tez nowa instalacja (probowalem i Xampp i instalacja wszystkiego osobno)
• sam PHP - to nie wiem jak przetestowac, ale PHP+Mysql - błyskawica, benchmark apache - błyskawica,
• same bazy -** bazy chodzą w aplikacji producenta programu błyskawicznie,**

Potem, jeśli wyniki są zgodne z oczekiwaniami, możesz przetestować interfejsy - np. PHP z Firebird - jak to przetestować?
A potem samą aplikację. - aplikacja działa dobrze.
Firebird 32-bitowy może nie wykorzystywać 64-bitowej maszyny, może być trochę wolniejszy na niej, ale nie aż tak. -** a jednak, zwróć proszę uwagę, że na dwóch PC - na jednym PHP na drugim Firebird - działa błyskawicznie.**

Chyba że mają jakiegoś solidnego buga - kod nie jest idealny, ale jeśli na nowym sprzęcie jest 10razy wolniejszy niż na starym, przy czym nie obciąża rdzeni wykonując zapytanie to coś nie tak, coś czytałem o przeskakiwaniu wątków, ale Firebird Classic podobno to eliminuje.

emaniek napisał(a):

ad.
Przetestuj wszystko osobno.

• komputer: system plików, CPU, RAM - wszystko nowe, linux tez nowa instalacja (probowalem i Xampp i instalacja wszystkiego osobno)

Chodzi o test wydajności. Spróbuj tego: https://romanrm.net/dd-benchmark

emaniek napisał(a):

• sam PHP - to nie wiem jak przetestowac, ale PHP+Mysql - błyskawica, benchmark apache - błyskawica,

Spróbuj np. tego: http://www.php-benchmark-script.com/

emaniek napisał(a):

• same bazy -** bazy chodzą w aplikacji producenta programu błyskawicznie,**

Wygeneruj skrypt SQL wykonujący 1000 razy to samo zapytanie z różnymi parametrami i uruchom lokalnie na obu maszynach np. tym:
http://www.flamerobin.org/

emaniek napisał(a):

Chyba że mają jakiegoś solidnego buga - kod nie jest idealny, ale jeśli na nowym sprzęcie jest 10razy wolniejszy niż na starym, przy czym nie obciąża rdzeni wykonując zapytanie to coś nie tak, coś czytałem o przeskakiwaniu wątków, ale Firebird Classic podobno to eliminuje.

To że nowy komp (nr 2) się nudzi może oznaczać że bardzo się "męczy" w obszarze I/O lub bazy danych. Być może występuje jakiś problem konfiguracyjny interfejsu PHP do Firebird.

Przykład testu PHP + Firebird (na końcu):
http://www.firebirdsql.org/file/documentation/papers_presentations/Firebird_PHP_Linux.pdf

testy wydajnosci przede mną, zainstalowałem to samo na Linux 32 bit - niestety to samo, czy moze byc winny sterownik PHP do obsługi bazy, baza jest 1.5.6, a sterownik PHP do interbase 2.5, czy to moze byc problem?

wrzucam czesc wynikow z testów, resztę robię:

dd bs=1M count=256 if=/dev/zero of=test
256+0 przeczytanych recordów
256+0 zapisanych recordów
skopiowane 268435456 bajtów (268 MB), 0,437731 s, 613 MB/s

dd bs=1M count=256 if=/dev/zero of=test; sync
256+0 przeczytanych recordów
256+0 zapisanych recordów
skopiowane 268435456 bajtów (268 MB), 0,450951 s, 595 MB/s

dd bs=1M count=256 if=/dev/zero of=test oflag=dsync
256+0 przeczytanych recordów
256+0 zapisanych recordów
skopiowane 268435456 bajtów (268 MB), 2,33877 s, 115 MB/s

dd bs=1M count=256 if=/dev/zero of=test oflag=dsync
256+0 przeczytanych recordów
256+0 zapisanych recordów
skopiowane 268435456 bajtów (268 MB), 2,32923 s, 115 MB/s

z tej samej maszyny:

---

| PHP BENCHMARK SCRIPT |

Start : 2014-06-04 1422
Server : [email protected]
PHP version : 5.4.20
Platform : Linux

test_math : 0.925 sec.
test_stringmanipulation : 0.906 sec.
test_loops : 0.602 sec.
test_ifelse : 0.373 sec.

Total time: : 2.806 sec.

z innej maszyny w sieci:

---

| PHP BENCHMARK SCRIPT |

Start : 2014-06-04 1444
Server : [email protected]
PHP version : 5.4.20
Platform : Linux

test_math : 0.913 sec.
test_stringmanipulation : 0.912 sec.
test_loops : 0.602 sec.
test_ifelse : 0.374 sec.

Total time: : 2.801 sec.

wykonanie prostego selecta FlameRobin, zajmuje dużo czasu i jesli idzie on w pętli 1000 razy to łatwo policzyć, że zajmuje 67 sekund! :

1009 fetches, 0 marks, 0 reads, 0 writes.
0 inserts, 0 updates, 0 deletes, 0 index, 494 seq.
Delta memory: 0 bytes.
Total execution time: 0,073s
Preparing query:
SELECT SUM (ITEM_AMOUNT) ITEM_AMOUNT FROM WAREHOUSE_STATES
Prepare time: 0,067s
Field #01: . Alias:ITEM_AMOUNT Type:NUMERIC(18,3)
PLAN (WAREHOUSE_STATES NATURAL)

Executing...
Done.

i na starej maszynie przez LAN z Flame Robin z innej maszyny:

1009 fetches, 0 marks, 0 reads, 0 writes.
0 inserts, 0 updates, 0 deletes, 0 index, 494 seq.
Delta memory: 0 bytes.
Total execution time: 0,039s
Preparing query:
SELECT SUM (ITEM_AMOUNT) ITEM_AMOUNT FROM WAREHOUSE_STATES
Prepare time: 0,022s
Field #01: . Alias:ITEM_AMOUNT Type:NUMERIC(18,3)
PLAN (WAREHOUSE_STATES NATURAL)

proszę o komentarz?

to jest powiedzmy średnia dla 1000 przebiegów zapytania, waha się na maszynie nowej od 0,062s do 0,086s - podałem wynik jakikolwiek ze środka, na starym mam problem z zainstalowaniem Flamerobin, ale tam jest tez wyciety czas jeden z tysiąca i nie pierwszy - tyle ze przez siec LAN - z nowego komputera - a mimo ze przez LAN (bo Flemrobin jest na nowym komputerze) to czas jest 3-4 razy lepszy.

Porównuj zbliżone funkcjonalności (np. Flamerobin przez LAN na obu maszynach), ale z tego co piszesz to masz problem z samym Firebird, PHP tu nie ma nic do rzeczy.

Zajrzyj tutaj:
http://www.slideshare.net/ibsurgeon/resolving-firebird-performance-problems
http://ibexpert.net/ibe/index.php?n=Doc.Optimization

wyniki zadziwiające, ale potwierdzają poprzednią sytuację: SQL z sieci LAN dla systemu 64 bit, cwiczylem rowniez na nowym 32bit, ale z nowym procesorem i7:

• do starego komputera: 0,036s-0,052s
• do nowego komputera: 0,034s-0,052s
  Znaczy to, że bazy są dla sieci LAN wydajne tak samo.

Powstaje problem dlaczego baza lokalnie odpowiada wolniej niż zdalnie?

127.0.0.1 - rezultaty takie same jak z localhost, pytanie czy baza nie odpowiada, czy sprzęt wstrzymuje, błądzi, gubi?

a dlaczego masz przedpotopową wersję FB??

niestety producent aplikacji ksiegowej, uzywanej przez kilka lat nie przewiduje migracji do wyższej wersji FB w najbliższym czasie

dzisiaj zainstalowałem wszystko na opensuse 13.1 32 bit i na zestawie z inną płytą i procesorem Core 2 Quad (czyli jak na starym PC, efekt z wydajnością FB jest taki sam, czyli problem, czy może to być wina linuxa, że menadżer procesów coś żle przydziela, albo format plików na dysku coś żle przydziela?

Skoro działa wolno zapytanie z konsoli przez isql to chyba coś nie tak musi być z kompatybilnością FB 1.5.6 z nową wersją Opensuse? Czy macie jakieś inne pomysły?