Requests are really slow on mac

[louis-l]

Hi,

Thanks for the awesome package. Im trying it in my new project and realise that the HTTP requests are really slow, ~2s each.

I guess its the docker file sync issue? Any way to improve that using this package?

P/S: Im using Mac.

Cheers,

[sinnbeck]

Sadly I generally hear reports of docker being slow on Mac. Sadly I don't own a Mac, so I have hard time tweaking it to run faster (if possible).

If anyone with docker experience and a Mac, want do try tweaking the volume creation, and add a pr, that would be appriciated

[sinnbeck]

@louis-l I made a quick branch to test volume caching for mac. If you want to try it out you can install it with

composer require sinnbeck/laravel-served:dev-volume_cache

No promises. Seems that Mac and Docker has a long standing history of not working well together

[iammikek]

@sinnbeck I just checked out new version on my Mac mini, and a basic

Route::get('/test', function () {
    return response()->json(['foo'=>'bar']);
});

renders to page in around 900ms.

calling a basic livewire counter, returns an updated response in just over a second.

[sinnbeck]

@iammikek Thanks! Too bad. It also seems that they are trying to find where to take it in the future. Maybe an NFS share from what I can read. If anyone with mac/docker experience have any ideas, please feel free to comment :)

[pfaffenrodt]

@sinnbeck this is file related.

• only for mac mount volumes with :cached (instead of :delegated). files may be out of sync, but thats faster, than waiting a second of a http request.
• if cached is not an option, than create a volume for vendor and storage that is not synced to mac file system.
• use redis for cache, sessions and so on

On windows threre is wsl2 now and this is no issue there anymore.

[sinnbeck]

@pfaffenrodt Thanks? Sadly that is exactly what I tried. The above branch adds :cached to both php and web container. Sadly it apparently doesn't help. I will need to get my hands on a mac for testing myself.

[zendraxl]

@sinnbeck as a first tweak I would suggest moving Xdebug to separate container. After that we can see what can be done to fix slow requests.

[sinnbeck]

@zendraxl Do you mean having 2 php containers (one with xdebug and one without)? I have never seen any examples of running xdebug completely by itself. And it should be easy to test without it (simple disable it and rebuild)

Change it to disabled in served.php

'xdebug' [
    'enabled' => false
],

And run

php artisan served:up

[zendraxl]

@sinnbeck thanks for replying to my comment

Do you mean having 2 php containers (one with xdebug and one without)?

Yes, that is exactly what I mean. Current setup would require us to run served:up command to rebuild, while approach with two containers is more flexible and does not require developer to be constantly aware what is the current state of Xdebug. Since Xdebug container does not have to run in the background, it will not eat any resources like battery/CPU/RAM, but it will only be active during testing.

The way I run my containers is that I have one for PHP, one for test and one for debugging. That is 3 almost identical containers, but all serve purpose and do not affect each other.

Hope you like my idea and apply it, but if not I'll understand. All best.

[pfaffenrodt]

@sinnbeck you use :delegated and not :cached in the cache branch.

@zendraxl In my experience xdebug will affect the response time, but not that much that it is up to a 1 sec. In most cases it is filesystem related.

For best response time is not to sync vendor and storage dirs. Devs need to know, that files are not on the host filesystem.

mount volumes:

• vendor:/var/www/html/vendor
• storage:/var/www/html/storage

and perform composer install on booting docker container. This whole scenario would not be necessary on linux file system.

Edit: maybe more details in this blog that I found http://blog.michaelperrin.fr/2017/04/14/docker-for-mac-on-a-symfony-app/

[sinnbeck]

@zendraxl thanks for the idea. Not quite sure how to implement it. I would assume the webserver would need to handle each php instance, and serve it on a different port?

@pfaffenrodt Doh! I was certain I had used cached. I will update the fork as soon as I can.

But that is actually an interesting idea. But as I understand the article you would need to move the folders to a new location (out of the app directory)?

Anyways, I might be able to check the OS and use that to determine which way volumes are handled. I already check for windows. Hopefully I can borrow a mac tomorrow to I can test it out.

Thanks for the ideas. I will try to get some better performance out of Mac, but no promises. Seems like people are still struggling (the article is 3 years old)

My biggest concern is to not break Linux or windows as they now work great

[zendrax]

@sinnbeck Depends on your workflow. If you put a breakpoint and run a test with debugger then you only need to have other container with XDebug. But if you are listening for a connection then I'm not sure since I haven't used that for a long time. I always create a test proving that the bug exists or to guide me develop new feature.

If someone is using listen for connection, please try and report back.

As for ports, on container without XDebug you only have 80 or whatever. While on XDebug you only expose 900x port.

Hope this makes sense.

@pfaffenrodt yeah, but it all depends on the machine, and Docker is pretty bad on Mac. I'm not saying that it will slow it down that much, but I've seen scenarios where it will add substantial amount of overhead, especially over the course of full test suite.

[sinnbeck]

@zendrax Thanks. I will look into it :)

@pfaffenrodt New version ready with cached. Sadly the laravel splash page is still 1 second to load.

[pfaffenrodt]

@zendrax you are right.

@sinnbeck I guess it depends on the mac hardware. On our docker envs it has at least 230 ms on mac. We tested with :cached and :delegated it make just a litte difference. I let my colleague test it with laravel served.

*edit:

400ms landingpage of laravel 8.4 with cache branch.

We had with Laradock a 230 ms response time (but not with the landingpage)

[sinnbeck]

@pfaffenrodt Thank you so much for testing. It's quite an old Mac (reinstalled today though), so that might have something to do with it.

I am almost done with implementing your suggestion regarding unsynced directories (just fixing a few permission issues).

[sinnbeck]

@pfaffenrodt New version is up with your suggested changed. It dropped the loading time to around 200-300 ms! That is way better :)

Be aware that after running php artisan served:up you will need to run php artisan served:ssh and then from there composer install

[iammikek]

@pfaffenrodt @sinnbeck let me know if I can help with testing. I’m running a 2014 Mac mini i7 3ghz with ssd and latest Mac OS

[sinnbeck]

@iammikek You are very welcome to install the newest version and see if it runs fast for you as well :) Remember to run served up

composer require sinnbeck/laravel-served:dev-volume_cache

[iammikek]

@sinnbeck sure thing. Will update here when I have

[sinnbeck]

@zendrax Xdebug fix has been posted here https://github.com/sinnbeck/laravel-served/issues/27 if you want to have a look :)

[zendraxl]

Very nice support. Thank you @sinnbeck