PHP vs reszta platform Opcje

[Crozin]

Na początek prośba do moderatorów by rozdzielić wątek na dwa.

Chodzi ci o JEE czy nie trafilem, jesli mozesz opisz na co sie przerzuciles z jakich powodow jakie ma wady i zalety w poprowaniu do php twoje nowe narzedzie

Osobiście jestem w trakcie "przesiadki" na JEE i w żadnym wypadku nie można moich wypowiedzi traktować tutaj jako wypowiedzi kogoś kto ma z tą platformą spore obycie.
Prosiłeś o wypisanie wad i zalet tej platformy względem PHP tak więc i takie zestawienie znajdziesz poniżej, miej jednak na uwadze, że jak już wspomniałem JEE (a nawet i wiele elementów JSE) nie jest mi tak dobrze znaną technologią jak PHP, które znam od dobrych kilku lat. Na pewno z wielu wad/błędnych rozwiązań nie zdaję sobie nawet sprawy (brak wystarczającego doświadczenia), a jest ich na pewno cała masa - jak w każdym języku/platformie, szczególnie takiej która swoje początki miała w połowie lat 90 i dbała o wsteczną kompatybilność (to akurat zaleta) kosztem pewnych decyzji/rozwiązań (np. typy generyczne będące na dobrą sprawę jedynie lukrem składniowym).

Subiektywna lista:
Język:

1. Java jest statycznie i silnie typowanym językiem co znacznie ułatwia pracę poprzez: znaczne poprawienie czytelności kodu; ułatwienie dokumentacji kodu; uniemożliwia mieszanie typami (popatrz chociażby na genialny sposób informowania o nieznalezieniu podciągu przez strpos - zamiast zwrócić "-1" zwracają "false", które jest w większości przypadków traktowane jak "0") nie wspominając już o wszelkiego rodzaju narzędziach typu IDE, które po prostu mogą w ogóle działać.
2. Idiotoodporność PHP, która najbardziej krzywdzi właśnie początkujących, a bardziej doświadczonym sprawia jedynie problemy. Użyłeś nieistniejącej zmiennej/właśćwiości obiektu/elementu tablicy? Żaden problem, uznamy, że podano wartość null/false/0. Podałeś za dużo argumentów dla funkcji? Żaden problem, uznamy że tych nadmiarowych w ogóle nie ma. Podzieliłeś przez zero? Wszechświat się zapada, a zmienna przyjmuje boolean'owski fałsz i jedziemy dalej. Takich zachowań jest znacznie więcej i w najmniejszym stopniu nie są one pomocne.
3. Deweloperzy PHP nie myślą i nie testują nowych elementów języka:
   • Pojawiły się wyjątki, a nie istniały praktycznie żadne predefiniowane, żadnych reguł co do ich użycia, żadnych elementów składni informujących o tym, że dany wyjątek może się w ogóle pojawić itd.
   • Wprowadzili domknięcia, ale nie dali już możliwości zdefiniowania czy domknięcie przekazane w argumencie dla funkcji (np. jako callback) ma mieć jeden, dwa czy może cztery argumenty? O ich typach nie wspominając.
   • Wprowadzają kolejne klasy do SPL-a (bardzo dobrze), ale wymyślili sobie, że jedna z nich - bodajże MessageFormatter - będzie mogło zwrócić NULL-a w wyrażeniu new MessageFormatter(..); (tak dla jasności jest to sprzeczne z "specyfikacją" języka.
   • Wprowadzili przestrzenie nazw, ale nie narzucili żadnego sposobu ich nazywania (zrobił to dopiero PSR-0, który nie jest jednak zawsze przestrzegany)
4. Brak porządnego wsparcia dla Unikodu w PHP, ogromny burdel w bibliotece standardowej, [u]brak nowej, równoległej do istniejącej biblioteki standardowej[/i]
5. Spore braki w elementach/strukturach języka: w PHP nie stworzysz sobie nie-publicznej/lokalnej klasy gdy potrzebujesz jej jedynie w obrębie innej klasy/przestrzeni nazw przez co cały projekt musi być zawalony jakimiś nieistotnymi klasami; nie stworzysz sobie prywatnej stałej w klasie; nie stworzysz typu wyliczeniowego; nie masz dostępu do adnotacji, anonimowych instancji itp.

Platforma:

1. JEE jak sama nazwa wskazuje jest zdecydowanie bardziej "enterprise'owa". To dostęp do całej masy świetnych narzędzi, trzymanie się dobrych, utartych, a przede wszystkim sprawdzonych standardów co do których ma się pewność, że w ciągu najbliższych lat nawet jeżeli zostaną zamienione innymi nadal będą dobrze wspierane. Za JEE stoi cała masa korporacji co bardzo dobrze wpływa na jej stabilność. W tym zestawieniu PHP wygląda jak stojący na glinianych nogach, [brak mi weny ;] - kaleka?]. I bynajmniej nie jest to jak pojedynek Dawida i Goliata, tu ten ostatni jednak wygrywa.
2. W PHP na dobrą sprawę na start nie dostajesz kompletnie nic. Żadnych mechanizmów mogących realnie wspierać cokolwiek. Jak już napisałem na całe szczęście kilka lat temu pojawienie się FW dla PHP uratowało je przed kompletnym porzuceniem. A JEE? JSP/JSF, EJB, CDI, JPA, JTA, JMS i jeszcze wiele, wiele innych 3-4 literowych akronimów. (IMG:style_emoticons/default/wink.gif)
3. Oczywiście w/w to jedynie specyfikacje i zestawy interfejsów... bo w Javie masz możliwość realnego wyboru implementacji. Nie jesteś ograniczony do jednego producenta.
4. Serwer aplikacji nie działa na zasadzie od żądania do żądania - to znacznie ułatwia pokonywanie ograniczeń protokołu HTTP oraz platformy klient-serwer. Masz rzeczywistą możliwość robienie dowolnych rzeczy na serwerze (bo nie ogranicza Cię ani środowisko uruchomieniowe dla języka, ani sam język bo Java jest po prostu szybka).

