რატომ PHP?

threads

ეს მორიგი სტანდარტული პოსტი არ არის ენების / პლატფორმების დაპირისპირებაზე. უამრავი ნეგატიური სტატიის და მოსაზრების მიუხედავად წლებია რაც php-ის ჩემს გულში განსაკუთრებული ადგილი უჭირავს და სულ ვცდილობდი დამედგინა რატომ. ბოლოს სიყვარულის სიბრმავეს დავაბრალე და ტკბილ მოგონებებს, რაც საყვარელ ხალხთან და პროექტებთან მაკავშირებდა, მაგრამ ახლა მე მგონი კიდევ ვიპოვე ერთი დიდი მიზეზი.

მოდი ცოტა შორიდან დავიწყებ.
ერთხელაც, .net რომ ვითარდებოდა ვებში, შემოვიდა asp ვებ ფორმები და პოპულარული გახდა. რამდენჯერ ვცადე შიგნით გარკვევა, რა წიგნები არ წავიკითხე, მაგრამ არ მიმივიდა გული არცერთხელ, თუმცა მიზეზს ვერ ვასახელებდი მაშინ. ეგ მიზეზი იყო თავსმოხვეული ხელოვნურობა. გეუბნებოდა ფრეიმვორკი, რომ მე ვიცი რასაც ვაკეთებ, შენ მარტო ეს ღილაკი დასვი და იმას დააჭირე. მერე მიდიოდა და ზურგს უკან რას აკეთებდა?! 😀 ამხელა სტეიტს დაათრევდა აქეთ იქით რიქვესთებს შორის. მე მგონი პლატფორმა კი არა, ერთი დიდი workaround იყო ვებისთვის.

ვერ ვიტან როცა ფარდის უკან აკეთებენ ყველაფერს. მოხდება შეცდომა და კაცმა არ იცის ვისი და რისი გამოწვეულია სინამდვილეში.

ახლა ჯავა 😀 ჯავა მიყვარს. მაგრამ ვებში ვერ შევეგუე ჯავას. მე მგონი რეალურად ახლა გავიაზრე თუ რატომ ვიყენებთ მისთვის Application სერვერს და არა ვებ სერვერს. უხეში ანალოგია რომ გავაკეთო, წარმოიდგინეთ რომ როგორც დესკტოპისთვის გაუშვებთ რაღაც პროგრამას, ანალოგიურად უშვებთ თქვენს ერთ პროგრამას სერვერზე ყველა მომხმარებლისთვის. ერთს! ყველასთვის! მთელი პარალელიზმი შიგნით არის ფაქტიურად.

Java EE-ში რიქვესთების საპასუხოდ პროგრამისტები ვწერთ სერვლეტ კლასებს, იქ კი instance ცვლადების გაკეთება არ არის კარგი. იცით რატომ? იმიტომ რომ თითო სერვლეტის ერთი ობიექტი გამოიყენება ყველა რიქვესთის საპასუხოდ (მთლად მაგაზე დაყრდნობაც არ შეიძლება, რადგან კონტეინერი აკონტროლებს როდის მოკლას ან ჩაანაცვლოს ის ინსტანსი). სტატიკური რაღაცები, სინგლტონ კლასები – ყველაფერი ჩვეულებრივ არსებობს აპლიკაციაში და shared არის მომხმარებლებს შორის. სპეციალურადაც კი არის ობიექტი – ‘აპლიკაციის კონტექსტი’ რომელიც სერვლეტებს შორის shared მონაცემებს დაატარებს და არაერთ best practice-ში გამოიყენება, თუნდაც რაღაც ობიექტების კეშირებისთვის. ამ ყველაფერს კი სჭირდება სინქრონიზაცია. უნდა იცოდეს პროგრამისტმა რა ბიბლიოთეკები და კლასებია thread-safe, იცოდეს კოდის რა ნაწილი მოხვდება ცალკე ნაკადში და რა ნაწილი იქნება გაზიარებული. მერე შესაბამისად lock-ებით და სინქრონიზაციის სხვადასხვა მექანიზმებით უნდა აკონტროლოს ეს ყველაფერი.

იყო რაღაც ფრეიმვორკები, ახლაც არის. ახლების ნახვის სურვილი აღარც გამჩენია მათ შემდეგ, იმიტომ რომ მე მგონი იმ ვებ ფორმებზე უარესად აფარებდნენ ფარდებს ყველაფერს. მახსოვს Struts რომ მიშრობდა სისხლს. xml-ში აკონფიგურირებდი და მერე ჯადოსნურად უნდა ემუშავა ბევრ რამეს. მაგრამ უმეტეს გაშვებაზე ერთი შეცდომა გამოდიოდა ხოლმე, რაც ჭირივით მეზიზღებოდა 😀 ფაილს ვერ ვპოულობო. ვერ გაიგებდი რა უნდოდა, xml-ში გამოგრჩა წერტილი თუ გადატვირთვა დააკლდა სერვერს. Spring-ზე არც დავიწყებ…

