라 라벨이 정말 이렇게 느린가요?

라 라벨이 정말 이렇게 느린가요?

---

방금 라 라벨을 사용하기 시작했습니다. 아직 코드를 거의 작성하지 않았지만 페이지를로드하는 데 거의 1 초가 걸립니다!

프레임 워크가없는 앱과 NodeJS 앱이 ~ 2ms가 걸릴 때 이것은 저에게 약간 충격적입니다. 라 라벨은 무엇을하고 있습니까? 이것은 정상적인 행동이 아닙니다. 미세 조정이 필요합니까?

---

Laravel은 실제로 그렇게 느리지 않습니다 . 500-1000ms는 터무니 없습니다. 디버그 모드에서 20ms로 줄였습니다.

문제는 Vagrant / VirtualBox + 공유 폴더였습니다. 나는 그들이 그러한 성능 타격을 입었다는 것을 깨닫지 못했습니다. Laravel에는 너무 많은 종속성 (~ 280 개의 파일로드)이 있고 각 파일 읽기가 느리기 때문에 추가 속도가 매우 빠릅니다.

kreeves는 저를 올바른 방향으로 안내했습니다. 이 블로그 게시물 은 공유 폴더를 사용하는 대신 파일을 VM으로 재 동기화 할 수있는 Vagrant 1.5의 새로운 기능을 설명합니다.

Windows에는 기본 rsync 클라이언트가 없으므로 cygwin 을 사용해야 합니다. 그것을 설치하고 Net / rsync를 확인하십시오. C:\cygwin64\bin경로에 추가 하십시오. [또는 Win10 / Bash에 설치할 수 있습니다.]

Vagrant는 새로운 기능을 소개합니다 . 나는 Puphet을 사용하고 있으므로 Vagrantfile이 약간 재미있어 보입니다. 다음과 같이 조정해야했습니다.

  data['vm']['synced_folder'].each do |i, folder|
    if folder['source'] != '' && folder['target'] != '' && folder['id'] != ''
      config.vm.synced_folder "#{folder['source']}", "#{folder['target']}", 
        id: "#{folder['id']}", 
        type: "rsync",
        rsync__auto: "true",
        rsync__exclude: ".hg/"
    end
  end

모든 설정이 완료되면 vagrant up. 모든 것이 순조롭게 진행되면 컴퓨터가 부팅되고 모든 파일을 복사해야합니다. vagrant rsync-auto파일을 최신 상태로 유지하려면 터미널에서 실행해야 합니다. 약간의 지연 시간을 지불하지만 30 배 빠른 페이지로드를 위해서는 그만한 가치가 있습니다!

---

PhpStorm을 사용하는 경우 자동 업로드 기능이 rsync보다 더 잘 작동합니다. PhpStorm은 파일 감시자를 방해 할 수있는 많은 임시 파일을 생성하지만 업로드 자체를 처리하게하면 잘 작동합니다.

---

한 가지 더 옵션은 lsyncd 를 사용하는 것 입니다. Ubuntu 호스트-> FreeBSD 게스트에서 이것을 사용하여 큰 성공을 거두었습니다. 아직 Windows 호스트에서 시도하지 않았습니다.

---

문제 해결을 돕기 위해 laravel 프로덕션을 최적화하는 방법에 대해 설명하는 이 블로그 를 찾았습니다 . 앱을 빠르게 만들기 위해해야하는 대부분의 작업은 이제 코드의 효율성, 네트워크 용량, CDN, 캐싱, 데이터베이스의 손에 달려 있습니다.

이제 문제에 대해 이야기하겠습니다.

Laravel은 기본적으로 느립니다. 이를 최적화하는 방법이 있습니다. 또한 코드에서 캐싱을 사용하여 서버 시스템을 개선하는 옵션도 있습니다. yadda yadda yadda. 그러나 결국 Laravel은 여전히 ​​느립니다.

Laravel은 많은 심포니 라이브러리를 사용하며 techempower의 벤치 마크 에서 볼 수 있듯이 심포니 순위는 매우 낮습니다 (마지막으로 가장 낮음). laravel 벤치 마크 가 거의 바닥에 있음을 찾을 수도 있습니다 .

많은 자동 로딩이 백그라운드에서 발생하며 필요하지 않을 수도있는 것이 로딩됩니다. 기술적으로 laravel은 사용하기 쉽기 때문에 앱을 빠르게 빌드하는 데 도움이되며 속도도 느려집니다.

그러나 나는 Laravel이 나쁘다는 것을 말하는 것이 아닙니다. 그것은 많은 일에 훌륭하고 훌륭합니다. 그러나 높은 트래픽 급증이 예상되는 경우 요청을 처리하기 위해 더 많은 하드웨어가 필요합니다. 더 많은 비용이들 것입니다. 그러나 당신이 불결한 부자라면 라라 벨로 무엇이든 이룰 수 있습니다. :디

일반적인 트레이드 오프 :

 Easy = Slow, Hard = Fast

나는 C 또는 Java가 어려운 학습 곡선과 어려운 유지 관리 성을 가지고 있다고 생각하지만 웹 프레임 워크에서 매우 높은 순위를 차지합니다.

너무 관련이 없지만. 나는 단지 요점을 증명하려고 노력하고 있습니다 easy = slow.

