@rashid czy mógłbyś polecić coś naprawdę dobrego?

Scalable Internet Architectures to bardzo fajna pozycja przegladowa z zagadnien webowych. Daje do myslenia niektorymi rozwiazaniami i jest solidna podstawa do szukania dalszej wiedzy w necie.

Kopalnia ciekawych przemyslen i pomyslow jest publicznie dostepna lista artykulow opublikowanych przez Google'owcow, ale trzeba wylapac interesujace zagadnienia.

dziękuje wygląda ciekawie - na pewno przeczytam.
Niestety po polsku jest dostępna tylko Skalowalne witryny internetowe Budowa skalowanie i optymalizacja aplikacji internetowych nowej generacji - w której jest zaledwie kilkadziesiąt stron o temacie tutaj poruszanym

Jest jeszcze Wydajne witryny internetowe. Przyspieszanie działania serwisów WWW. Nie jest to moze ksiazka bezposrednio o tworzeniu skalowalnej architektury, ale opisuje sporo technik, ktore powinno sie zastosowac zanim sie wpakuje w probe skalowania rozwiazania.


Jesli ktos chcialby sprawdzic mozliwosci baz danych nie opierajacych sie na relacjach, to akurat pojawil sie ciekawy post przegladowy

Przepraszam, ze tego trupa odgrzebuję, ale miałbym coś do powiedzenia w tym temacie. Delikatnie.

Pierwsze i zasadnicze jestem przede wszystkim programistą takich technologii jak ColdFusion czy ASP.NET i tam loadbalancing nie jest problemem. Pythona nie dotykałem więc nie wiem. Ale wracając do brzegu Opiszę jak to wygląda na serwerze ColdFusion i jakie rozwiązanie zastosowalem.

ColdFusion:

1. Tworzony jest plik application.cfm i jeżeli taki istnieje jest dołaczany do każdego wywołania - dzięki temu zmienne aplikacyjne mogą być trzymane w jednym miejscu i mogą być WSPÓLNE dla wszystkich wywołań skryptu, przez dowolnego użytkownika, a to oznacza, że mamy ponad użytkownikowe rozwiązanie.
2. Istnieje coś takiego jak Client Scope - takie zmienne sesyjne dla klienta, dla przeglądarki. Jak to jest rozwiązane nie mam bladego pojęcia. Ważne że przeglądarka - ta sama instancja jest rozpoznawalna. Wewnątrz jest utrzymywany stan sesji i na wywołaniu z tego samego klienta stan jest odwtarzany.
3. Trzeba dodać, że jak się skorzysta ze zmiennych sesyjnych serwera Java (który jest pod spodem ColdFusion) to można clustrować dowoli serwery, a one sobie ze sobą poradzą

Napotkałem ten problem w jednym grubym projekcie intranetowym na serwerze PHP. Ponieważ za specjalnie nie potrafiłem sobie poradzić, więc podszedłem do tematu z innej strony. Pierwsze opisałem sobie czego mi w PHP brakuje z lepsiejszych (no cóż wygoda programowania CF czy .NET nie do porównania z PHP ^^) rozwiązań. Wypisalem sobie i się okazało, że wcale nie jest tak źle ^^. Cold Fusion daje możliwość składowania ciastek dla klienta po stronie serwera, a u klienta leży jedna zmienna z id ciastka i CF jakoś to robi, ze rozpoznaje że to ten user (klient) był.

Zakasałem rękawy i przeryłem stado dokumentacji do PHP i .NET i do tworzenia modułów do PHP. Po miesiącu prób i błędów udało mi się wyprodukować dll'kę która zwracała hello world! Ale to już był gotowy przepis na rozwiązanie moich problemów. Jak się udało wypluć hello world to da się cokolwiek zrobić. Wykonałem więc dll'kę, która odczytywała zmienne sesji z bazy danych i wrzucała je do skryptu PHP. Voile'a - między serwerowe rozwiązanie Co prawda potrzebna była taka maszyna, która to w bazie utrzyma, wysokiej dostępności i na pewno nie MyShitQL (sorry jeżeli kogoś urażam, ale to moja opinia). I znalazła się. Jakiś tam Echange stał, który tylko pocztę serwował z 16 procesorów oO. SQL Server Workgroup się znalazł i zaczeło gadać.

Pozostała jeszcze kwestia rozpoznawania klienta. W tym wypadku było to o tyle prostsze, że to był intranet, więc ciastko zapodałem i dowidienia.

Zapytacie na pewno jak z wydajnością. No cóż. Okazało się, że początek nie był radosny. Opóźnienie skryptu z jednej maszyny o jakieś 200%. Niestety, ale to mnie na chwilę znowu zatrzymało. Okazało się, że problemem stało się dochodzenie do zmiennych sesji $_SESSION przez dll. Znowu drobna przebudowa dll i extend replace na skrypty php ze zamianą $_SESSION na $_SESS (i przestawinie się w głowie na takie używanie zmiennych).

Kolejna sprawa, że stało się dla mnie niezbędne korzystanie ze zmiannych aplikacyjnych globalnych dla wszystkich użytkowników. TO akurat było prosto rozwiązać.

Napisałem skrypcik ładujący dane do tabeli $_APP (znowu naleciałości z coldka) i dodalem .htaccess z wpisem:

php_value auto_prepend_file "/sciezka/do/application.php"

