On 02.05.2013 13:06, M.M. wrote:
> W dniu czwartek, 2 maja 2013 05:11:21 UTC+2 użytkownik u...@d...invalid
napisał:
>> Jak facebook sobie poradziďż˝, to ty teďż˝ sobie poradzisz :)
> Ciekawe czy by sobie poradzili ludzie od facebooka z moim problemem,
> jakby mieli taki sam budżet jak ja ;-)

Jakbyś miał taką oglądalność jak facebook to miałbyś też taki sam
budżet. IMO powolność PHP, która i tak nie razi, jest pomijalna w ~95%
przypadków.

do góry

W dniu niedziela, 5 maja 2013 06:32:41 UTC+2 użytkownik u...@d...invalid napisał:
> Jakby� mia� tak� ogl�dalno�� jak facebook to
> mia�by� te� taki sam bud�et. IMO powolno�� PHP, kt�ra i
> tak nie razi, jest pomijalna w ~95%
> przypadk�w.

Sa rozne aplikacje webowe. W wiekszosci waskim gardlem sa naprowadzenia
glowicy na dysku, ale nie wiem czy wiekszosc to 95%, czy moze 60%. Jesli
sie nie stosuje zadnych dodatkowych sposobow buforowania, to JSP moze
wygrywac z PHP. Ale poza aplikacja sa jeszcze dane. Duze zbiory danych
moga nie miescic sie w buforach i zaden jezyk programowania nie wplynie
na poprawe wydajnosci. Czyli masz racje.

Niemniej zdarzaj sie aplikacje, w ktorych obliczenia tez w jakims
stopniu skladaja sie na waskie gardlo. Gdy jestem na etapie projektowania
aplikacji, to trudno ocenic mi co i w jakim stopniu bedzie problemem. Jesli
od razu wybiera sie wydajny jezyk programowania, to ma sie problem
dlugotrwalych obliczen czesciowo rozwiazany. No ale mozna jezyki laczyc...
nic nie stoi na przeszkodzie, zeby z poziomu PHP wywolac procedure napisana
chocby w asemblerze.

Stara zasada mowi, trzeba napisac, zobaczy co najbardziej obciaza i dopiero
wtedy optymalizowac.

Pozdrawiam

do góry

W dniu 03.05.2013 07:27, Ghost pisze:
>
> Użytkownik "Lopez" <l...@p...onet.pl> napisał w wiadomości
> news:klump1$ini$1@node1.news.atman.pl...
>>
>> A requesty ajaxowe to kto najlepiej obsluzy jak nie framework?
>
> W jakim sensie "najlepiej"?
>

A w takim, że ma juz w sobie przede wszystkim obsluge
sesji i uwierzytelnianie, a takze wiele dodatkowych funkcji
jak obsluga parametrow, ORM itp. ktorych chyba nikt normalny
nie chce pisac od nowa:)


--
Pozdrawiam
Lopez

do góry

W dniu poniedziałek, 6 maja 2013 00:06:23 UTC+2 użytkownik Lopez napisał:

> A w takim, �e ma juz w sobie przede wszystkim obsluge
> sesji i uwierzytelnianie, a takze wiele dodatkowych funkcji
> jak obsluga parametrow, ORM itp. ktorych chyba nikt normalny
> nie chce pisac od nowa:)

Frameworki w takim PHP maja pelno bledow. Znam kilka
osob ktore napisaly swojego prostego frameworka i wcale
nienormalne nie sa. Pisanie autoryzacji od zera, obojetnie
czy ajaxowej czy zwyklej, argumentowaly mozliwoscia ukrycia
zrodla i potencjalnych bledow.

Pozdrawiam

do góry

W dniu niedziela, 5 maja 2013 22:06:51 UTC+2 użytkownik M.M. napisał:
> W dniu niedziela, 5 maja 2013 06:32:41 UTC+2 użytkownik u...@d...invalid
napisał:
>
> > Jakby� mia� tak� ogl�dalno�� jak facebook to
>
> > mia�by� te� taki sam bud�et. IMO powolno�� PHP, kt�ra i
>
> > tak nie razi, jest pomijalna w ~95%
>
> > przypadk�w.
>
>
>
> Sa rozne aplikacje webowe. W wiekszosci waskim gardlem sa naprowadzenia
>
> glowicy na dysku, ale nie wiem czy wiekszosc to 95%, czy moze 60%. Jesli
>

dyski maja cache w ram - i kiedys
pisalem jak to ladnie dziala, np
pierwsza kompilacja blisko 10 s
a kolejna 1 s, innym razem o tym
ze dostep z cache jest niewiele
wolniejszy niz memcopy ) wydaje sie
wiec ze to cache powinno dzialac
zwlaszcza ze wspolczesne kompy maja
sporo ramu - czyzby nie dzialalo ?

