Wkopanie źródeł do RAMu Opcje

[pieto]

Hej, dawno mnie tu nie było, wiec rzucę coś ciekawego.

Potrzebuję zoptymalizować jeden większy portal i tak kombinując wymyśliłem aby źródła ba! w zasadzie cały serwis
przerzucić do RAMu, nie wiem od czego zacząć wiec pytanie.

Jakieś koncepcje ?

z góry dzięki za podpowiedzi..
pozdrawiam

[!*!]

Chcesz cały portal wrzucić do ramu? mocne

A tak poważniej to zainteresuj się memcached.

[pieto]

Ano pierwsze co mi przyszło to memcached i rewrite zrodel rzutowany na imageMagica z cachem kierowany do RAMu,
Opcja nr - łatwiejsza w teorii ale nie wiem czy idzie - Dowiazanie symboliczne rzutowane na RAM..

Jakies inne pomysly ?

[Uriziel01]

Jest to niestety niezbyt wykonalne w PHP.
Ale tutaj masz liste dostepnych 'akceleratorów', działaja one na zasadzie przechwycenia wygenerowanego OPCode'u z PHP który potem jest zapisywany do pliku, daje to niesamowity boost bo tak na prawdę większośc aplikacji traci najwięcej czasu na interpretację kodu w PHP do kodu maszynowego.
Tutaj masz liste najpopularniejszych akceleratorów dla PHP:
http://en.wikipedia.org/wiki/List_of_PHP_accelerators
Możesz też zainteresować się HipHop dla PHP od twórców Facebook'a, jest to inne podejście, skrypt jest tam interpretowany i zmieniany na 'wysoce wydajny' kod Cpp, ale tak po prawdzie to ten 'wysoce wydajny' kod ma także swoje wady i luki, w pewnych zastosowaniach może okazać się nawet sporo mniej wydajny niż samo PHP (istnieje kilka ciekawych artykułów na ten temat).

Jeżeli naprawdę interesujesz się wykonywaniem kodu w 'pamięci RAM' jak to zgrabnie ująłeś zainteresuj się implementacją protokołu HTTP dla Cpp (jest kilka FW do tego celu, niestety żaden z nich nie jest pozbawiony wad), można w ten sposób wykonać demona który będzie jak desktopowa aplikacja obsługiwał nadchodzące od serwera zapytania, ale:
1)Poziom trudności stworzenia takiej aplikacji jest niewspółmiernie większy niż pisanie w PHP
2)Ponownie w pewnych zastosowaniach może to doprowadzić do zmniejszenia wydajności zamiast jej wzrostu.

Ten post edytował Uriziel01 9.12.2011, 10:11:50

[pieto]

Dzięki za info,
Właśnie pomysł zrodził przy okazji implementacji akceleratora, faktycznie w dużej części rozwiązuje sporo problemów.
Jednak nie do końca mój główny - ograniczenie ilości requestów do serwera, tu uprzedzam z góry ze techniki łączenia cssów, js i grafik w sprity zaimplementowałem ale dalej dysk ledwo zipie..
Czy niezbyt możliwe z poziomu PHP, hm nie sądze.

Pod warunkiem że źródła będą dynamicznie generowane lub pseudo-generowane (można przepuścić przez skrypt, np cachujacy do pamieci) powinno się dać,
tak czy siak znajdę chwilę to pokombinuję.
Problemem zdaje się być baza danych chociaż tu widzę rozwiązanie na poziomie samej bazy - tworzenie zmapowanych widoków

[Uriziel01]

Oczywiście że się da, tworząc jakies potwory w stylu popen(). Tylko po co? Na 99% będzie to miało mniejsza wydajność niż zwyczajny kod w PHP, poprostu skrypty PHP cierpią z powodu ograniczonej obsługi standardowych portów WEJ/WYJ.
Ale czysto TEORETYCZNIE widze to tak:
Pracujący 24H demon który czeka na otwarcie sie procesu który jest tworzony przy kazdym requeście od klienta, ma on już wczytaną grafike, css, szablony, i18n i co tam sobie jeszcze wymarzysz. Po otwarciu procesu, odbiera od niego argumenty, przetwarza je, generuje kod, przesyła go do procesu-klienta a ten natychmiast wysyła go zleceniodawcy. Ale powiedz mi w jaki sposób chcesz tutaj rozwiązać problem wielu jednoczesnych requestów ? Niestety nie możemy uzyc wielowątkowości, pozostaje tylko odpalić kilka daemonów, co WYDATNIE zwiększy zużycie pamięci RAM. Potem pozostaje problem balansowania ilosci zapytań, konfliktów dostepu etc. etc. etc.
I powiedz mi, czy warto ?

