Мат Дънинг Дроп гол

PHP е вездесъщ език, който освен всичко друго позволява на сървъра да изобразява уеб страница при поискване и да обслужва резултантния HTML на клиента.

Например, обслужваната страница може да е различна за различните клиенти и сървърът "изгражда" HTML на заявка.

Предполагам, че това като цяло е практически мигновено. Но може ли това да е проблем за по-сложните уеб страници? (Пример: ако чрез изобразяване на страница сървърът трябва да получи достъп до услуга на трета страна, която може да има своя собствена латентност)

Ако да, какви решения можем да приложим, за да избегнем този проблем?

  • Реалният проблем ли е достъпът до ресурси на трети страни? Казвате „например“, това ли е вашето желание? Винаги има проблеми със закъснението, свързани с достъпа до ресурси, които не са на вашия собствен сървър. Това обаче не е езиков проблем. PHP е най-популярният език за уеб разработка, но не и единственият.
  • Да, това е моето желание, (опитах се да направя въпроса си по-общ и полезен за бъдещите хора.)
  • PHP е фин и лесен за използване. По-специално, това е добре за извличане на данни от други ресурси. Обаче много зависи от ресурса, скоростта, надеждността, последователността и т.н. Винаги съм извличал външни ресурси, независими от потребителския вход или заявка, но това съм само аз. Намерих възможността да компенсирам проблеми, които могат да възникнат, но в случаите това може дори да не е необходимо. Наздраве !!
  • „Предполагам, че това като цяло е практически мигновено“ - Рядко някога е толкова бързо. Много често се случва PHP страниците да отнемат много секунди за обработка на заявка. Това обикновено се дължи на заети сървъри и голям брой заявки към бази данни, използвани за изграждане на страници.

Проблем ли е времето, необходимо на PHP, за да изобрази страница и да я обслужва на клиента?

Без да дочитам основното съдържание на въпроса ви, имам идеалния отговор.

ДА

Това е така, защото цялото време за обработка, необходимо за представяне на страницата на потребителя от момента, в който потребителят натисне клавиша за въвеждане (от въвеждане на URL или щракване върху връзка), е от първостепенно значение. Толкова е важно, че ако времето е твърде дълго, гостът ще помисли, че сайтът е счупен.

Времето на процеса може да се влоши, когато много хора се свързват към сървъра наведнъж, защото компютърът ще трябва да обработва всяка заявка заедно с обработката на всяка заявка и ако има твърде много хора, които се свързват, тогава някои хора могат да получат закъснения преди част от искането им се обработва. Това зависи от мощността на процесора на сървъра.

Има термин, който е ценен за вас. Нарича се „Време до първи байт“. Това означава времето, необходимо на хората да видят която и да е част от страницата от момента, в който я поискат за първи път. webpagetest.org може да измери тази стойност за вас, когато стартирате който и да е уебсайт през тях. Искате да запазите стойността възможно най-малка (приблизително 20 до 50 ms, ако страниците се обслужват локално, или до 1 ms, ако страниците се обслужват до далечно място с лоша интернет връзка).

Сега, ако търсите начин, по който времето, което PHP процесорът отнема да изобрази страница, не е проблем, тогава можете:

  1. Изхвърлете PHP и използвайте друг скриптов език от страна на сървъра, но след това ще трябва да вземете предвид времето за обработка на този език.

  2. Погледнете други фактори, които биха могли да доведат до значителни времена за рендиране, като например javascript, използван в днешните сайтове, за да промени целия външен вид и / или функционалността на сайта.

Дори ако вземете една от горните две опции, пак ще искате да вземете предвид времето, през което сървърът обработва заявки като цяло, дори ако това означава PHP и / или други сървърни скриптови езици, които се използват за обработка на заявките за гости.

PHP понякога може да бъде бавен понякога в зависимост от това какъв тип PHP се използва от страна на сървъра.

Компютрите могат да изчисляват и изобразяват данни много бързо, но може да има латентност в случай, че скоростта на сървъра не е достатъчно бърза, за да изчисли моментално заявката.

Това може да се случи, когато количеството на съхранените променливи използва значително количество RAM, или когато просто има твърде много процеси и заявки за процесора, за да може да обработва цялата информация.

Също така е много често за езика PHP да се използват различни заявки file_get_content и file_put_content. И PHP скриптът не може да продължи да обработва допълнителен код, докато сървърът не достави или не получи заявката file_get_content или file_put_content. С други думи, ако отнема 2 секунди, за да заредите страница чрез file_get_content, това ще са допълнителни 2 секунди, необходими на вашия сайт за визуализация и зареждане.

Това беше проблем ... преди 20 години.

Разбира се, ако имате други основни проблеми като лошо написан php код или сървър, който има някои сериозни проблеми с управлението на зареждане и ресурси, в крайна сметка това ще бъде проблематично и ще се прояви като "бавно зареждане на php страници". Но същото би било вярно, ако използвате скриптове от страна на сървъра или обаждания към базите данни; или наистина обслужва НИЩО изобщо при тези условия.

Кодирам изключително управлявани от данни php уеб страници за всичко в момента; и компилирането и изпълнението на php НИКОГА не е проблем или забавяне за мен.

Зареждането на големи ресурси като jquery, css библиотеки, bootstrap и т.н. може да е проблем. Но ако ги заредите с помощта на асинхронизация (когато е възможно), тогава страницата ви ще продължи да се зарежда и също няма да ги чака. И те най-вероятно ще бъдат кеширани след първото зареждане, така че нулево време и след това.

Накратко: Въпреки че има много неща, за които да се притеснявате при проектирането на вашия уеб сайт и потребителски интерфейс, правилно написаният PHP код не е един от тях.

  • Има причина, поради която уеб сайтовете с висока производителност не използват PHP и други програмни езици от тип скриптове. С увеличаване на изискванията за производителност, като увеличен брой потребители, PHP ще се превърне в проблем, при който ще трябва да се направят допълнителни подобрения на сървъра или промяна в използвания език.
  • Рамката на Facebook Hack е изградена върху PHP. Предполагате ли, че те не са сайт с висока производителност? Всички сайтове на Xenforo също работят на фреймворка Zend, също изграден на PHP. Започвайки с версия 5-5.5 PHP стана много по-здрав език, позволяващ взаимодействие.
  • Не съм виждал тестове за сравнение през последните 5+ години, които предполагат, че PHP е "бавен" в сравнение с други езици за програмиране на SS. Или че обикновено е тясното място във всякакви проблеми с производителността, свързани с голям трафик на уебсайт, когато се прилага правилно. Ако имате някои източници, моля, цитирайте ги тук, тъй като бих искал да ги видя.
  • Хвърлете достатъчно хардуер на даден език и той ще се покаже бързо на всеки. Ако искате да бъдете разумни, използвайте език, който не се нуждае от толкова хардуер, за да изглежда бързо. И нито един интерпретиран език, като PHP, не може да се сравни с компилиран език.
  • Искам да добавя, но нямам време, че Facebook има компилатор за превръщане на PHP в роден код и разчита на C / C ++ в бекенда заедно с други езици. Бързо търсене не можах да намеря нищо, но един бивш инженер каза, че използват само PHP, защото все още има наследствен код. Новият код е по-вероятен не написана на PHP или е компилирана преди време.

е работил за вас: Charles Robertson | Искате ли да се свържете с нас?