Apache 1.3 vs Apache 2

[Tomoiaga]

Apache 1 la php e mai rapid decat Apache 2, pe noi asta ne intereseaza, nu viteza la static etc.

Pe baiatul asta il cred:
http://ilia.ws/archives/32-Apache-1-vs-Apache-2-Performance.html

Eventual pot sa va dau cateva date si din testele mele daca e nevoie.

Bineinteles ca nu vorbim de Apache 2 pe threaduri, e inutil.

[WBF]

Cand o sa fie suport de Apache2 in cpanel oare o sa mai vad genul asta de posturi ?

[Tomoiaga]

Exista suport, etp poate sa-ti confirme de exemplu.
O sa vezi genul de posturi pentru ca nu merita sa trec la apache 2 decat atunci cand o sa fie vital pytonu de exemplu si ala o sa fie alt server.
Apache 2 fara threaduri nu ma ajuta si cum nu se poate cu threaduri pentru ca....., atunci nu merita trecerea.
Citeste link-ul pe care l-am dat, tipu ala nu vorbeste prostii.
In plus comunitatea php a tot criticat Apache 2 etc.

[Cosmin L. Neagu]

Bine ... daca e sa fim fair faptul ca developerii de PHP ii critica pe cei de Apache nu inseamna mare brânză. Fac cei de la PHP atatea tampenii incat nu sunt ei cei mai in masura sa critice pe altii cu prea multa vehementa.

[Gupi]

hate to say that, da' apache o cam ia la vale sistematic
http://news.netcraft.com/archives/2007/07/09/july_2007_web_server_survey.html

[Tomoiaga]

multumesc gupi
Acum, nu zic ca imi caut motive de post si nici ca Apache o sa fie terminat, nu, trebuie sa lucreze mai bine putin. Exemplu relevand doar ca idee, remember winamp 3 ? I hated that am ramas la 2 sau cat era. La 5 deja si-au revenit.

Edit:
Da, asta cu php-ul cat de cat, dar au si aia ceva motive nu ca php-ul e stralucit.
Probabil ca ei au ajuns la discutii mai aprinse si si-au cautat peste tot defecte.

[Gupi]

multumesc gupi
Acum, nu zic ca imi caut motive de post si nici ca Apache o sa fie terminat, nu, trebuie sa lucreze mai bine putin. Exemplu relevand doar ca idee, remember winamp 3 ? I hated that am ramas la 2 sau cat era. La 5 deja si-au revenit.

Nu e vorba de moartea apaşului, da' o palma pe ceafă cred că au primit deja.
Pe de altă parte, cel mai bun Winamp e audacious-media-player.org

[Tomoiaga]

acuma na.
Asta ziceam, le trebuie palme. Bun, au pus workeru (threaduri) dar php-ul ii trage inapoi, mai sunt si alt factori nu zic, dar.... nu sunt motive foarte intemeiate sa renunti la apache 1.3 decat daca opresc productia ei.

[MYOTIS]

Problema e cam asa:

PHP nu e threadsafe.
PHP e un dinozaur. S-au folosit la greu o multime de 3rd-party librarii si nimeni nu s-a gindit nici macar pentru o clipa ca evolutia fireasca este spre multi-threading. Ca va veni o zi cand din ce in ce mai multe aplicati vor fi multi-threading cu toate avantajele care rezulta. Au folosit tot ce se putea folosi, au integrat librari fara sa analizeze acest aspect. Este aceasta librarie threadsafe? Care sunt implicatiile pe termen lung? Well ... intrebarea nu si-a pus-o din pacate nimeni. De ce? Pentru ca atunci cind s-a nascut PHP,  multi-threading si un OS cu toate librariile threadsafe era SF. De ce continua pe aceasta cale? Pentru ca e mai simplu. Scri cod mai repede fara a rascoli prin documentatia libc care-o folosesti sau a altor biblioteci daca functia cutare este safe. Se persista in aceasta directie pentru ca pur si simplu oricarui programator i se ridica parul maciuca in cap gindindu-se la ce ar insemna sa rescri intregul cod din perspectiva multi-threadingului. Asa ca mai bine mergi in directia gresita decit sa o ei de la capat...

...sau dai vina pe Apache 2! pentru ca autorii lui au inteles incotro merge lumea si au avut nerusinarea sa o ia de la 0 si sa rescrie intregul cod dupa standardele anilor 2005 nu dupa cele a anilor 1995. Lucru care in foarte scurt timp ar trebui sa-l faca si programatorii PHP-ului. Altfel in citiva ani o sa semene cu bunicuta.

Pe Windows toate librariile de baza sunt acum thread safe iar Apache profita din plin de acest fapt. Pe diverse platforme Unix exista in continuare librari care nu sunt thread safe. Acest fapt va complica extrem de mult rescrierea PHP-ului pentru acele platforme. Asta este o alta cauza a atitudinii fanilor PHP. Iubitoriilor de Unix le vine greu sa recunoasca superioritatea si unitatea Windows-ului la acest capitol.

Cat despre viteza, o sa observati diferente notabile daca rulati Apache pe pe windows unde librariile de baza sunt toate thread safe. Adica Apache 2 merge incomparabil mai repede decit versiunea 1.