> sie nie stosuje zadnych dodatkowych sposobow buforowania, to JSP moze
>
> wygrywac z PHP. Ale poza aplikacja sa jeszcze dane. Duze zbiory danych
>
> moga nie miescic sie w buforach i zaden jezyk programowania nie wplynie
>
> na poprawe wydajnosci. Czyli masz racje.
>
>
>
> Niemniej zdarzaj sie aplikacje, w ktorych obliczenia tez w jakims
>
> stopniu skladaja sie na waskie gardlo. Gdy jestem na etapie projektowania
>
> aplikacji, to trudno ocenic mi co i w jakim stopniu bedzie problemem. Jesli
>
> od razu wybiera sie wydajny jezyk programowania, to ma sie problem
>
> dlugotrwalych obliczen czesciowo rozwiazany. No ale mozna jezyki laczyc...
>
> nic nie stoi na przeszkodzie, zeby z poziomu PHP wywolac procedure napisana
>
> chocby w asemblerze.
>
>
>
> Stara zasada mowi, trzeba napisac, zobaczy co najbardziej obciaza i dopiero
>
> wtedy optymalizowac.
>
>
>
> Pozdrawiam

do góry

W dniu poniedziałek, 6 maja 2013 00:39:18 UTC+2 użytkownik firr kenobi napisał:
> W dniu niedziela, 5 maja 2013 22:06:51 UTC+2 użytkownik M.M. napisał:
> > glowicy na dysku, ale nie wiem czy wiekszosc to 95%, czy moze 60%. Jesli

> dyski maja cache w ram - i kiedys
> pisalem jak to ladnie dziala, np
> pierwsza kompilacja blisko 10 s
> a kolejna 1 s, innym razem o tym
> ze dostep z cache jest niewiele
> wolniejszy niz memcopy ) wydaje sie
> wiec ze to cache powinno dzialac
> zwlaszcza ze wspolczesne kompy maja
> sporo ramu - czyzby nie dzialalo ?

Dziala i to na tyle dobrze, ze przyspieszenie widac golym okiem.

Problem w tym, ze danych moze byc 100 razy wiecej niz pamieci
RAM w jednym kompie. W takim przypadku "statystyczny bufor"
raz zadziala dobrze, drugi raz zle. Zwykle algorytm buforujacy
musi byc dostosowany do aplikacji.

Teraz z innej beczki:
Odczyt z dysku jest szybki, naprowadzania glowicy
wolne. Na dysku lezy duza tabela, zawiera recepty pacjentow. Recepty
moga byc porozrzucane losowo. Gdy chce recepty Xa, to naprowadzam
glowice nad kazdy rekord z recepta i odczytuje. Gdy chce recepty
Ya, to robie to samo. Mozna wiec zmienic kolejnosc recept, tak aby
obok siebie lezaly recepty tego samego pacjenta. Ale gdy bede
chcial recepty z 5-maja, to napotkam ten sam problem, w innej
postaci. Indeksy rozwiazuja problem przeszukiwania calej tabeli, ale
nie rozwiazuja problemu gdy rekordy sa losowo porozrzucane.

Czy w bazach danych (w systemach operacyjnych?) sa standardowo
implementowane jakies rozwiazania tego problemu? Gdybym mial
recznie cos takiego rozwiazywac, to chyba bym zrobil dwie kopie
tabeli, w jednej bym posortowal po nazwiskach, w drugiej po dacie.

Oczywiscie wplata sie w to wszystko koszmarny problem, a mianowicie
spowolnienie operacji usuwania i edycji pola po ktorym tabele zostaly
posortowane. Wiec moze optymalnym rozwiazaniem jest zrodlo danych na
XML czy CSV a nie na tabelach rekordow? Z pliku CSV mozna latwo
usunac recepte, mozna recepte przeniesc z jednego pliku do drugiego.

Hmmm jakis czas temu byla dyskusja o rozwiazaniach NO-SQL, ale to
o czym teraz napisalem, to chyba rozwizanie NO-TABLES? :D

Pozdrawiam

do góry

Dnia Sun, 5 May 2013 16:02:51 -0700 (PDT), M.M. napisał(a):

> Teraz z innej beczki:
> Odczyt z dysku jest szybki, naprowadzania glowicy
> wolne. Na dysku lezy duza tabela, zawiera recepty pacjentow. Recepty
> moga byc porozrzucane losowo. Gdy chce recepty Xa, to naprowadzam
> glowice nad kazdy rekord z recepta i odczytuje. Gdy chce recepty
> Ya, to robie to samo. Mozna wiec zmienic kolejnosc recept, tak aby
> obok siebie lezaly recepty tego samego pacjenta. Ale gdy bede
> chcial recepty z 5-maja, to napotkam ten sam problem, w innej
> postaci. Indeksy rozwiazuja problem przeszukiwania calej tabeli, ale
> nie rozwiazuja problemu gdy rekordy sa losowo porozrzucane.
>
> Czy w bazach danych (w systemach operacyjnych?) sa standardowo
> implementowane jakies rozwiazania tego problemu? Gdybym mial
> recznie cos takiego rozwiazywac, to chyba bym zrobil dwie kopie
> tabeli, w jednej bym posortowal po nazwiskach, w drugiej po dacie.