EDIT:
Było by dużo prościej przy aktywnych requestach do daemon'a, ale niestety w PHP (wg. mojej obecnej wiedzy) brak mechanizów na to pozwalających, stąd też ten pasywny styl połączeń.

Ten post edytował Uriziel01 9.12.2011, 10:51:59

[!*!]

Teoretycznie ilość requestów możesz ograniczyć przez ajax, choć to zależy od budowy całego portalu.

[redeemer]

1) cachowanie zapytan do bazy
2) opcode caching
3) KeepAlive w apache na On

Co do bazy, jeżeli masz dużo zapytań ze statusem "Using filesort" to quick-fixem bedzie zrobienie ramdisku i ustawienie go w konfigu jako tmpdir dla mysql. No i popraw/zoptymalizuj zapytania/indeksy

[by_ikar]

Możesz też dokupić jakiś średni serwer, postawić na nim nginx'a i z niego serwować całą treść statyczną. To samo zresztą możesz zrobić z bazą danych, przenieść na inny serwer. Możesz też zwiększyć cache bazy, wtedy o ile masz dużo pamięci ram, to cała baza mogłaby być nawet trzymana w pamięci. Możesz również wymienić dysk, podłączyć kolejny i spiąć go w raid. Możesz podłączyć dysk ssd. Możliwości jest bardzo dużo, wszystko zależy w głównej mierze od ilości gotówki jaką posiadasz.

Sprawa wrzucenia całego serwisu do pamięci ram, jest problematyczna. Z samą optymalizacją kodu dobrze radzą sobie akceleratory i wątpię aby wrzucenie do pamięci całego serwisu było mniej pracochłonne i efektywniejsze od akceleratorów.

O ile ten serwis jest napisany oop, mógłbyś przebudować autoloadera, który by sprawdzał czy w pamięci (apc) przetrzymywany jest obiekt i go zamiast includować, pobierać z pamięci. W sumie mogłoby się to wydawać dość ciekawe.

Ten post edytował by_ikar 9.12.2011, 11:56:15

[Uriziel01]

W jakiś dziwny sposób ta dyskuja kompletnie zmieniła swój obrót, ale w porządku

No pewnie, jak ma za dużo kasy może nawet postawić CDN'a ale chyba jednak autor miał coś kompletnie innego na mysli. Ma jeden serwer, potrzebuje zoptymalizować kod tak aby nie być zmuszonym dokupic kolejne maszyny.

[by_ikar]

W jakiś dziwny sposób ta dyskuja kompletnie zmieniła swój obrót, ale w porządku

No pewnie, jak ma za dużo kasy może nawet postawić CDN'a ale chyba jednak autor miał coś kompletnie innego na mysli. Ma jeden serwer, potrzebuje zoptymalizować kod tak aby nie być zmuszonym dokupic kolejne maszyny.

No wiesz, niektórych rzeczy się nie da bardziej zoptymalizować, zasoby serwera nie są nieskończone i swoje granice mają. Nie napisał ile tych odwiedzin ma oraz jaki ma serwer. Wróżbitą raczej nie jestem, więc dostał ogólne informacje, tak samo ogólne które dostałem i ja.

[pieto]

EE, nie potrzebnie tak daleko sięgamy,
Owszem przerzucanie serwisu bezpośrednio z PHP jest dość uciążliwe, ale nie chodzi skrocenie czasu wykonywania php'a,
a ograniczenie udziału dysku .

Nie wiem dlaczego zapomniałem o starej jak świat metodzie tworzenia RAMdysku..
ot, http://members.fortunecity.com/ramdisk/RAMDisk/ramdriv.htm

+ cachowanie na ramdysk powinno rozwiązać mój problem.




Dla ciekawskich benchmark
http://fiehnlab.ucdavis.edu/staff/kind/Col...-benchmarks.pdf

[Uriziel01]

Poprostu wow. jakas czarna dziura sprawiła że kompletnie zapomniałem o czyms czego używałem jeszcze kilka lat temu sam we własnym domowym zaciszu. Faktycznie jest to najszybsze i najprostsze możliwe rozwiązanie w kwestii 'przeniesienia do RAMu' skryptów PHP. A także przechowywania tego statycznego contentu.

Ten post edytował Uriziel01 9.12.2011, 13:25:43