Grona >> Java >>

Grono.net a Java

Java [1242]

Zapisz się

Grono.net a Java

  • 1
  • 2
Dodaj kartkę Dodaj bana
Powód wlepienia kartki
Wybierz wątek docelowy z listy lub wpisz jego ID

  • T.

    Cześć.

    Na początek zaznaczę, że w zakresie webaplikacji jestem zwolennikiem rozwiązań Javowych. Co prawda popieram stosowanie odpowiednich narzędzi do odpowiednich zadań i bynajmniej nie neguję technologii skryptowych, jednak w J2SE/J2EE widzę wiele zalet, które na własnej skórze zdołałem poznać podczas realizacji kilku niemałych projektów (m.in. zbudowanych na frameworku Cocoon2).

    Hostuję aplikacje Java i muszę przyznać, że przy tuningu JVM, problemach z maszynami różnych vendorów, zwalonych GC i innych tego typu sprawach, parę litrów kawy już wypiłem. Jednak przy odrobinie wysiłku i wykorzystaniu współcześnie przyzwoitych zasobów sprzętowych hula to normalnie. Osobiście nie mam praktycznego doświadczenia z bardzo dużym loadem, ale przykład idea.pl pokazuje, że nawet duży traffic można obsłużyć porządnie. I to bez brawurowych inwestycji sprzętowych typu Agora.

    Niestety to, co się dzieję z gronem, napawa mnie trwogą. Nie potrafię sobie przypomnieć jakiejś innej strony WWW, która przetwarzałaby się wolnej oraz refusowała i 500-tkowała częściej, niż grono. Domyślam się, że występuje tu spora liczba konkurencyjnych requestów, ale korzystając (próbując korzystać) z serwisu odnosi się nieodparte wrażenie, że albo aplikacja jest po prostu źle napisana, albo niewykorzystane są odpowiednie, dostępne w tym środowisku narzędzia, albo chodzi to wszystko na muzealnym sprzęcie.

    Tak czy siak, grono.net z pewnością będzie ostrzeżeniem dla osób ufnie wierzących w skalowalność Javy. Tym bardziej, że znacznie mocniej obciążone serwisy o podobnej logice aplikacyjnej z powodzeniem chodzą... na PHP.

    Przykre, ale jakże prawdziwe.

  • Anonim

    Musze sie zgodzic... serwisy podobne do grono.net, znaczniej obciazone... lepiej sobie radza i wszystkie sa na php.
    np. sogamed.com oraz sk-gaming.com gdzie caly czas srednio jest podlaczonych 1500 uzytkownikow.

  • madGreg

    To nie jest prawda, że serwisy "znacznie lepiej sobie radzą na php". Prawdą natomiast jest, że serwis w Javie bardzo łatwo można spartolić (w sensie tak napisać, że będzie działał koszmarnie), jednak gdyby był napisany dobrze php zostałoby znacznie z tyłu.

  • Marek

    Możesz podać przykłady jak się partoli kod javy ?

  • яazo я

    szef grona (number one),
    odpisał mi na pytanie, właśnie traktujące o problemie z działaniem i obciążeniem.
    odpowiedź była taka że Tomcat/Java sobie radzą bez problemu.
    problem jest z bazą danych, która nie wyrabia
    i z pytaniami do tejże bazy danych
    (z odpowiedzi wnioskuję że w tym momencie nie są one jeszcze do końca idealne)

  • madGreg

    nie kod, tylko serwis, jako całość. od projektu po implementację. wystarczy źle korzystać z dobrodziejstw w stylu connection pooling, niepotrzebnie alokować zasoby, java to nie jest technologia dla dzieci. nie zrozum mnie źle, ale chyba jasne jest, że dajmy na to ejb dla efektywnego działania potrzebuje niebanalnej wiedzy, bez tuningu będzie się wlec jak parowóz.

  • chojnac

    podrecznikowy przyklad :

    String tmp = "";
    for(int i=0;i<10;i++){
    tmp += i;
    }

  • nablaone

    Pewnie ci co wysłali SMS to nie mają 500; -)

  • wojteks

    Tomku, wszystko sie rozbija o baze, aktualnie dzieja sie jakies szalenstwa z naszym serwerem bazodanowym. A wczesniej sie dzialy szalenstwa z JVM, a jeszcze wczesniej z czyms innym :)

    Rozwijamy sie lawinowo wiec kiedy naprawimy jeden problem - pojawia sie drugi. My tez nie mielismy do czynienia z takim ruchem, i pewnie nie wielu uzywajacych tomcata i postgresql'a mialo.

    Takze javy nie ma sie co bac, faktycznie wymaga ona wiekszej wiedzy niz php, ale w rewanzu daje:
    1. przejrzyste frameworki do budowy aplikacji
    2. wygodniejsze pisanie kodu (jest kilka rewelacyjnych IDE) i latwiejszy jego rozwoj
    3. wieksza szybkosc wykonania
    4. rzeczy w rodzaju http://c-jdbc.objectweb.org/ o czym nikt od php chyba nie wie? (nie mam pewnosci bo nie uzywam php do niczego duzego), http://www.prevayler.org http://db4o.com itd itp

    minusem jest walka z JVM (ale to tez jest do opanowania niestety po paru dobrych dniach szukania i kombinowania)

    pozdrawiam

  • T.

    Uhm. To chyba nie obejdzie się bez clusteringu baz, albo nawet wymiany pgsqla na jakiś inny, bardziej wydajny silnik. C-JDBC jest jednocześnie abstraction layerem, więc to byłoby nawet łatwe; -)

    Jestem jednak zaskoczony, że szybciej "skończyła" się baza, niż Tomcat, bo czytałem kiedyś, że Coyote do obsługi dużej ilości konkurencyjnych requestów stworzony to nie jest.

    Wojtek: jeśli to nie tajemnica, to czy możesz zdradzić w jakich warunkach to chodzi? Tzn. czy serwer aplikacji i baza są na tej samej, czy na innych maszynach i na jakich (chociaż arch/cpu, ram) oraz jaką liczbę requestów na sekundę ( http oraz sql) taki zestaw znosi - jak wnioskuję jeszcze bez clusteringu.

  • madGreg

    Czy cache'ujecie większość częstych danych w pamięci czy za każdym razem wołacie bazę?
    Dla dostępu do samej bazy używacie gołego JDBC czy też może jakieś narzędzie ORM, Entity Beans a może JDO?

    A tak na marginesie to od paru dni mam komunikat, że najkrótsza ścieżka nie istnieje blablabla ścieżki liczone są raz na dobę :) Czyżbym został odcięty od grafu? :) A tak serio to wy też tak macie?

  • madGreg

    Apropos najkrótszych ścieżek to jeśli to nie tajemnica to jak liczycie? Liczenie Floydem raz na dzień raczej odpada, bo przy złożoności O(n^3) i n rzędu 10^5 byłoby to niełatwe zadanie. Z uwagi na specyfikę tego grafu można by się pokusić o jakieś heurystyki. Tak czy inaczej problem jest ciekawy, więc jeśli to nie tajemnica to z chęcią posłucham jakiego algorytmu używacie.

  • Karwer

    Mysle, ze przy stosunkowo niewielkich stopniach wierzcholkow to lepiej zrobic dla kazdego wierzcholka BFS i miec zlozonosc O(mn) niz Floyda-Warshalla... Ale tak, mnie tez to ciekawi :)

  • madGreg

    To wydaje się być dobry pomysł. Ten graf jest dość rzadki, nie wiem jaki jest maksymalny stopień wierzchołka, ale stawiam na nie więcej niż 300, a średnio jest to pewnie mniej niż 10. W tym grafie N<M<<N^2, więc to na pewno jest lepsze niż Floyd-Washall. Myślałem jednak o czymś co liczyłoby inkrementacyjnie w miarę rozbudowy grafu. Bo większa jego część pozostaje przez większość czasu statyczna.

  • Przemek Drochomirecki

    Innym wartym rozważenia pomysłem jest:
    -znalezienie dwuspójnych składowych
    -wyznaczenie najkrótszych ścieżek dla składowych metodą BFS dla kazdego wierzcholka O(E*V)
    -stworzenie nowego grafu G', w ktorym wierzcholki reprezentują pewne dwuspojne skladowe

    i teraz mamy delikwetna A i B
    jesli A i B naleza do tej samej skladowej to wiadomo, jesli nie
    to szukamy najkrotszej sciezki w G' i modyfikujemy ta wartosc o dlugosc najkrotszego wyjscia A i B ze swojej skladowej

  • wojteks

    http://terra.act.uji.es/REA/

    algorytm Eppsteina wszystko zalatwia. Wszystkie wierzcholki sa oczywiscie w RAMie.

    A odnosnie cache to:
    http://www.danga.com/memcached/
    rewelacja, zwlaszcza jesli web-aplikacja rozrzucona jest po kilku serwerach (co niechybnie czeka grono).

    a grono chodzi na dwoch podwojnych xeonach (odnosnie wczesniejszego pytania)

  • T.

    Wojtek, ciekawy jestem jakie jest Twoje zdanie TERAZ, po prawie
    roku od czasu tamtej rozmowy (powyżej). Na pewno nie znam
    wszystkich szczegółów, ale moje odczucia są takie, że:

    - w ciągu ostatniego Wy roku zrobiliście postęp technologiczny pewnie niczym NASA; )
    - a Java dalej pie*doli się na potęgę, działa jak chce, kiedy chce i jak szybko (a raczej wolno) chce.

    To jak; ukochana czy znienawidzona?

  • Adept

    no ale czemu uparcie twierdzisz że to java??

    Moim zdaniem (chodź nie wiem jak top naprawde wygląda) jest to porblem architektury fizycznego systemu. Po prostu za mało serwerów.

    Zresztą to samo było jak przebudowaywali pracuj.pl. byłem na konferencji na której jeden z programistów nowej wersji powiedział tak:

    "stara wersja była oparta na javie, i strasznie wolno chodziła, ale nie była to kwestia javy tlko braku wyspecjalizowania serwerów"

    z iluś tam (nie wiem czy to był 1,2 czy 3) serwerów zrobili całe farmy serwerów i teraz działa gites (co prawda na .net ale to nie robi różnicy). Dopóki zespół grono.net nie zabierze się również za infrastrukture nie ma co liczyć na poprawe :)

  • T.

    Bla, bla, bla. :-) Od zawsze słyszę takie usprawiedliwienie, że Java to świetny język i w ogóle świetne środowisko, a jedynym jego problemem jest to, że.. jeszcze nie wynaleziono takich komputerów, na których by to przyzwoicie chodziło; ) Chłopaki z pracuj.pl przeszli do Microsoftu, a cały świat już dawno z Appletów - na Flasha. Ja sam jeszcze niedawno duże nadzieje pokładałem w Tigerze i nowym Tomcacie 5.5, ale po tygodniu walki - mam dosyć. Dalej jest to zabawka dla pasjonatów typu "zrób to sam", która po tylu latach rozwoju bardziej niż serwer przypomina system Windows95, szczególnie w aspekcie stabilności i komunikacji z uzytkownikiem.

    PS. Odnośnie grona.. no cóż - możemy tylko gdybać, jakby to chodziło zrealizowane w innej technologii. Ja osobiście nie wierzę, że po roku wciąż problemem jest baza. Bazy na szybkim sprzęcie zazwyczaj chodzą szybko. Bo nie są napisane w Javie; ))

  • Maciek Makowski

    > Bazy na szybkim sprzęcie zazwyczaj chodzą szybko.
    > Bo nie są napisane w Javie; ))

    Cloudscape i HSQLDB są. Inna sprawa, że w tej pierwszej podobno z wydajnością jest bardzo kiepsko, a druga to taka zabawka niespecjalnie nadająca się do pracy z wieloma klientami na raz (obsługuje transakcje tylko na poziomie read uncommitted).

    Zaletą baz javowych jest za to bardzo dobra wydajność gdy używa ich się jako silników bazodanowych wbudowanych w aplikację: http://www.theserverside.com/news/t...
  • 1
  • 2