asp.net-ზე როცა იწერება ვებ აპლიკაცია, იქაც ერთი პროგრამა ეშვება. იქაც თუ შექმნით სტატიკურ კლასს, საერთო იქნება და რაღაც საერთო კონტექსტის ობიექტიც ჰქონდათ თუ სწორად მახსოვს. მერე asp MVC ფრეიმვორკი რომ შექმნეს, იქ კარგად ცდილობდნენ ყველა რიქვესთი stateless ყოფილიყო და როცა მომიწია მაგით წერა, ერთი სიამოვნება იყო ჩემთვის რადგან ფაქტიურად ზუსტად ისე ვწერდი როგორც php-ში.

(ცოტა ვურევ ახლა მე ერთმანეთში რაღაც რაღაცებს, მაგრამ ყველაფერზე რომ ვრცლად დავწერო, მთლიანი ბლოგი არ მეყოფა ალბათ).

განა ვაკნინებ ამ პლატფორმებს და ფრეიმვორკებს (ვებ ფორმების გარდა), უამრავი არაადამიანური შრომა არის ჩადებული და მეც წლების მანძილზე გამომიყენებია. მადლობის მეტი რა მეთქმის.
მარტო იმას ვამბობ რომ გაცილებით სასიამოვნო და კომფორტულია ისეთ გარემოში წერა, სადაც ამხელა კომპლექსურობა მოხსნილია და თანაც ისეა მოხსნილი რომ ფარდის უკან გადაძრომა არ გიწევს ხშირად. ჩემთვის ერთ-ერთი ეგეთი გარემოა php.

მეორე გახდა node.js, რომელზეც ქვევით ვიტყვი უფრო დეტალურად.

როცა PHP-ის ვებ სერვერზე ვიყენებთ, უმეტეს შემთხვევაში ისე ვაკონფიგურირებთ რომ ის არ ინახავს არანაირ state-ს. თუ CGI-ის, FastCGI-ის ან Apache-ს Prefork რეჟიმს გამოვიყენებთ, სერვერთან მოსული თითოეული რიქვესთისთვის ახალი პროცესი გაეშვება და მარტო ერთ ნაკადში შესრულდება php-ის კოდი. მაშინაც კი თუ php-ის კომპილირებული ფაილების კეშირებას ვაკეთებთ, სკრიპტის თითოეული ინსტანსი მაინც ცალკე შეიქმნება და ფიზიკური მეხსიერებაც ცალკე გამოეყოფა.
თურმე სახელიც ჰქონია ასეთ მიდგომას – Shared nothing architecture.

მესმის რომ წარმადობის პრობლემა შეექმნება ასე, მაგრამ საშუალო ზომის ვებ აპლიკაციების შემთხვევაში რამდენჯერ მისულხართ მაგ პრობლემამდე?

(ცალკე დეველოპმენტის რეჟიმში კიდევ – არ ვიცი როგორ ახერხებს რომ კოდი სერვერის მხარეს კომპილირდება და მაინც წამიერად მუშაობს. არადა ჯავაზე ან visual studio-ში თუ ვარ, ყველა გაშვებაზე უნდა დაბილდოს-დალინკოს და აშკარად ვამჩნევ მაგას. დაკომპილირებულ ბიბლიოთეკებში ბოდიალი სხვა თემაა კიდევ..)

ჰოდა node.js-ს რაც შეეხება, მანდ საერთოდ მარტო ერთი ნაკადი გვაქვს. მერე უკან, ჩვენს გარეშე კი აქვს რაღაცები გაპარალელებული, მაგრამ პროგრამისტები რასაც ვწერთ, იქ ერთისთვის ვწერთ და სრულიად არ გვანაღვლებს race condition-ები. მაგის მოდელზე ჯობია ცალკე პოსტს დავწერ.
node-ში წერასაც ექნება თავისი ნაკლები და ბევრჯერ წავიმტვრევ ალბათ ცხვირსაც, მაგრამ ნაკადებზე რომ არ ვფიქრობ, ძალიან მომწონს.

ისიც მესმის, რომ ნელ-ნელა გარდაუვალი გახდება წარმადობაზე ფიქრი და წინსვლისთვის მაინც მოგვიწევს ისეთი პროგრამების შექმნა, რომლებიც ბევრი პროცესორისთვის და ბევრი ნაკადისთვის იმუშავებს, მაგრამ რაღაცნაირად იმედი მაქვს რომ იქნება რაღაც იდეები (მაგალითად როგორც node.js ან როგორც nosql ბაზები) და ნაწილობრივ მაინც მოგვაცილებენ shared state-ის თავისტკივილს.