oczywiscie, że próbowało dopisywać do każdego pliku. Proste rozwiązanie:

if(!$_APP)

i już. Mam zmienne aplikacyjne, mam załatwiony load balancing i mam sprawny intranet - kodu dll nie zapodam - kupę kapuchy za to położyli.

Na zakończenie tego wtrącenia trzeba dodać parę uwag:

1. Jak chcesz tak zrobić wybierz DOBRY serwer bazodanowy. Najlepiej nadają się do tego SQL Server w wersji Workgroup lub wyższej, ORACLE lub PostgreSQL.
2. NIGDY nie próbuj zmuszać serwery do komunikacji między sobą. Postaw maszynę, dającą sesje ale niech maszyny ze sobą nie współpracują w jakiś "zacieśniony" sposób - niepotrzebnie zużyjesz zasoby. PHP jest nieclustrowalny w sposób prosty i trzeba się z tym pogodzić dopóki programiści czegoś nie wysmażą.
3. Przy tworzeniu dll'ki dałem jej parę parametrów konfiguracyjnych ładowanych przez php.ini:
- nazwa clustra
- id serwera
- dane dostępowe do bazy danych z sesjami - dzięki nazwie clustre'a taka maszyna może obsługiwać ileś clustrów i ją samą też można clustrować - to już naprawdę na poziomie very high lodaed applications - ale wtedy weźmiecie coś lepszego nie PHP
4. Regularnie usuwaj sesje, które wygasły. Najlepiej jakiś sprytny trigerek on insert. ALbo Scheduled Task w Windows lub cron w UX

To porada dla naprawdę bardzo potrzebujących i muszących łączyć DUŻĄ ilość serwerów. Jest jednak sprytniejsze rozwiązanie. Może mniej wydajne, ale zawsze. Ustaw jedną maszynę z serwerem obsługującym dane aplikacyjne sesyjne i inne cuda. Jak nie chcecie IIS z .NET może być zwykły Debian z JBoss'em. Zmienne Javy bardzo dobrze się sprawdzają.

Przy odpaleniu dowolnego skryptu wywołujesz jeden jedyny plik z tamtego serwera (zmienne aplikacji nie będą się zmieniać zbyt często), który PRZEPISUJE Ci zmienne do php. eval i dowidienia


Tak teraz mi dwie aplikacje na po trzy serwery chodzą. Z tyłu stoi .NET, który stoi na windzinie XP i się sprawdza. A to najważniejsze. Sprawdza się na tyle, ze nie zamierzam znowu jakichś karkołomnych skoków robić - dodam, że aplikacje obciążane są średnio dziennie na jakieś 45k wywołań przez ok 3k użytkownków. Raporty finansowe, cuda wianki, wnisoki i inne duperele. Żeby jeden workflow przejść trzeba zrobić jakieś 10 wywołań.

To tak tytułem odgrzewania trupów trafiłem tu bo znowu robie high loaded i myślałem, że może coś się zmieniło w tym temacie. A że klient chce PHP na Linuxie.... .NET odpada, Javy nie wystawię, zostaje lip w C++. Trzeba się przeprosić...

Myślę, że wypadałoby odświeżyć temat. Przy okazji - czy zna ktoś dobre pozycje nt. pisania skalowalnych aplikacji? ( To dobry temat do tego? ).

Odgrzebie temat, bo mam trochę praktyki w tym temacie. W firmie tworzymy duża aplikację, którą około 8 mieszący temu przeszła na środowiska HA (High availabilty). Wynikało to z ruchu oraz podpisanego SLA z klientem. W tej chwili architektura wygląda tak, że mamy x serwerów apikacyjnych i y serwerów bazodanowych. Architektura jest rozwiązaniem autorskim zrobionym przez naszego administratora.

Opiszę może proces przejścia aplikacji ze zwykłej na środowisko rozproszone. Liczba zmian w kodzie równa się 0, aczkolwiek opiszę problemy z jakimi można się spotkać. Być może ktoś dopowie coś ciekawego i dołoży swoje przemyślenia. Na starcie powiem, że pominałęm ze 2 strony z wątku więc mogłem wszystkiego nie doczytać .

Co z cache:
- wszystkie foldery, współne np. cache widoku jest współdzielony między wszystkie nody applikacyjne. Zapis w cache do node-4 powoduje pojawienie się w node-1.

Co z uploads
- jak wyżej, współdzielone.

Sesja:
- sesja utrzymywana jest na poszczególnym węźle. Load balancer dba o to, aby żądanie od klienta kierować zawsze na ten sam węzeł. Jeżeli ten węzeł padnie, to cóż mamy fail dla tej sesji, ale aplikacja dalej jest dostępna. Efekt -> wylogowanie.

baza danych i replikacja:
- tutaj są największe problemy dla replikacji asynchronicznej dla wielu węzłów bazodanowych. Może być taka sytuacja w aplikacji, że dokonujemy zapisu do db-1 (węzeł 1 db), robimy przekierowanie, a następnie robimy odczyt z bazy wcześniej zapisanej wartości. W przypadku gdy aplikacja podłączy się do db-2 może replikacja nie zdążyć i dostaniemy error 500, lub błąd z brakiem danych w bazie.


Jestem ciekaw jak u Was następowały przenosiny aplikacji w PHP na środowiska HA i na jakie problemy natrafiliście. Jak wyglądało u Was dostosowanie oprogramowania i architektury do potrzeb działania systemu.