Wydajność Node.JS kontra reszta świata
W internecie panuje moda na zachwycanie się niezwykłą wydajnością Node.JS, często nie poparta jest ona żadnymi testami, a jedynie typowymi hasłami, takimi jak „nieblokujące we/wy”, „asynchroniczność”. Sama asynchroniczność w warstwie serwerowej jednak nie gwarantuje jeszcze wielkiej wydajności i również nie jest niczym nowym. Server-side JavaScript, jako dziedzina relatywnie nowa (przynajmniej w praktyce, bo niemalże niezauważone eksperymenty istniały już od wielu lat), pełna jest niedomówień i nadziei („ale super – mogę pisać serwery w JS”). Co jednak za tym stoi w praktyce?
Kontrowersyjny temat
Na początku lipca zorganizowaliśmy trzydniowy DevCamp, którego celem miało być lepsze rozpoznanie zastosowań, słabości i mocnych stron SSJS. Jednym z głównych tematów była wydajność, wokół której najwięcej jest kontrowersji. Zauważyliśmy to, gdy tylko pierwsi z uczestników DevCampa opublikowali na swoich blogach swoje spostrzeżenia – w komentarzach zahuczało od uwag i pomysłów na lepsze udowodnienie ogromnej wydajności Node.JS, w którą wszyscy tak bardzo chcą wierzyć.
Zamiast “gdybać” – zmierzmy wydajność
Ponieważ wydajność to temat rzeka, a z naszych podevcampowych przemyśleń również wysnuliśmy kilka dodatkowych wniosków, postanowiliśmy zorganizować w tym temacie dedykowany DevMeeting – dla tych, którym temat wydajności jest bliski i którzy chcieliby się przyczynić do stworzenia testów możliwe najbardziej miarodajnych i adekwatnych. Jeśli masz doświadczenie w przeprowadzaniu testów wydajności, znasz odpowiednie narzędzia, interesują Cię tego typu porównania – zapraszamy.
ServerSide JS kontra inne technologie
Na DevMeetingu chcemy skupić się na porównaniu nie tylko różnych rozwiązań SSJS między sobą, ale również innych popularnych technologii aby mieć właściwe odniesienie i aby móc umiejscowić JavaScript na rynku rozwiązań serwerowych. W ramach spotkania stworzymy zatem kilka aplikacji w różnych językach programowania i skupimy się na ich porównaniu. No i nie zaczynamy od zera – będziemy bazować na przemyśleniach i wynikach osiągniętych podczas DevCampa.
Tematy
- Testy obciążeniowe – ile requestów tak naprawdę uciągnie Node.JS?
- Rozpraszanie środowiska – wiele instancji Node.JS vs inne rozwiązania klastrowe/rozproszone; skalowalność tych rozwiązań
- Node.JS vs V8CGI vs RingoJS
- Wydajność w klasycznych realnych sytuacjach typowych dla aplikacji webowych
- Zmiana wydajności wraz z obciążeniem – rozpoznamy granice i słabe punkty różnych technologii
Dla kogo?
- Zaawansowanych developerów JavaScript ale także Ruby, PHP, Perl, Python i Java
- Osób znających się na zagadnieniach związanych z testowaniem wydajności, także tych niezwiązanych z JS’em
- Maniakalnych ewangelizatorów Node.JS i zaciekłych wrogów tychże
Devmeetings @ facebook
Prowadzący
David de Rosier, rocznik 1977. Programista, szkoleniowiec i pasjonat WEB2.0 oraz nowoczesnych technik programistycznych. Były nauczyciel akademicki, stały współpracownik Software Developers Journal. W latach 2003-2010 zajmował się szkoleniem programistów z technologii MDA (BML, Java, JavaScript) oraz projektowaniem aplikacji bankowych i mobilnych, pracując onsite dla klientów w Azji, Afryce i Europie. Aktualnie freelancer, zajmujący się głównie szkoleniami i konsultingiem z technologii javascriptowych. W wolnych chwilach programuje lub podróżuje. Często jedno i drugie.
David zapewnia, że żadne z waszych pytań, które pojawi się podczas pisania aplikacji, nie pozostanie bez odpowiedzi.
Dyskusja
@David: Pisząc o 4 bazach danych masz na myśli 4 różne systemy baz danych (np. mysql, couchdb, mongodb i redis)? Czy 4 różne bazy w obrębie jednego systemu? Domyślam się, że pierwsza opcja – czy zostało już ustalone jakie to będą bazy? Czy w ogóle wybór należy do nas? Jeśli źle się domyślam, to pytanie to samo :) I czy schemat(y) bazy będzie narzucony, czy zgodnie z zasadą “ma być jak najszybciej” podejmujemy decyzje sami?
Druga sprawa, to jeśli mielibyśmy zacząć pisać coś wcześniej, to przydałoby się trochę szczegółów dotyczących funkcjonalności jakie mamy udostępnić. Zapewne przygotujecie jakiś skrypt testowy, więc fajnie gdybyśmy wiedzieli jakiego API on oczekuje. Bo np. rozumiem, że renderowanie HTML-a po stronie klienta odpada? :P
Trzecia sprawa, to ja poproszę do jakiegokolwiek teamu z JS-em. Najchętniej oczywiście Node :P
Czwarta sprawa, to jak zawsze smutne słowa o perftestach. Przetestujemy tu dosyć specyficzny case (nie mówię, że rzadki). Dużo prostych odczytów z bazy, mało przetrawiania danych w kodzie, stosunkowo mało logiki, nietrudne renderowanie HTML-a i dużo req/s. Dużo więcej zrobić nie możemy, bo skomplikowanej aplikacji nie zbudujemy, ale warto mieć świadomość, że wyniki otrzymane w tym wypadku nie będą się musiały sprawdzać w każdym. Tak przynajmniej myślę :)
PS. Przydałyby się odstępy pionowe pomiędzy akapitami (a przynajmniej w podglądzie ich nie mam).
@piotrek – wydaje mi się, ze David pisząc o 4 bazach miał na myśli master-slave i replikację.
Odnośnie prostych aplikacji – jakbyśmy napisali skomplikowaną aplikację, to też trudniejsze byłoby jej przetestowanie. Wiele różnych akcji, ACLe, zdecydowanie bardziej skomplikowane walidowanie danych i takie tam. Dobrym “case’m” ( :D ) na coś takiego byłaby moim zdaniem jakaś gra MMO.
@radek: Myślałem, że może chodzi o przetestowanie różnych baz, by nie sprawdzać tylko jednej. Ale to bez sensu jeśli mamy mieć najlepszą wydajność, więc pewnie masz rację.
Odnośnie testowania – rzecz jasna masz rację. Nawet nie twierdzę, że byłby w ogóle sens testować takie złożone aplikacje (gdyby w ogóle był na to czas). Zbyt dużo zmiennych, zbyt mała jasność wyników.
PS. tego case’a to przejąłem od Piotrka :P Spaczył mnie nim ;)
Hej. W pierwszym poście chciałem bardziej ogólnie zarysować przypadek testowy – dlatego nie wdawałem sie w niuanse. Co do rodzajów baz danych – będzie jeden i… relacyjny (MySQL). Testujemy konkretne technologie i silniki webowe a nie bazy danych; możecie jednak domyślac się co wydarzy się tydzień później na DevMeetingu no-SQL :-) Nie jest to klasyczny master-slave. Dane są rozproszone między bazami – nie zajmujemy się w naszym przypadku replikacją. Bardziej chodzi o złożenie wyniku z kilku źródeł (banalny map-reduce?). Dodaje to złożoności naszej aplikacji, ułatwi nam też kwestie resetowania bazy przed kolejnym testem (możemy założyć, że zapisujemy tylko do jednego węzła).
Przykład MMO jest dobry ale pamiętajmy, iż mamy do dyspozycji tyko jeden dzień. Poza tym tutaj dość złożonym staje się tworzenie powtarzalnych testów.
Nasz przypadek komplikujemy przez kilka źródeł danych. W efekcie wyciągnięcie tweetów naszych followersów jest zagadnieniem nieco bardziej złożonych i na tej bazie budujemy test. Przy odpowiednim obciążeniu oczywiście. Naturalnie częścią testu będzie też postowanie.
Jesteśmy na etapie koncepcyjnym ale zgodzę się iż jak najszybciej powinniśmy określić API i parę dodatkowych warunków. W międzyczasie zastanówcie się proszę nad kwestią konfiguracji poszczególnych środowisk testowych. Chcielibyśmy definitywnie uniknąć sytuacji, w której podstawowym ograniczeniem wyników testowych jest konfiguracja a nie technologia sama w sobie.
@David: Szczerze mówiąc, narzucenie jednej bazy niekoniecznie może być dobre. Z jednej strony, masz rację, że mamy jaśniejsze wyniki co do technologii, ale z drugiej strony staramy się sprawdzić realny przypadek. A realny przypadek jest taki, że każdy wybierze bazę dla której w danej technologii ma najszybszego drivera, która dobrze współpracuje z koncepcją danego środowiska itd. Na przykład może się okazać, że PHP świetnie współpracuje z MySQL-em, ale z Redisem kijowo, a w tym wypadku może Redis będzie najlepszą bazą, bo (zgaduję) pasuje do lekkiego Node’a i istnieje dopracowany natywny driver. I w ten sposób wypaczymy lekko wyniki. Bo wydaje mi się, że to co wpływa na realną wartość Node’a, PHP, czy Javy, to nie sam core tych technologii, tylko cały pakiet jaki się wykorzystuje w projekcie.
@David: podoba mi się pomysł z wcześniejszym przygotowaniem do projektu.
O ile bardzo interesuje mnie jak zachowają się poszczególne technologie w podobnym projekcie o tyle skupienie się na “najszybsze” budzi moje wątpliwości. Bazowanie na frameworkach przyspiesza kodowanie, czasami ułatwia skalowanie i zwykle wymaga więcej zasobów na przetrawienie requesta. Sensownie byłoby porównać kod który robi mniej więcej to samo i pokazać gdzie poszczególne technologie mają przewagę.
Hej!
Zgłaszam się na ochotnika do teamu PHPowego. Mam “jakieś tam” doświadczenie z PHPem i Zend Frameworkiem więc mogę spróbować na tym przygotować klonik Twittera pod testy.
Musimy tylko ustalić szczegóły dot. choćby bazy, formatu URLi itp.
Pozdro! Gregor
@piotrek – masz trochę racji co do bazy danych. Aby wyeliminować ten problem, moglibyśmy robić mocki. Albo za pomocą profilera zobaczyć
Ale to też nie będzie rzeczywiste zastosowanie, no bo co jak co, ale produkcyjna aplikacja musi gadać z jakimś storage’em. Chyba że osobno testy samych driverów.
@Gregor ZF z racji swojej architektury do demonów szybkości nie należy, dlatego nie jestem pewien, czy jego wykorzystanie w testach wydajności nie będzie strzałem w stopę.
Wiadomo, że najszybsze będzie rozwiązanie bez frameworka, ale tez nie o to chodzi. Proponowałbym coś lżejszego – z ostatnich testów wynikało, że bardzo szybkie są Kohana i DooPHP (aczkolwiek ten ostatni mało popularny). Yii też podobno potrafi przyspieszyć. Osobiście na potrzeby pracy dyplomowej mam na dysku klon Twittera napisany w w Lithium, ale on też nie jest super wydajny z tego co zauważyłem.
@singles – zgadza się, ZF do demonów szybkości nie należy, ale zawiera odpowiednie mechanizmy które wspomagają wydajność (wszelkiego typu cache itp.). Myślę że skoro mamy porównywać, to soft na różnych platformach powinien być zrobiony w ten sam sposób – jeśli czysty JS na node (tj. bez frameworków) to tylko czysty PHP – jeśli po stronie node’a framework to po stronie PHP też. Kwestia wyboru frameworka PHPowego: nie kierowałbym się tym co jest w danym momencie najszybsze, tylko raczej dojrzałością danej biblioteki. Osobiście dla wydajnej witryny sam bym sobie zrobił odpowiedni do wymagań framework, ale jeśli wydajność nie byłaby jedynym kryterium to wybrałbym ZF (moim skromnym zdaniem najbardziej dojrzałą bibliotekę PHP).
To co robimy w tej kwestii?
Przy okazji – zwracam uwagę na totalne oddzielenie komponentu pobierania danych od frameworka, co pozwoli na ewentualną zmianę frameworka bądź też logiki związanej z pobieraniem danych bez jakiś większych przeszkód.
Co do wydajności – wydaje mi się, że w tym konkretnym wypadku to właśnie o na jest jedynym kryterium :)
Czyli czysty PHP ;-)
Postaram się tym zająć wieczorem.
(coś mi ucieło) – “Albo za pomocą profilera zobaczyć ile średnio zajmuje komunikacja z bazą danych i brać to pod uwagę”.
Jakby się trafił jakiś dobry spec od PERLa i jego wydajności to ja się dołączę z webserwerem BOA i client-side JS, żeby serwer musiał generować tylko JSONa i staniemy w szranki z serwerem wielkości 10×10×4 cm :)
Znalazłem jeszcze serwer G-WAN, ale żeby na nim coś napisać potrzebny jest chętny do pracy w C (tym bez plusów ;) )
Prościej byłoby chyba zapodać Hip Hop PHP. OSX nie jest wspierany, ale na Linuxie podobno działa. Ale to zadanie raczej na osobę z teamu PHPowego, z Linuxem na pokładzie.
G-WAN jest nieporównywalnie wydajniejszy jako sam serwer i to o ten zysk chodzi. Można na nim ruszyć też PHP, ale to wymaga i tak napisania kawałka kodu w C. Więcej nie doczytałem.
Hip Hop odpada – to jest tuning PHPa a chyba zależy nam na sprawdzeniu jak goły PHP sobie radzi na tle konkurencji. Jeśli tuningujemy, to również aplikację – czyli dokładamy memcache, jakiś dobry indexer etc… ;-)
Ja jestem za gołym PHPem na Nginxie, bez keszy indekserów i innych – ssiemy dane z bazy, obrabiamy i wysyłamy.
Pamiętajmy o tym że mamy tylko 12h – każda bardziej skomplikowana architektura pod testy generuje prawdopodobieństwo że się nie uda nic zrobić w danej technologii ;-)
Dokładnie, 12h to wcale nie tak dużo. Musimy się skupić na najbardziej typowych rozwiązaniach. Tymczasem zdaje się, że nikt się jeszcze zgłosił do teamu Ruby…
Ja się z chęcią w Ruby pobawię :)
Propozycja REST API dla naszych twitterow.
Bazujac na prawdziwym API twittera proponujemy nastepujace 3 (znacznie uproszczone) operacje:
GET http://.../statuses/home_timeline.json
?screen_name=cindyli
[
{
"created_at": "Fri Jul 16 16:58:46 +0000 2010",
"text": "got a lovely surprise from @craftybeans. ",
"id": 18700887835,
"user": {
"name": "cindy li",
"id": 29733,
"screen_name": "cindyli"
}
},
{
"created_at": "Fri Jul 16 16:55:52 +0000 2010",
"text": "Anything is possible when you're in"
"id": 18700688341,
"user": {
"name": "Daniel Burka",
"id": 635543,
"screen_name": "dburka"
}
},
...
]
GET http://.../statuses/user_timeline.json
?screen_name=cindyli
[
{
"created_at": "Fri Jul 16 16:58:46 +0000 2010",
"text": "got a lovely surprise from @craftybeans.",
"id": 18700887835
},
{
"created_at": "Fri Jul 16 16:55:52 +0000 2010",
"text": "Anything is possible when you're in",
"id": 18700688341
},
...
]
POST http://.../statuses/update.json
?status=Maybe%20he%27ll%20finally...
&screen_name=cindyli
{
"created_at": "Fri Jun 24 17:43:26 +0000 2011",
"id": 84315710834212866
}
Mysle ze calosc dosc ladnie tlumaczy sie sama. Warto dodac ze rezygnujemy z jakiegokolwiek logowania i kontroli dostepu. Interfejs webowy oczywiscie nie jest konieczny.
Schemat danych proponujemy nastepujacy:
users: id, name, screen_name
statuses: id, text, created_at
followers: user_id, follower_id
Zeby oczywiscie nie bylo zbyt prosto, tak jak wspomnial David, dane beda podzielone na 4 bazy danych (MySQL). Tak wiec operacja pobrania ‘home_timeline’ bedzie musiala zajrzec do wszystkich baz, polaczyc i posortowac wyniki.
Oczywiscie rezygnujemy z jakiegokolwiek przechowywania danych w pamieci RAM czy tez innego rodzaju cache.
Mozna kodowac ;)
Adam, czy ‘statuses’ nie powinno zawierać jeszcze ‘user_id’?
Wstyd się przyznać w XXI wieku, ale nie korzystam z Twittera ;-), a brakuje mi relacji do autora w statusie…
Gregor – nie, nie powinna, masz obiekt usera z jego ID, nickiem i nazwą :)
A gdzie relacja? Jak chcesz związać statusy z danym userem?
Ehh, ja miałem na myśli to co zwraca JSON. W przypadku schematu bazy rzeczywiście brakuje user_id w statuses – mój błąd, zwracam honor :)
Powinno i zawiera. Blad przy pisaniu posta.
Rozumiem, że dla dwóch pierwszych listingów są jakieś limity ilości rekordów?
Danych bedzie duzo, ale nie za duzo ;) Postaram sie dzisiaj badz jutro przedstawic liczby. Starmy sie dobrac ilosci tak, aby operacje odpytywania danych byly dosc czasochlonne i zobaczyc jak aplikacje/wybrane technologie sobie z tym radza pod wiekszych obciazeniem.
Nie do końca zrozumiem. Czyli odpowiedź na zapytanie z pierwszego przykładu API ma zwracać wszystkie wpisy osób śledzonych przez cindy bez jakichkolwiek ograniczeń (SELECT bez LIMIT)?
Nie zrozumialem Cie ;) Moj blad. W zwracanych wynikach oczywiscie ogranicznie musi byc. 20 rekordow – tyle co domyslnie w api twittera.
Czyli nie testujemy w ogóle template’ów? Jedynie REST-owe API?
Zdecydowalismy ze nie, ale jelis ktos ma ochote stworzyc rownolegle do restowego jakis prosty interfejs webowy, to bardzo fajnie, zobaczymy jaki jest jego narzut. Podstawa jest interfejs taki jak zdefinowalismy.
To jak starczy czasu to spróbuję. W szczególności po DC, gdzie testowany był np. EJS, który jeśli wierzyć jsperfowi jest dalej niż dinozaury za np. doT.
Dla pewności zapytam. Dzielimy dane na bazy danych. Rowno, czy po tabelach? Tzn, baza A trzyma trochę userow, trochę tweetow itd, a baza B inna część? Czy też baza A trzyma userow, baza B followersow, a ostatnia tweety?
Kazda baza ma ten sam schemat i zawiera podzbior danych. Partycjonowanie zrobimy po user_id czyli wszystkie statusy danego usera bada w tej samej bazie. Czyli dane dla:
user id:1 -> baza 1
user id:2 -> baza 2
user id:3 -> baza 3
user id:4 -> baza 4
user id:5 -> baza 1
user id:6 -> baza 2
itd.
W ten sposób partycjonowana jest tylko tabela “statuses” czy także inne tabele?
Partycjonujemy sami na poziomie aplikacji (wstawiając rekordy do tabel odpowiedniej bazy), czy piszemy jedynie do mastera nie martwiąc się o resztę?
W API brakuje metody do tworzenia nowych użytkowników czy określania kto kogo śledzi – rozumiem, że wypełnieniem tych danych zajmą się odrębne skrypty?
@tomasze: ja myślę, że userów i followersów to będziemy mieli z góry zdefiniowanych, to w końcu ma być stosunkowo prosta baza bo mamy tylko 12h na zabawę. Można to też wywnioskować z metod które zaproponował Adam.
Pozdro!
Tutaj moze byc kilka opcji, ale decydujemy sie na wariant ze dane konkretnego usera znajduja sie w tej samej partycji, czyli jego rekord w tabeli users, statusy w tabeli statuses oraz rekordy w tabeli followers mowiace o tym kogo ‘sledzi’ (z follower_id odpowiadajacym users.id.
Nie robimy replikacji, czyli na poziomie aplikacji musi byc logika odpytywania partycji, czyli np:
home_ timeline – na wejsciu mamy screen_name, czyli nie wiemy w ktorej partycji jest dany user. Musimy go zlokalizowac. Gdy juz go znajdziemy, z tej samej partycji dostaniemy jego statusy oraz info kogo ‘sledzi’. Majac idki userow ktorych, sledzi musimy zjarzec do odpowiadajacych im partycji, aby pobrac ich statusy. Laczymy wszystki statusy, sortujemy, ograniczamy do 20 i zwracamy wynik. Niektore z tych operacji moga byc wykonane rownlegle, inne nie. Naszym zadaniem jest napisanie najbardziej optymalnego rozwiazania.
Dane beda przygotowane. Inne opracje niz te, ktore opisalem nie sa potrzebne do przeprowadzenia testow, ale jesli ktos ma ochote to super.
Piszę się na Pythona lub NodeJS. Jeśli chodzi o Pythona to chodzi mi po głowie Tornado (jak ktoś ma ochotę dołączyć to zapraszam).
Pytanie organizacyjne – będzie możliwość stałego podłączenia do zasilania? Tak się składa, że padła mi ostatnio bateria…
Zawsze dobrze mieć ze sobą przedłużacz, my zagwarantujemy aby było go do czego podłączyc.
Jeśli chodzi o testowanie wydajności proponuję trzy możliwe warsztaty: Apache JMeter (scenariusze testowe do wyklikania, technologia Java), Tsung (konfiguracja manualna (nagrywanie zachowań) w (do) XML; technologia Erlang), ab (banalny w obsłudze, ale usługi HTTP można męczyć z konsoli na kilka sposobów; pakiet binarny do systemu op. lub kompilowanie dla wymagających). Również można tutaj wykorzystać Selenium RC + Jenkins z wieloma nodami, lecz dodatkowo musimy wymyślić coś do robienia raportów. A dla lubiących NodeJs jest np: nodeload, więc są jak widać nie jedne drzwi do wyważania ;-)
Jeśli wspominamy o testach wydajnościowych do tworzonych rozwiązań, to ten wątek ma na celu wymyślenie metod i scenariuszy testowych.
Kontynuując obrany w kierunek warto zrealizować poniższe:
1 określenie jednego spójnego Rest API
2 wykonanie testów obciążeniowych dla praktycznych ścieżek użycia API (propozycja: szukanie x 5, dodawanie x 1, szukanie x 2; szukanie x 20; aktualizacja x 2; szukanie x 10; usuwanie x 1; usuwanie nieistniejącego rekordu x 1; szukanie x 100; dodawanie x 100; szukanie x 100, aktualizacja x 100)
3 wybór narzędzia do pisania testów – spójne narzędzie z wstępu wątka; przyjęcie spójnego sposobu prezentacji wyników ew. użycie tego z narzędzia (ta sama metryka – wspólna skala)
4 ustalenie jak będą traktowane nody testowe (czy polowa grupy uruchamia serwery aplikacji a druga polowa nody tesowe i przez siec wewnetrzna testujemy kolizje i inne zdarzenia :-), czy ew. ktoś zaproponuje inaczej)
5 po nieudanych/udanych testach: zestawienia, raporty, komentarze, dyskusja, PIWKO ;-)
Pamiętajcie aby myśleć nie tylko w kategoriach doboru technologii ale również odpowiedniej konfiguracji. Na testowym serwerze memy np. zarówno Apache jak i Nginx. Przypominam, że maszyna testowa jest dwurdzeniowa – gdyby ktoś chciał z tego skorzystać. Fajnie gdybyście podrzucili pomysły na konfigurację jeszcze przed devmeetingiem, abyśmy mogli ewentualnie coś doinstalować.
Nasz serwer: Ubuntu Server 11.04, 64bit, 4GB RAM, Intel Atom Pineview (2 rdzenie, chyba 1,8GHz). 1 dysk twardy 7200RPM.
Rozumiem, że oba serwery : Nginx oraz Apache wyrzucają za burte potencjalne rozwiązania javowe i około javowe ?
Java jak najbardziej nie ma prawa być wyrzucona. Mamy oczywiście na pokładzie Tomcata i Jetty. Jeśli chcesz coś innego możemy dorzucić. Piszesz się na twitclona javowego?
Jeśli chodzi o PHP, to moim zdaniem najlepiej PHP 5.3.8 + APC (z instalacją 3.1.9 miałem problemy, ale 3.1.6 się spokojnie kompiluje). Najlepiej na Nginxie + FPM. Fajny tutorial jest tutaj, dla trochę starszych wersji, ale powinien się nadać http://interfacelab.com/nginx-php-fpm-apc-awesome/
Panowie PHPowcy, proszę o ewentualne uwagi :)
@singles – zgadzam się – jak ma być wydajnie to będzie to świetne rozwiązanie. Potrzebny będzie rewrite i przeglądając ten tutorial prawie padłem widząc wszystko-mówiący komentarz właśnie przy rewricie :-D :
# if file exists return it right away
if (-f $request_filename) {
break;
}
# otherwise rewrite the fucker
if (!-e $request_filename) {
rewrite ^(.+)$ /index.php$1 last;
break;
}
Odnośnie modułów PHP’a – właśnie siadłem do tematu, zobaczę co tam mam u siebie żeby to mniej więcej działało i podeślę listę, ale wydaje mi się że dociągnięcie ad-hoc odpowiednich modułów nie będzie problem w sobotę.
A co myślicie o tym, żeby uspójnić zapytania do bazy. W końcu każdy mechanizm będzie wyciągał te same dane, tylko po swojemu je obrabiał i zwracał. Chodzi mi o to, żeby nie było za dużych odstępstw pomiędzy SQLkami zrobionymi przez różne teamy.
To samo chciałem zaproponować. Co prawda to powinny być dosyć proste zapytania SQL, ale żeby nikt też nie zaszalał :)
A czy można być w teamie C#? :)
Straight Talk on Event Loops by Ted Dziuba
http://teddziuba.com/2011/10/straight-talk-on-event-loops.html
Kontrowersyjna, ale mimo wszystko konkretna analiza tematu wydajnosc/skalowalnosc node.js.
Ooo :) Tym razem wziął się za wzorki. Bo poprzednio kiedy pisał o Node, to zrobił z siebie pośmiewisko ;) Trzeba będzie uważnie przeczytać w wolnym czasie.
Jeśli nie posiadasz jeszcze konta, prosimy się zarejestrować .
Czas na kontynuację eksperymentów w temacie wydajności SSJS (contra reszta świata) – rozpoczętych w lipcu w trakcie DevCampa (http://devcamps.pl). Tym razem spotkamy się, by przetestować kompletną aplikację webową i zobaczyć różnice w wydajności między Node.JS, RingoJS i V8CGI w zestawieniu z PHP, Pythonem, Javą i Rubym.
Po DevCampie spotykaliśmy się często z opiniami, iż testowaliśmy nierealistyczne przypadki, badając niezależnie zagadnienia obciążenia procesora, pamięci, czy IO. Nie twierdzę, by tamte testy były złe – dzięki nim oceniliśmy i porównaliśmy sprawność poszczególnych technologii w konkretnych dziedzinach, poznając ich największe zalety i słabości. Tym razem jednak po prostu przetestujemy aplikację pod solidnym obciążeniem, nie wdając się w niuanse, który z podsystemów staje się wąskim gardłem – interesuje nas aplikacja jako całość. W efekcie finalnym chodzi bowiem o to, by użytkownik siedzący przed ekranem otrzymał wyniki jak najszybciej.
Naszą aplikacją testową będzie klon Twittera, pracujący jednocześnie na czterech bazach danych (partycjonujemy wpisy). Przy odczycie mamy zatem do zaimplementowania uproszczony map-reduce, natomiast zapis kierujemy do jednej bazy (z prostego powodu – przed uruchomieniem kolejnego testu usuwamy tę bazę).
Na DevMeetingu podzielimy się na grupy – każda reprezentująca oddzielną technologię. Grupy w określonych oknach czasowych, będą uruchamiać swoje aplikacje na naszym serwerze testowym. Wyniki będą automatycznie zbierane i aktualizowane na stronie.
Wkrótce opublikujemy szczegółowy opis przypadku testowego. Byłoby świetnie, gdybyśmy jeszcze przed DevMeetingiem podzielili się na grupy w zależności od znajomości konkretnych technologii i – o ile znajdziecie czas – zaczęli wstępną implementację jeszcze przed spotkaniem. Bardzo ważnym jest aby uniknąć sytuacji, w której niepoprawna konfiguracja zaważy na wynikach – przemyślcie zatem mocno, jak chcielibyście mieć skonfigurowanego np. Noda albo PHP, by uzyskać możliwie najlepsze wyniki. To samo dotyczy wyboru modułów czy frameworków. Mamy konkretny problem i chodzi o to by zrealizować go jak najwydajniej – dobierając najbardziej adekwatną konfigurację.
Niniejszym otwieram forum do dyskusji w temacie. Podrzucajcie swoje propozycje i uwagi, spróbujcie się też zadeklarować w której grupie najchętniej chcielibyście się znaleźć. Nie widzimy też problemu, by uczestnicy w trakcie Devmeetingu zmieniali zespoły.
Gdyby ktoś był zainteresowany, przygotowałem szkielet serwera w Node.JS oparty o framework Restify (<3) dostępny na moim githubie: https://github.com/adamjodlowski/tweet-perf/
Przygotowałem soft w ten sposób, że każdy zainteresowany podpina się ze swoim modułem bazodanowym napisanym pod konkretny driver i pompuje wyciągnięte tweety do silnika aplikacji, gdzie następuje map-reduce (od tej chwili, jeden kod) i przekazanie serwerowi jako odpowiedź dla klienta. Mam nadzieję, że takie podejście pomoże w uniknięciu benchmarkowania driverów jako-takich, zamiast serwera.
API zaimplementowałem zgodnie z niniejszą dyskusją. Pozostaje dogadanie się z bazą i zrobienie map-reduce.