Tych punktów mogłoby tutaj być więcej. Ale PHP nie jest wcale jakimś niewyobrażalnym badziewiem. Jak każdy język ma spore możliwości, a w dobrych rękach można w nim stworzyć na prawdę świetne projekty.

[wookieb]

A po co Ci "locki" w PHP gdy chcesz skorzystać z memcache?

[Orzeszekk]

A po co Ci "locki" w PHP gdy chcesz skorzystać z memcache?

masz jakis wpis w memcache. Ma on waznosc na 10 minut.
nastepnie x uzytkownikow (dajmy na to 100) akurat wchodzi w tym samym momencie na twoja strone, i potrzebuje tego wpisu w memcache.
Poniewaz sie przedawnil, probuja go utworzyc od nowa. poniewaz kazdy request dziala w oddzielnym wątku, i robia to mniej wiecej w tym samym momencie, nie wiedzą o sobie nawzajem, ze rownolegle requesty rowniez probuja utworzyc ten wpis na nowo.
leci 1000 zapytan do bazy danych, a nastepnie 1000 requestów zapisuje te dane w danej komórce pamieci.

Jezeli zapytanie do bazy danych trwa 500ms, to przez 500ms pomimo ze zapytanie juz jest wykonywane, kolejne requesty ktore wchodza na strone i żądają tej komorki pamieci memcache, robią swoje requesty od nowa, bo mysla ze komorka pamieci jest pusta - pierwszy request ktory wykonal zapytanie majace na celu odswiezyc cache, jeszcze nie zakonczyl swojego dzialania. I tak w kolko beda sie odpalac kolejne zapytania dopoki pierwszy request nie zakonczy zapytania i nie zapisze go w memcache.
Zazwyczaj cachuje sie duze partie danych wiec calkiem prawdopodobne ze to zapytanie bedzie trwalo dosc długo.

Z tego co widzialem i co jest w miare logiczne, aby uniknac tej sytuacji proponują aby swoje zapytania do memcache przekonstruowac tak ze każdy request zanim zacznie to zapytanie do bazy danych czy cokolwiek innego co ma zdobyc dane dla odswiezenia memcache, sprawdza czy zostala ustawiona flaga ze juz ktos to odswieza - zazwyczaj jest to np dodatkowa zmienna w memcache o jakiejs tam nazwie. To nawet dzialajaca solucja ale i tak nie do konca rozwiazuje problem, jesli ten pierwszy skrypt ktory zalozyl lock sie zawiesi, blokada nie zostanie zdjęta. Po za tym wątki moga zostac przelaczone w dowolnym momencie - np pierwszy proces ustawia flage lock, nastepnie system zatrzymuje ten watek i uruchamia drugi - drugi tez chce odswiezyc cache ale widzi ze flaga jest ustawiona więc czeka sleepem lub pętlą, zajmuje procesor, nastepnie przeskakuje do trzeciego.. tysiecznego i na koncu wraca do pierwszego ktory dopiero wtedy moze zaaktualizowac cache i dokonczyc prace i odblokowac reszte wątkow. gdyby byla sekcja krytyczna to nie byloby takiego problemu bo caly kod wykonalby sie za jednym razem bez przeskakiwania do innego wątku.

po za tym jest to smierdzące obejscie niedorobki w jezyku ktore powinno byc rozwiazane przez developerow php, ewentualnie memcache, a nie przez programistow korzystajacych z tych modułów. skoro php nie ma mechanizmow programowania wspolbieznego, to powinien byc zrobiony tak by programisci nie musieli sie wspolbieznoscia przejmowac.

Ten post edytował Orzeszekk 24.02.2012, 13:51:00