მეტყვით ალბათ, რომ სიზარმაცის და Thread-ების აზრზე არ ყოფნის გამოა ეს ყველაფერი გამოწვეული. მაგის უარყოფას არ დავიწყებ 🙂

14 thoughts on “რატომ PHP?

  • 20 თებერვალი, 2016 at 16:32
    Permalink

    ყველაზე კარგი ენაა ის რომელიც (I) დავალებას ასრულებს და (II) რომელშიც წერა გსიაამოვნებს. ზუსტად მაგ მიმდევრობით.

    Reply
    • 20 თებერვალი, 2016 at 16:33
      Permalink

      ემოჯები გადამიყლაპა კომენტარში! 😛 🙂

      Reply
    • 26 თებერვალი, 2016 at 23:58
      Permalink

      მართალი ხარ ტოტო 🙂 მეც გეთანხმები მაგაში :))

      Reply
  • 21 თებერვალი, 2016 at 23:14
    Permalink

    მშვენიერი პოსტია 🙂

    ASP.NET MVC ზე ვიტყვი 2 სიტყვით.
    ჩემის აზრით მასში არსებული არქიტექტურა არანაირ დამატებით საზრუნავს არ გიქმნის იმისათვის რომ მონაცემები, შენი სურვილისამებრ, იზოლირებული ან Shared გააკეთო.

    დავიწყოთ თავიდან, ქმნი საიტს ვებ-სერვერზე (IIS) და უთითებ მას App Pool-ს. App Pool რეალურად ოპერაციული სისტემის ერთი პროცესია (w3wp.exe).
    რამდენი App Pool-იც გაქვს ვებ-სერვერზე, იმავე რაოდენობის პროცესები გაქვს ოპერაციულ სისტემაშიც.
    თითო საიტისთვის App Pool-ის პროცესში გამოიყოფა თითო App Domain, თუ ერთ App Pool-ში 5 საიტი გაქვს დაჰოსტილი, მაშინ შესაბამის პროცესში 5 App Domain გექნება.
    ზუსტად ამ App Domain-ით ხდება ამ საიტებს შორის მეხსიერების და სხვა რესურსების იზოლირება. მაგალითად თუ ერთი საიტი დაიქრაშა, მეორე საიტს ეს არ შეეხება.
    როგორც ოპერაციულ სისტემის ფარგლებში პროცესი არის იზოლირებული “ობიექტი”, იმავენაირად არის App Domain-ი პროცესის ფარგლებში.

    ამის შედეგად, ყველა სტატიკური კლასი Shared იქნება ამ App Domain-ის (საიტის) ფარგლებში, ხოლო თითოეული Request ამ App Domain-ის (საიტის) მიმართ, შექმნის აპლიკაციის(HttpApplication) ახალ instance-ს.

    ამ მოცემულობის გათვალისწინებით არანაირი დამატებითი კონფიგურაცია თუ პროგრამირება არ გჭირდება სასურველი ეფექტის მისაღწევად (რისი მიღწევაც არ უნდა გინდოდეს)

    P.S რათქმაუნდა სხვა ქეისია Web Garden კონფიგურაცია, როდესაც ერთი და იმავე App Pool-ზე რამდენიმე პროცესის მიბმა შეგიძლია, მაგრამ ეს უკვე სხვა თემაა.

    Reply
    • 27 თებერვალი, 2016 at 00:02
      Permalink

      მადლობა გურამ 🙂 MVC-ზე მეც კარგი წარმოდგენის ვარ.
      shared-ში იმ შემთხვევას ვგულისხმობდი როცა თვითონ ერთი აპლიკაციის ფარგლებში არის shared ნაწილი.
      თუმცა მე მგონი ჯავას ფრეიმვორკებში უფრო იგრძნობა ეგ და MVC-ზე შეიძლება რო არც შეეხო მაგას.

      Reply
  • 26 აპრილი, 2016 at 16:41
    Permalink

    PHP არ ვიცი. რასაც Scala და Erlang გააკეთებს , მულტისრედინგ ოპტიმიზაციაში იგივეს გაქაჩავს PHP? Async, Async, Asycnc…

    Reply
    • 27 აპრილი, 2016 at 00:44
      Permalink

      🙂 იგივეს არა მგონი. თუ ეგეთი საქმეა, რომ უნდა გაპარალელდეს, ჩვეულებრივი php წააგებს სავარაუდოდ, რადგან მაგის multi threaded გარემოს უკიდურეს შემთხვევაში თუ გამოიყენებს კაცი. პოსტში საშუალო ზომის საიტებზე მქონდა აქცენტი გაკეთებული, სადაც ერთი რიქვესთისთვის ლოგიკის ბირთვებზე დანაწილება არ არის საჭირო.

      Reply
  • 26 აპრილი, 2016 at 16:57
    Permalink

    კიდევ ერთსაც დავაკომენტარებ. ზემოთ ერკლანგი და სკალა ვახსენე და JVM ზე სკალა ძალიან მაგარია – აი რომ იყტვიან სასწაულებს და საოცრებებს ახდენსო :)))) პ.ს EE ზე რაგითხრა მაგრამ Spring ში მეტი სიმარტივე და ფლექსიბილითი გაქვს. თუ გადახედავ ზალიან მოგეწონება. ვებისთვის ჩემთვის ჯერჯერობით Angulad + Spring არის. სწრაფი, კონფორტული საშუალება.

    Reply
  • 26 აპრილი, 2016 at 19:27
    Permalink

    node.js +1. მე შორს ვარ იმ აზრისგან რო Thread-ებში ვინც ვერ ერკვევა იმას მოწონს node.js; უბრალოდ არსებობს სწორი მიდგომები რაღაც პრობლემებისთვის…

    Spring-ზე რატო არ თქვი არაფერი? ერთი პარაგრაფი როგორ ვერ გაიმეტე 🙁

    Reply
    • 27 აპრილი, 2016 at 00:55
      Permalink

      სპრინგზე მეშინია რამის თქმა :))) ახლა ალბათ ბევრი რამე შეცვლილია, მაგრამ მე როცა ვცდილობდი მის გამოყენებას.. სამწუხაროდ ცუდი გამოცდილება უფრო ამახსოვრდება კაცს 😀 ამიტო სურვილი აღარ მქონია, რომ როდესმე მეცადა. ბევრი კარგი რამე აქვს, მაგრამ ძალიან მიჭირს ხოლმე ეგეთი რამის გამოყენება თუ ყველაფერი არ ვიცი, რასაც ჩემს გარეშე აკეთებს. რატომღაც პრობლემების ძებნაშიც კი გაცილებით მეტი დრო მეხარჯებოდა. და კომპილაცია / დაბილდვა რომ სჭირდება, ეგეც დიდი დისკომფორტი იყო ჩემთვის.

      მე სტაბილურობის და უსაფრთხოების შედარება არ შემიძლია. მაგალითად php-ზე უფრო შემეშინდებოდა რამე დიდის და მნიშვნელოვანის დაწერა, ვიდრე ჯავაზე, თუმცა შეიძლება უბრალოდ სხვების სიტყვების გავლენაა.

      Reply
      • 27 აპრილი, 2016 at 12:39
        Permalink

        გუშინ დილის 6 საათამდე Spring boot-ს ვარჩევდი. გადახედე, გაოგნდება ისეთია. არანაერი XML ები! ემბედით სერვერი! არც Jrebel გჭირდება, თვითნ აგვარებს რედეპლოიმენსაც. მოკლედ EE სთან შედარებით სასწაულებს ახდენს. ერთხელ რო მოვიცლი კარგ სტატიას მივუძღვნი. დაჟე მულტრი სრედინგშიც ბევრი პრობლემები გადაჭრა რაც concurrency პაკეტებს არ აქვს;

        Reply
      • 27 აპრილი, 2016 at 23:53
        Permalink

        გეთანხმები ადმინ 🙂 მიჭირს რამე გამოვიყენო თუ ყველაფერი არ ვიცი. სპრინგი ძალიან დიდი და მძიმეა, ღამეები მათენებინა. ონ დემანდ ვსწავლობ ახლა, სამწუხაროდ.

        Reply
  • 27 აპრილი, 2016 at 23:25
    Permalink

    მიუხედავად იმისა, რომ ჯავას მიმართ ჩემი სიყვარული საქვეყნოდაა ცნობილი, web-ის შემთხვევაში გეთანხმები, დაწერა ერთია და შიგნით რა ხდება იმის ცოდნა მეორე. ვებ კონტეინერის მუშაობა რომ გამეგო რამდენიმე წიგნი წავიკითხე, და ამის შემდეგ ვწერდი მშვიდად, იგივეს თქმა შემიძლია EE ზე. Jax-rs ის გამოყენება მირჩევნია web-ის შემთხვევაში.

    Reply

კომენტარის დატოვება

თქვენი ელფოსტის მისამართი გამოქვეყნებული არ იყო. აუცილებელი ველები მონიშნულია *