기술 스택으로서의 PHP 및 Go.

먼저, 제가 다른 유명한 JAVASCRIPT 기술 스택보다 이것을 선호하는 모든 이유부터 시작하겠습니다.

• 저는 "Javascript for everything" 트렌드를 싫어합니다.. 네.. Javascript는 현 시점에서 거의 모든 일을 할 수 있습니다.. 하지만 그렇게 하는데 효과적인가요?

• 매우 집약적인 CPU 바인딩 작업의 예를 들어 보겠습니다. 이는 CPU 집약적인 작업을 시뮬레이션하는 코드 샘플입니다. 그리고 Javascript가 어떻게 수행되는지 살펴보겠습니다.

이유 1: Javascript는 CPU 바인딩 작업을 제대로 수행하지 못합니다!

setTimeout(function() {
    console.log("Hello world")
}, 1000)

const startTime = Date.now();
while (Date.now() - startTime < 3000) {} //Simulating a long CPU intensive main thread task..

console.log("End")

• 그럼 여기에는 무엇이 있나요? 저는 JAVASCRIPT 사용자로서 1초 후에 "hello world"가 인쇄될 것으로 예상합니다. 그리고 무엇을 추측해 보세요. 그렇지 않습니다. 3초뒤에 "hello world"가 뱉어지네요..

• 왜 이런 일이 발생하는 걸까요? 이를 이해하려면 브라우저와 노드 js의 이벤트 루프가 어떻게 작동하는지 이해해야 합니다. 간단히 말해서 이벤트 루프는 콜 스택과 콜백 큐를 동시에 확인합니다. setTimeout()에 전달하는 콜백 함수는 타이머가 1000ms로 완료되면 콜백 대기열에 들어갑니다.

• 그런데... 타이머가 작업을 완료해도 콜스택은 비어 있지 않습니다.. 우리가 작성한 3초 CPU 집약적 작업을 수행하는 데 여전히 바쁩니다(예.. 시뮬레이션입니다.. 무엇을 하려는지 3초 만에 수행하는 실제 멍청한 프로그램입니다.

• 그래서 콜백 큐와 마이크로태스크 큐의 콜백 함수가 굶어 죽게 됩니다.. 콜백 함수가 형편없습니다. 그들은 3초 후에만 콜스택에 들어갈 기회를 얻습니다. 그리고 이것이 제가 1000ms를 지정했음에도 불구하고 "hello world"가 3초 후에 인쇄되는 것을 보는 이유입니다.

그렇습니다. 웹에서 다운받은 임의의 이벤트루프 이미지입니다.. 멋진 이미지입니다.

excat와 동일한 작업을 수행하는 Go 코드를 살펴보겠습니다.

package main

import (
    "fmt"
    "time"
)

func main() {
    time.AfterFunc(1*time.Second, func() {
        fmt.Println("Hello world")
    })

    // Simulating a long CPU-intensive main thread task
    startTime := time.Now()
    for time.Since(startTime) < 3*time.Second {
    }

    print("End")
}

여기서 1초 뒤에 "hello world"가 출력되는데.. 어떻게요? AfterFunc()는 기본 GoRoutine을 방해할 필요가 없는 자체 GoRoutine에서 실행되기 때문입니다..

이유 2: 저는 개인적으로 클라이언트 측 렌더링을 싫어합니다..

• reactJS에 대해 이야기해보겠습니다. 자바스크립트 구성 요소를 클라이언트에 푸시하고 클라이언트가 목을 조르기 시작하는 많은 것들로 클라이언트의 목을 밀어냅니다..

• 저사양 PC가 정적 HTML 파일을 요청했는데 수많은 반응 구성 요소를 받았다고 상상해 보세요. 클라이언트는 어떻게 느낄까요? 속도가 느려집니다.. 브라우저는 자바스크립트를 구문 분석하고, 가상 DOM을 실행하고, HTML을 생성해야 합니다. 그리고 그렇지 않은 것은..

• 서버가 하는 일은 브라우저가 다 해준다..

• 웹의 자연스러운 흐름을 기억하시나요?

• HTML을 먼저 로드하고 그 다음에 자바스크립트를 로드하시겠습니까? 왜? 초기 페인트를 최대한 빨리 만들기 위해.. HTML 문서의 바닥글에 자바스크립트를 로드하던 시절을 기억하시나요?

• React가 전체 흐름을 거꾸로 만들었습니다.

• 그리고 그 결과 클라이언트는 텅 빈 흰 화면을 오랜 시간 동안 바라보게 되는데..

이유를 말하자면..

• 자신만의 세계에서 빛나는 언어 2개를 선택합니다..

가다

• 직접 인상 깊었던 점은 Go가 컴파일된 언어이고 정적으로 입력된다는 점입니다. Go는 맹목적으로 Go가 엄청 빠르고 javascript보다 훨씬 빠르다고 할 수 있습니다..

• GoRoutines라는 경량 스레드가 내장되어 있으며 Go 스레드는 가볍기 때문에 실제 OS 스레드보다 훨씬 빠릅니다.

• Go는 RESTful 엔드포인트를 구축하는 데 사용되거나 모든 백엔드 서비스에 사용될 수 있습니다..

• 하지만 SSR에는 Go를 사용할 수 없습니다. PHP가 그 점에서 빛을 발합니다.. 내 스택에서 Go는 CPU 집약적인 API나 백엔드 서비스에 많이 사용될 것입니다.

PHP

• SSR에 사용한 것 중 PHP가 가장 좋습니다. 간단하고 매우 간단합니다. 각 클라이언트에 대한 프로세스를 생성합니다. 속도가 다소 느려집니다. 그러나 이러한 프로세스는 동일한 프로세스 메모리 공간을 공유하는 스레드와는 달리 서로 독립적이며 경쟁 조건 및 기타 많은 스레드 관련 문제에 좋지 않습니다..

• 내 생각에는 PHP도 웹과 밀접하게 결합되어 있습니다. $_GET, $_SERVER 등과 같은 기본 슈퍼 전역 변수는 일반적으로 웹 작업을 더 쉽게 만듭니다.

• PHP의 세션관리가 너무 좋네요.. 언어자체로 나오네요.. 그리고 세션관리도 너무 쉽습니다..

결론:

• PHP는 SSR에만 사용할 수 있습니다. 그리고 세션 관리. 나는 CPU 집약적인 작업을 수행하는 데 있어 PHP를 믿을 수 없습니다. 왜? 해석된 언어이며 멀티스레드도 아닙니다..

• 그래서 CPU 집약적인 호출을 모두 Go로 오프로드했습니다.

• 두 가지 장점 중 최고입니다.. SSR용 PHP는 클라이언트가 문제를 겪지 않도록 하고, 동시성을 잘 수행하므로 CPU 집약적인 작업에 사용합니다...

위 내용은 기술 스택으로서의 PHP 및 Go.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!