| Dragi Tata |
18. 09. 2006. 19:56 |
Lamp i distribuirane Web aplikacije
Out of curiosity: kakva je podrška LAMP tehnologija za distribuirane web aplikacije. Recimo, koji se middleware koristi, kakva je podrška za transakcije, itd.
Konkretno, koje bi LAMP tehnologije koristili za ovako nešto (primer J2EE:) http://www.tusc.com.au/tutorial/html/chap2.html |
| Ilija Studen |
18. 09. 2006. 21:13 |
Kad je PHP u pitanju nema potrebe za enterprise terminologijom, dijagramima i sličnim stvarčicama. PHP scaleuje po defaultu. Resursi između izvršavanja se ne dele već se uništavaju čim se akcija izvrši. Zahvaljujući tome PHP aplikaciju možeš da širiš horizontalno na praktično neograničen broj mašina - svaki zahtev je država za sebe, ma gde da se izvršavao.
Scenario je prost: imaš server baze (koji je opet država za sebe i može da se izvršava na više mašina, sa tim PHP nema veze) i imaš niz "aplikacionih" servera koji voze jednu te istu PHP skriptu i nalaze se iza load balancera koji ravnomerno prosleđuje zahteve. To je to.
Uglavnom, kad je reč o PHP-u treba da se potrudiš pa da napraviš aplikaciju koja NE scaleuje ;) Baš sam danas slušao intervju sa Rasmus Lerdorfom (autor PHP-a). Zanimljivo zapažanje: ljudi tvrde da PHP ne scaleuje jer nema mnogo tekstova o toj temi online. Razlog zašto nema mnogo tekstova je zato što to kod PHP-a i nije problem. Cela priča se može ispričati u 5 rečenica.
Način na koji PHP radi je ponekad ograničavajuć jer moraš da koristiš nešto da bi očuvao stanje između zahteva. Koliko je to mana toliko je i prednost. Na celu stvar gledaš iz ugla problema koji rešavaš.
Btw, tako stvari funkcionišu po rečima onih koji su pravili slična rešenja (ja nisam). Kada stvarno napravim nešto što će zahtevati ovakvu arhitekturu (nadam se uskoro) moći ću da podelim i neke konkretnije detalje.
|
| marinowski |
18. 09. 2006. 22:03 |
Pomenuo sam vec ranije prezentaciju Cala Handersona o funkcionisanju Flickra:
http://www.niallkennedy.com/blog/uploads/flickr_php.pdf
Po meni je to pravi primer poznavanja tehnologije. Ne radi se tu o nekom ekstremnom menjanju postojece infrastrukture, nego o poznavanju prednosti i mana istih. Toplo preporucujem ovu prezentaciju.
Najlakse je uzeti neko gotovo resenje, a kada se servis optereti, samo redjas servere i pricas okolo: znas, nase je resenje skalabilno ... pfff.... |
| Dragi Tata |
18. 09. 2006. 23:14 |
Citat:
Originalno napisao Ilija Studen
Scenario je prost: imaš server baze (koji je opet država za sebe i može da se izvršava na više mašina, sa tim PHP nema veze) i imaš niz "aplikacionih" servera koji voze jednu te istu PHP skriptu i nalaze se iza load balancera koji ravnomerno prosleđuje zahteve. To je to.
|
Kako se npr. rešavaju slučajevi heterogenih transakcija? Npr, moraš da u toku jedne transakcije promeniš rekorde u 3 sasvim različite baze. |
Off Topic: E bilo bi super kad bi neko napisao vrste aplikacija. distribuirane (?), cisto radi edukacija nas dizajnera. |
| dedamunila |
18. 09. 2006. 23:25 |
Citat:
Originalno napisao Dragi Tata
Out of curiosity: kakva je podrška LAMP tehnologija za distribuirane web aplikacije. Recimo, koji se middleware koristi, kakva je podrška za transakcije, itd.
|
+1. To i mene veoma zanima, kao nekoga ko razmatra prelazak (ili delimicni prelazak) sa MS-a na neku otvorenu platformu. Onoliko koliko sam do sada mogao da vidim, ta podrska (za middleware) na LAMP-u je 0. Znam, middleware se ne koristi svaki dan (npr. ja se ni ne secam vise kada sam zadnji put otvorio COM+ konzolu na Windowsu), ali... Cini mi se da je Java tu zakon (pogotovo sa gomilom open source application servera), ali nekako nije popularna na Webu, ne znam za mnogo high-traffic sajtova na Javi. Imam utisak da od nje beze kao da je sugava, a ne znam zasto i to me jako nervira.
Citat:
Originalno napisao Ilija Studen
Kad je PHP u pitanju nema potrebe za enterprise terminologijom, dijagramima i sličnim stvarčicama. PHP scaleuje po defaultu.
|
Ilija, ovo ne drzi vodu. Nije skalabilnost jedino cemu middleware sluzi (tu su jos, recimo, distribuirane transakcije, reliable messaging kojim se cesto ostvaruje async komunikacija itd.). Stateless, shared nothing arhitektura gde se sve cuva u bazi, moze se koristiti na svakoj platformi. Poenta je u tome da to ponekada usporava sistem, gotovo uvek cini programiranje tezim i sl. Npr. ASP.NET ima mogucnost cuvanja session state-a na vise mesta, od kojih je jedno SQL Server baza. Ta opcija je npr. ubedljivo najsporija.
Jos jedna stvar jako zanima: kako se na LAMPu pravi daemon/service aplikacija (npr. kada treba pokrenuti neku obradu kada stigne mail ili SMS poruka)? Citajuci gore pomenuti tekst o Flickr-u (gde pise da su to oni uradili pomocu Jave) stekao sam utisak da to ni ne moze. Da li gresim? |
| skaarj |
18. 09. 2006. 23:39 |
@[ng]
Distribuirane web aplikacije oznacavaju (najprostije receno) sisteme koji se rasprostiru na vise servera. Opste je poznato da vise servera manje snage u najvecem broju slucajeva daju bolje rezultate nego jedan server velike snage. To je sve ok dok se aplikacija ne zakomplikuje pa treba cuvati stanje izmedju dva zahteva koji su upuceni fizicki razlicitim masinama. Recimo da se desi da izmedju dva zahteva jedan od servera crkne i tvoj drugi zahtev se automatski prosledjuje na drugi dostupan server... Uvidjas problem?
O temi se moze jako puno pricati i ima raznih zanimljivih problema koji se tu desavaju ali globalno mali broj sajtova zahteva preterano komplikovanje oko toga.
JEE je zamisljen da resi problem u tim najkomplikovanijim mogucim slucajevima dok PHP i nije. Naravno, to niposto ne znaci da JEE ne moze da resi jednostavne probleme ni da PHP ne moze da resi jako kompleksne.
|
| Dragi Tata |
18. 09. 2006. 23:47 |
|
| dedamunila |
18. 09. 2006. 23:47 |
Citat:
Originalno napisao [nq]
Off Topic: E bilo bi super kad bi neko napisao vrste aplikacija. distribuirane (?), cisto radi edukacija nas dizajnera.
|
Distribuirane aplikacije su ti kao funkcionalne Flash prezentacije - o njima se prepricavaju legende, ali niko nije uspeo da dokaze njihovo postojanje :1064:
Distribuirane su ti one aplikacije koje se izvrsavaju na vise masina (neki vole da kazu "ciji se delovi izvrsavaju na vise masina"). To izvrsavanje na vise masina donosi neke lepe stvari (bolje performanse, otpornost na otkaze itd.), ali i probleme (koji se uglavnom svode na probleme sinhronizacije rada tih masina, pojednostavljeno govoreci). |
| dinke |
18. 09. 2006. 23:57 |
Citat:
Originalno napisao dedamunila
Jos jedna stvar jako zanima: kako se na LAMPu pravi daemon/service aplikacija (npr. kada treba pokrenuti neku obradu kada stigne mail ili SMS poruka)? Citajuci gore pomenuti tekst o Flickr-u (gde pise da su to oni uradili pomocu Jave) stekao sam utisak da to ni ne moze. Da li gresim?
|
Nisam citao pomenuti tekst, ali veruj mi da PHP moze da radi u cli-u i samim moze da radi i kao deamon. Moze se napraviti socket server, moze da radi kao SOAP server i sl. Nisam se bakcao sa SMS porukama, ali za e-mail se bez problema koristi .qmail-emailaccount fajl koji forkuje php fajl koji moze da pokupi attachment i sl iz emaila. Radio to pre par godina i funkcionise (u nedostatku bolje reci) - savrseno :)
Inace, nisam uopste upucen u .NET i distribuirane aplikacije (od ovih J2EE linkova sto je DT postavio mi se dize kosa na glavi od terminologije ;) ali bas ovih dana radim na jednoj ajd da kazem "distribuiranoj aplikaciji", gde imam na nekoliko servera PHP CLI scriptove (klijente) koji obradjuju milione keyworda, a na glavnom serveru cuvam rezultate procesiranja u jednoj MySQL bazi. U tabeli se cuvaju hostovi tih klijenata, pa se keywordi rasporedjuju na onoliko masina koliko ih ima u procesu. Ne pretereno inteligentno, ali moze se skalirati sa dodavanje novih servera i sl.
E sad, ista stvar bi mogla i preko SOAP-a recimo, gde je na glavnoj masini SOAP server prima zahteve od ovih SOAP klijenata, ali obzirom da nemam PHP5 na tom serveru, nisam zeleo da se bakcem sa starim (PEAR SOAP ili NUSoap) bilbiotekama. |
| Vreme je GMT +2. Trenutno vreme je 02:58. |
|
Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.
Mišljenja, saveti, izjave, ponude ili druge informacije ili sadržaji nastali na Sajtu su vlasništvo onoga ko ih je kreirao, a ne DevProTalk.com, tako da ne morate da se oslanjate na njih.
Autori poruka su jedini odgovorni za ovakve sadržaje. DevProTalk.com ne garantuje tačnost, kompletnost ili upotrebnu vrednost informacija, stavova, saveta ili datih izjava. Ne postoje uslovi pod kojima bi mi bili odgovorni za štetu ili gubitak koji je posledica bilo čijeg oslanjanja na nepouzdane informacije, ili bilo kakve informacije nastale kroz komunikaciju između registrovanih članova.Web sajt može sadržavati linkove na druge web sajtove na Internetu ili neke druge sadržaje. Ne kontrolišemo niti podržavamo te druge web sajtove, niti smo pregledali bilo kakve sadržaje na takvim sajtovima. Mi nećemo biti odgovorni za legalnost, tačnost ili prikladnost bilo kog sadržaja, oglasa, proizvoda, usluga ili informacije lociranim na ili distribuiranih kroz druge web sajtove, niti za bilo kakvu štetu nastalu kao posledica takvih informacija. DevProTalk.com drži i čuva druga prava vlasništva na web sajtu. Web sajt sadrže materijale zaštićene copyright-om, zaštitne znakove i druge informacije o pravu vlasništva ili softver. Članovi mogu poslatu informacije zaštićene pravima vlasništva njihovih nosilaca i ona ostaju zaštićena bez obzira da li su oni koji prenose te informacije to naveli ili ne. Osim informacija koje su u javnom vlasništvu ili za koje dobijete dozvolu, nemate pravo da kopirate, modifikujete ili na bilo koji način menjate, objavljujete, prenosite, distribuirate, izvršavate, prikazujete ili prodajte bilo koju informaciju zaštićenu pravima vlasništva. Slanjem informacija ili sadržaja na bilo koji deo DevProTalk.com, Vi automatski dozvoljavate i predstavljate garanciju da imate pravo da dozvolite DevProTalk.com ili članovima DevProTalk.com bespovratnu, kontinualnu, neograničenu, globalnu dozvolu da koriste, kopiraju, izvršavaju, prikazuju i distribuiraju takve informacije i sadržaje i da iz takvih sadžaja koriste bilo koji deo u bilo koje svrhe, kao i pravo i dozvolu da koriste gore navedene sadržaje. Svi zaštitni znakovi (trademarks), logotipi, oznake usluga, firme ili imena proizvoda koji se pominju na ovom web sajtu su vlasništvo kojim raspolažu njihovi vlasnici.