A co z fragmentacja dysku? Co Ci da to, ze dane beda "obok" siebie w pliku
skoro beda na dwoch koncach dysku? Pomijajac juz taki detal, ze nie ma
zadnego mechanizmu ukladania danych w tabelach wg swoich widzimisie. Tym
zarzadza serwer i nie masz do tego dostepu. Nie istnieje takie pojecie jak
kolejnosc ulozenia danych w pliku bazy danych.

> Oczywiscie wplata sie w to wszystko koszmarny problem, a mianowicie
> spowolnienie operacji usuwania i edycji pola po ktorym tabele zostaly
> posortowane. Wiec moze optymalnym rozwiazaniem jest zrodlo danych na
> XML czy CSV a nie na tabelach rekordow? Z pliku CSV mozna latwo
> usunac recepte, mozna recepte przeniesc z jednego pliku do drugiego.

Z pewnoscia moge zaryzykowac stwierdzenie, ze chocbys stanal na glowie nie
jestes w stanie zrobic nic wydajniejszego niz wspolczesne silniki DB. Powiem
wiecej, wydaje mi sie, ze trwonisz czas na nieistotnych rzeczach, bazy
danych dzialaja z setkami milionow rekordow, ze zlaczeniami i innymi
"utrudnieniami" i daja rade. Na 90% zrobisz w swoim sofcie wiecej waskich
gardel niz to, ktore dostaniesz od serwera SQL. Oczywiscie serwerowi tez
mozesz pomoc lub podlozyc noge projektujac dobra lub zla strukture tabel.

--
pozdro
R.e.m.e.K

do góry

Użytkownik "Lopez" <l...@p...onet.pl> napisał w wiadomości
news:km6l4v$eq0$1@node2.news.atman.pl...
>W dniu 03.05.2013 07:27, Ghost pisze:
>>
>> Użytkownik "Lopez" <l...@p...onet.pl> napisał w wiadomości
>> news:klump1$ini$1@node1.news.atman.pl...
>>>
>>> A requesty ajaxowe to kto najlepiej obsluzy jak nie framework?
>>
>> W jakim sensie "najlepiej"?
>>
>
> A w takim, że ma juz w sobie przede wszystkim obsluge
> sesji i uwierzytelnianie, a takze wiele dodatkowych funkcji
> jak obsluga parametrow, ORM itp. ktorych chyba nikt normalny
> nie chce pisac od nowa:)

To jest raczej teza, ze ogolnie frameworki maja wiele gotowych funkcji. Stad
prosta droga do swteirdzenia, ze bez frameworkow pisza tylko nienormalni.
Dodam, ze tyle smiala co karkolomne stwierdzenie. Frameworki nie do kazdego
zadania sie nadaja "najlepiej".

do góry

Użytkownik "M.M." <m...@g...com> napisał w wiadomości
news:e29c6d46-5143-4e90-b0d7-5322767a06e8@googlegrou
ps.com...
W dniu poniedziałek, 6 maja 2013 00:39:18 UTC+2 użytkownik firr kenobi
napisał:
> W dniu niedziela, 5 maja 2013 22:06:51 UTC+2 użytkownik M.M. napisał:

>implementowane jakies rozwiazania tego problemu? Gdybym mial
>recznie cos takiego rozwiazywac, to chyba bym zrobil dwie kopie
>tabeli, w jednej bym posortowal po nazwiskach, w drugiej po dacie.

Problem nie znika ze wzgledu na dowolny fizyczny rozklad pliku na dysku, ale
skoro glowica Cie tak boli to probuj bez: use the ssd luke.

do góry

M.M. <m...@g...com> napisał(a)
> W dniu poniedziałek, 6 maja 2013 00:06:23 UTC+2 użytkownik Lopez napisał:
>
>> A w takim, �e ma juz w sobie przede wszystkim obsluge
>> sesji i uwierzytelnianie, a takze wiele dodatkowych funkcji
>> jak obsluga parametrow, ORM itp. ktorych chyba nikt normalny
>> nie chce pisac od nowa:)
>
> Frameworki w takim PHP maja pelno bledow.

Tak, w przeciwieństwie do home-made rozwiązań.

> Znam kilka
> osob ktore napisaly swojego prostego frameworka i wcale
> nienormalne nie sa.

To chyba taka php-przypadłość, że tam każdy wynajduje koło. Raz
współpracowałem z takimi, którzy pisali "swoje" RSA - wyszło fatalnie.

> Pisanie autoryzacji od zera, obojetnie
> czy ajaxowej czy zwyklej, argumentowaly mozliwoscia ukrycia
> zrodla i potencjalnych bledow.
>

Oraz stworzenia kodu, ktorego nikt poza nimi nie będzie już umiał
poprawić.

PS. Jak już ktoś napisał, zajmujesz się dziwnymi rzeczami, jak na
web-developera, jakieś głowice/pliki i inne głupoty. Jak chcesz ten swój
projekt zrobic szybko pisz w tym, co znasz najlepiej. Jak chcesz się
nauczyć Javy/Pythona/what-ever i czas nie jest krytyczny pisz w
Java/Pythonie/what-ever.

--
Tomek

do góry