Ruby는 유지 관리 및 학습 용이성에서 매우 좋은 평판을 얻었지만 여기에 표시된 것처럼 Python과 PHP 중에서 가장 느린 것으로 간주됩니다 .

---

Laravel 4를 사용하면 가장 큰 속도 향상을 얻을 수 있다는 것을 알았습니다. 올바른 세션 드라이버를 선택할 수 있습니다.

Sessions "driver" file;

Requests per second:    188.07 [#/sec] (mean)
Time per request:       26.586 [ms] (mean)
Time per request:       5.317 [ms] (mean, across all concurrent requests)


Session "driver" database;

Requests per second:    41.12 [#/sec] (mean)
Time per request:       121.604 [ms] (mean)
Time per request:       24.321 [ms] (mean, across all concurrent requests)

도움이되는 희망

---

예-Laravel은 정말 느립니다. 이를 위해 POC 앱을 구축했습니다. 로그인 양식이있는 간단한 라우터. $ 20 디지털 오션 서버 (몇 GB 램)에서 10 개의 동시 연결로 60 RPS 만 얻을 수있었습니다 .

설정:

2gb RAM
Php7.0
apache2.4
mysql 5.7
memcached server (for laravel session)

최적화, composer dump autoload 등을 실행했고 실제로 RPS를 43-ish로 낮췄습니다 .

The problem is the app responds in 200-400ms. I ran AB test from the local machine laravel was on (ie, not through web traffic); and I got only 112 RPS; with 200ms faster response time with an average of 300ms.

Comparatively, I tested my production PHP Native app running a few million requests a day on a AWS t2.medium (x3, load balanced). When I AB'd 25 concurrent connections from my local machine to that over web, through ELB, I got roughly 1200 RPS. Huge difference on a machine with load vs a laravel "login" page.

These are pages with Sessions (elasticache / memcached), Live DB lookups (cached queries via memcached), Assets pulled over CDNs, etc, etc, etc.

What I can tell, laravel sticks about 200-300ms load over things. Its fine for PHP Generated views, after all, that type of delay is tolerable on load. However, for PHP views that use Ajax/JS to handle small updates, it begins to feel sluggish.

I cant imagine what this system would look like with a multi tenant app while 200 bots crawl 100 pages each all at the same time.

Laravel is great for simple apps. Lumen is tolerable if you dont need to do anything fancy that would require middleware nonsense (IE, no multi tenant apps and custom domains, etc);

However, I never like starting with something that can bind and cause 300ms load for a "hello world" post.

If youre thinking "Who cares?"

.. Write a predictive search that relies on quick queries to respond to autocomplete suggestions across a few hundred thousand results. That 200-300ms lag will drive your users absolutely insane.

---

From my Hello World contest, Which one is Laravel? I think you can guess. I used docker container for the test and here is the results

To make http-response "Hello World":

• Golang with log handler stdout : 6000 rps
• SpringBoot with Log Handler stdout: 3600 rps
• Laravel 5 with off log :230 rps

---

I use Laravel quite a bit and I simply do not believe the numbers it tells me because end-to-end rendering as measured by my browser shows LOWER total time from request to ready.

Further, I get slightly higher numbers on my machine at work, which does execute the page noticeably faster than my machine at home.

I don't know how those numbers are getting calculated, but they are not corroborated by observation, or browser tools like Firebug...

Laravel is not actually all that slow, especially when optimized. It is memory-hungry however. Even a heavy CMS like Drupal which is very slow, appears to have about 1/3rd the memory footprint of a bare bones Laravel request.

Thus to run Laravel in production, I would deploy to memory-optimized servers before CPU-optimized servers.

---

I know this is a little old question, but things changed. Laravel isn't that slow. It's, as mentioned, synced folders are slow. However, on Windows 10 I wasn't able to use rsync. I tried both cygwin and minGW. It seems like rsync is incompatible with git for windows's version of ssh.

Here is what worked for me: NFS.

Vagrant docs says:

NFS folders do not work on Windows hosts. Vagrant will ignore your request for NFS synced folders on Windows.

This isn't true anymore. We can use vagrant-winnfsd plugin nowadays. It's really simple to install:

1. Execute vagrant plugin install vagrant-winnfsd
2. Change in your Vagrantfile: config.vm.synced_folder ".", "/vagrant", type: "nfs"
3. Add to Vagrantfile: config.vm.network "private_network", type: "dhcp"

That's all I needed to make NFS work. Laravel response time decreased from 500ms to 100ms for me.

---

Laravel is slow, because in most cases, using PHP for web pages is slow.

With Laravel, the entire framework is rebuilt on every invocation - that is why all pages point to index.php. Since the entire framework is PHP scripts, they all need to go through the PHP interpreter - each time. The larger the framework, the longer this takes.

Contrast this with a "server environment" (e.g. tomcat) where the server runs the initialization code once, and eventually all pages will be in native code (after JIT).

As a reference example, using the same hardware, OS, etc. a simple 'hello world' using JSP on this hardware is 3000 rps, the same hello world on laravel is 51 rps.

The easiest way to test framework overhead, and the resulting maximum RPS per core, is to use Apache AB and a concurrency value of 1, with a simple 'hello world' that is dynamic (to avoid static page caching).

참고 URL : https://stackoverflow.com/questions/23283574/is-laravel-really-this-slow