La final vreau sa accentuez inca o data adevarata cauza pentru care Apache primeste palme "in ceafa": Frustrarea fanilor PHP generata de acel warning din manualul PHP care nu este altceva decit o recunoastere a faptului ca PHP-ul nu se poate adapta la noua arhitectura:

"Do not use Apache 2.0 and PHP in a production environment neither on Unix nor on Windows."

[MYOTIS]

Ah si daca cineva e putin ametit de thread-uri si librarii iata si varianta mai po*ulara a postului meu:

Tot razboiul seamana identic cu certurile de prin 2002 cind mai mult de jumatate din prieteni se incapatinau sa-si formateze HDD-urile FAT32 ca "merge mai repede decit NTFS-ul" si pastrau Windows 98 sau ME ca "platforma NT e naspa, e inceata etc".

Rezultatul dupa 5 ani este ca cei care mai ruleaza Windows 98 sau formateaza partitii FAT32 ori au PC-uri de muzeu ori au nostalgii care ies din sfera normalitatii...

Exact acelasi lucru o sa se intimple in curind si cu Apache 1 si 2.

[Gupi]

Sa nu-i uitam pe clasici
Perl e bine-mersi si inca sunt o gramada de aplicatii excelente care il folosesc.

(my 2c)

[Tomoiaga]

Apache 2 merge notabil mai binde decat Apache 1 cand ruleaza pe threaduri, ceea ce nu e cazul la hosting din cauza unor librarii php (php e thread safe).
Apache 2 cu php fata de Apache 1 cu php e mai slab, aici a cui e vina ?

[MYOTIS]

Iata o scurta lista cu librariile folosite de PHP care cauzeaza aceasta problema. Daca puteti face sa ruleze PHP fara el ... PHP e thread safe :

GD
folositi cel putin versiunea GD-2.0.35RC2 (publicata in 2007-04-10) altfel o sa aveti in mod sigur probleme bine documentate cu GIF-urile si FreeType. In rest ... nu exista nici o garantie oficiala ca e thread safe.

gdbm
Erorile sunt returnate intr-o variabila statica (gdbm_error). Nu este safe.

ASpell/PSpell
Din documentatia oficiala: "There are several areas of Aspell that that are potently thread unsafe (such as accessing a global pool) and several classes which have the potential of being used by more than one thread (such as the personal dictionary)."

Berkeley DB
Posibile probleme cu conexiunile sharuite intre thread-uri.

cdb
Exista o nota in documentatia API care indica ca "some "Managers" are not Thread Safe." Am cautat ... nimeni nu ne spune exact care.

C-Client
functiile strtok() si gethostbyname() nu sunt thread safe in cele mai multe implementari unix.

cpdflib
habar nu am, anyway am gasit warning-uri all over the net related to cpdflib dar nimic oficial

libcrypt
E thread safe doar daca se foloseste o instanta separata a parser-ului/thread.

FreeTDS
Din documentatia oficiala "Threads may not share a DBPROCESS or CS_CONNECTION without controlling access via a mutex.". PHP in mod sigur nu face treaba asta.

FreeType
Mai studiez problema ... in documentatia oficiala se sustine ca este thread safe si ca nu foloseste variabile statice. Potentiale probleme ar putea aparea insa din cauza diverselor functii C folosite care nu sunt thread safe pe toate platformele.

Imlib2
Warninguri in documentatia libpng privind optimizarea MMX din Imlib2. N-am avut timp sa ma holbez in codul sursa.

libjpeg
Probleme probleme probleme. Renuntam la ea lasam PHP fara suport JPG Nu renuntam PHP nu e thread safe.

libpng
Din documentatia oficiala: "Libpng is thread safe, provided the threads are using different instances of the structures. Each thread should have its own png_struct and png_info instances, and thus its own image. Libpng does not protect itself against two threads using the same instance of a structure." Posibile probleme si cu libpng asadar... Si un alt exemplu de ce PHP trebuie regindit pentru multi-threading.

Iar mai jost o scurta lista cu librariile despre care am citit ca-s cu probleme dar nu am avut ocazia sa aflu mai multe (probabil ca lista e mult mai mare):

• Ming
• Net-SNMP
• liboci8
• Sablotron

Iar raspunsul meu pentru Tomoioaga la intrebarea "Apache 2 cu php fata de Apache 1 cu php e mai slab, aici a cui e vina ?" e urmatorul:

E mail slab pentru ca nu lucreaza pe threaduri. Nu lucreaza pe threaduri din cauza PHP-ului nu pentru ca nu poate. E ca o masina de curse la care-am atasat o remorca de la tara. Am citit de asemenea in alta parte o reprezentare foarte plastica a Apache/PHP. Apache e gaina si PHP e oul. Acum oul e mai destept de cit gaina. 

[Adrian Andreias]

"Libpng is thread safe, provided the threads are using different instances of the structures. Each thread should have its own png_struct and png_info instances, and thus its own image. Libpng does not protect itself against two threads using the same instance of a structure."

Asta e din seria ascultatorii intreaba, radio Erevan raspunde:
- E biblioteca thread-safe?
- Da, cat timp nu se incearca folosirea multithreading (in anumite situatii)

lol 

[Tomoiaga]

pentru cine e curios, ffmpeg are mod pentru threadsafe just in case cineva il foloseste. Posibil sa ma chinui un pic sa vad care e si care nu e ts