Source
r/PHP•
marktheprogrammer

[Poll] Do you use preloading in your applications?

As of version 7.4, PHP supports the preloading of files, functions, and classes (https://www.php.net/manual/en/opcache.preloading.php).

Do you use preloading in your applications?

If you do use preloading, please leave a comment (or upvote an existing comment) explaining how you handle restarting the PHP process after deploying new code.

If you do not use preloading, please leave a comment (or upvote an existing comment) explaining why.

View Poll

Posted Jul 4, 2021, 1:30 AM UTC

1141
ockcyp•

using symfony generated preload file

15
Annh1234•

There should be another option: long running scripts. You load your files once and they stay in memory, making this PHP preloading obsolete.

6
JordanLeDoux•

That's what projects like React and Swoole do. Not saying that something like this should never make it into the interpreter, but it would probably require something like an event loop in core in order to handle state.

The thing is that PHP programs are almost entirely made with the assumption that the state when the program runs is empty. The Superglobals get loaded with data from apache, php, etc., but the program itself is in an empty state.

Things like unset() would need to be called much more frequently in most code, associating particular variable states to particular requests... a lot of the stuff that is usually handled by a web server.

On the other hand, having a long running program like that could enable programs where an evolving state is the feature. Things like simulations.

What I'm getting at is that even if this was an option in PHP, it probably wouldn't be an option for your program, and if it is, then you're probably already using one of the solutions to that which are available.

2
wolfy-j•

We write enterprise software on PHP full on RoadRunner for last three years. Assumption about dying model are purely in engineer head. Typically it takes around a week to completely retrain (I mean with bottlenecks and optimization practices) engineer to work long running apps.

6
JordanLeDoux•

Fascinating! Would you write up an article sometime about the process you guys use? I'd be interested in reading it.

2
wolfy-j•

Already did - https://spiralscout.com/blog/php-was-never-meant-to-die

Also there is an article on PHP architect (https://www.phparch.com/article/on-the-road-to-long-living-php/ ) and a dozen of talks on YouTube :)

Oh, and a full stack framework optimized for resident memory model - https://github.com/spiral/framework

10
abhibeckert•

"Long running" doesn't have to be hours.

I have a cron task that launches once per minute and it exits once the minute is finished (if it's idle).

Running outside the web server allows these tasks to run without the time/memory restrictions applied by the web server.

2
sysLee•

Maybe have a look into supervisor if you do not know that tool, we use that to keep our php processes running, much better than with cronjobs (at least in our usecase)

3
Zurahn•

Depending on what the server is running, you can also achieve the same result using systemd services.

1
Annh1234•

We use Swoole for a few years, and the code reloads only on releases. ( Some services have been running for 8 months).

That's why I suggested this would be a pool option, since on these systems no selection applies.

1
seaphpdev•

We use containerized PHP services using a PSR-7 micro-framework and React/HTTP. Works just fine. Does require a slight paradigm shift in PHP developers that are used to writing sloppy leaky code because they could get away with it in a PHP-FPM world. But the benefits are clear: super fast and easily deployable.

1
yeskia•

Love the idea, but waiting for Laravel to do it out of the box (if it’s worthwhile enough to do from the framework level). Though they may be pushing more towards Octane these days.

5
JordanLeDoux•

This is particularly a problem with Laravel... designed to make starting your project so easy that you never question how hard it will be to improve or support your project. Everything done in the vendor-lock-in-style because that's how Taylor makes money by selling stuff that should be in the documentation. Whole swaths of available libraries and programs that the open source community has created that just can't be used because of the utterly insane architecture that is designed to resist static analysis (because how else could you make money off of selling what should be in the documentation).

Ah well. I hope you get your features, it sucks you need to wait. Because trust me, having been forced to work with Laravel on several projects, I wouldn't want to try to do it myself and get stuck in that house of mirrors.

EDIT:

As much as I dislike Laravel personally (went on a whole rant below because I was asked), I really think people shouldn't be downvoting the comment I'm replying to. u/yeskia is contributing the the discussion on the original topic, and people shouldn't be downvoting the comment for... using Laravel? I don't really get it. I don't like the framework, but I have no ill-will towards other devs who happen to use it.

31
AegirLeet•

Everything done in the vendor-lock-in-style because that's how Taylor makes money by selling stuff that should be in the documentation. Whole swaths of available libraries and programs that the open source community has created that just can't be used because of the utterly insane architecture that is designed to resist static analysis (because how else could you make money off of selling what should be in the documentation).

Do you have any concrete examples? I've never encountered a (framework-agnostic) library that didn't work with Laravel. Why and how would that ever be the case?

Also disagree with the static analysis take - we have dozens of Laravel applications that pass Psalm's static analysis with the strictest settings. All it takes is the Laravel plugin and some DocBlocks here and there.

9
yeskia•

Disagree. The benefits of Laravel and it's ecosystem as a whole outweigh my missing out on preloading. I could still use preloading if I wanted to put the effort in myself, but I'm lazy and would prefer a community battle-tested solution in the framework.

I don't get the hate towards Laravel, nor the support for your comment.

4†
JordanLeDoux•

I don't get the hate towards Laravel, nor the support for your comment.

I know. No one gets it until they get it. :/

It's hard because Laravel is a situation where the devs who use it are just like any other dev. Using Laravel doesn't tell me that the dev is bad, or unskilled, or whatever. I don't see that on a resume and wonder about them.

But the framework itself makes several compromises that aren't obvious until you actually try to build an application with it. Not a blog site, or a client project, or something like that, but an actual web application. And then it suddenly is like... well, like being in a house of mirrors like I said.

I will never work with Laravel again. The last time I was looking to change employers, I didn't even apply to positions that used Laravel. But I don't begrudge the people that do work in it, and I don't go around telling them they should stop using it.

Ironically, the lack of community battle-tested solutions is my single biggest problem with Laravel. Getting most composer libraries to work with Laravel, unless they are specifically designed to, is an absolute nightmare at times. It's so hit and miss that there were times I would skip over packages that perfectly performed the job because the documentation didn't specifically say it was compatible with Laravel and I couldn't afford to get 30 hours into the project and then tell my boss that I needed either double the time or to start over using a different solution.

Laravel is designed to lock you in to The Community^TM and never let you out. I didn't fully realize how true that was until I had a conversation with Taylor on this very subreddit a few years ago. That was before he deleted his account and fully gave up on participating in the larger PHP community.

A small example: the creator and maintainer of Psalm posted here a few days ago because they were stepping down from doing much development on the project any more, and support for Laravel was brought up in the comments. This was his reply:

Taylor's on record saying he doesn't care if Laravel code cannot be statically analysed. If you want things to change, you might use your influential position in the Laravel community to push back against that sentiment.

If you are using Laravel, you depend on one developer in reality: Taylor. If you are doing any other kind of PHP development, you can benefit from the efforts of hundreds of prominent and talented developers.

I don't hate Laravel because of that on its own, I hate Laravel because it's that way on purpose. The feature of Laravel is that Taylor gets to be the person you have to go to and pay for books, or seminars, or training when you need to do the complicated stuff.

Or you can spend hundreds of hours figuring it out, that's absolutely an option.

But in the last week I've spent a total of only 12 hours working on two projects and have already created one program that will analyze a code base and the extra meta information from the code and docblocks, and another that will turn that analysis into markdown documentation that already works for other projects like RTD and mkdocs. From scratch, an empty repository.

I've seen some devs perform absolute wizardry to make plugins for Laravel that do amazing stuff, and every time I wonder how many more things they could have made if they hadn't been boxed into Taylor's house of mirrors.

11
[deleted]•

[deleted]

1
marioquartz•

Some of your sentences remind me my hate from Simfony. And I dont use Laravel either.

0
Notoyota•

It feels you're misguided. I think your whole point resolves around the notions that Taylor would be developing all of Laravel alone and that he would be making money off of "things that should be in the documentation".

Personally I think you're wrong on many levels. Taylor is not a solo developer. Laravel has multiple core devs now and besides that a active community of contributors. Laravel has in my opinion the absolute best documentation. For example: I recently had to work on a Java Spring framework and was appalled by the lack of documentation compared to Laravels. Laravel and a lot of it's additional tools/libraries (like Horizon and Telescope) are completely open source. If you are "missing something from the documentation" Taylor won't make any money if you open the source code and see how it is supposed to work.

You complain about being locked in The CommunityTM, but in my experience this is hardly a lock at all. Sure if you tie all your code to Laravel specific stuff you would have a hard time switching to another solution, but that would be your own design choices at fault and not Laravel. it specifically allows for multiple choices to do the same things. You can bind routes with closures, controllers, invokable classes. You could use validators inline or in a FormRequest class. You can use Facades or choose to not use them, heck you don't even have to use the ORM. I'm not sure if these examples will resonate with you, but the point is: you're free to do what you want but you might use the framework to assist you in certain areas. I don't even relate to your point that getting other composer libraries to work within Laravel would be hard. There is absolutely nothing that Laravel would do to prevent that. You require your library and you use it. It's your code that calls the library. Laravel has nothing to do with it.

I'm not saying you have to love Laravel but if you hate it you have to hate it for valid reasons not because your assumptions about it.

-5†
zmitic•

I don't get the hate towards Laravel, nor the support for your comment.

The "hate" towards Laravel has been discussed many times here. Just a few examples:

  • magic everywhere
  • subpar ORM
  • no constructors for entities
  • no forms; existing package is too weak
  • very few features when compared to Symfony
  • lots of users show cult-like behavior; when Taylor changed 1 line in symfony/some-package, it was cheered like he made the cure for cancer

​

I find static analysis to be the most important part of the application; put psalm on level 1 and PHP feels totally different.

I like to joke: it makes PHP feel like a real programming language 😄

​

You can't do that with Laravel, at least not without suppressing errors. But if you do suppress them; why would you even want to use psalm, right?

7
JordanLeDoux•

when Taylor changed 1 line in symfony/some-package, it was cheered like he made the cure for cancer

There is a thread from 4 years ago where Taylor posted some "code complexity metrics" from Laravel. It had gems like... "% non-static methods: 95%". He was directly comparing it to how complex the code for Symfony was, I think as a marketing thing.

Anyway, when he was asked about the fact that Laravel has tons of symfony components as requirements in its package, he claimed that most of them were barely used.

This was the list of deps at the time of the thread (symfony component deps that is):

"symfony/console": "3.1.*",
"symfony/debug": "3.1.*",
"symfony/finder": "3.1.*",
"symfony/http-foundation": "3.1.*",
"symfony/http-kernel": "3.1.*",
"symfony/process": "3.1.*",
"symfony/routing": "3.1.*",
"symfony/translation": "3.1.*",
"symfony/var-dumper": "3.1.*",

I asked him directly what the symfony/routing package was use for if it wasn't used for routing. His answer?

We make one call to Symfony routing to compile the route regular expressions. We do not use the rest of their code.

I was like... isn't that almost all of what is actually complex in routing? Isn't the rest of it basically invoking a stored callable?

10
Firehed•

Yes, all source code and several vendor packages. We deploy to Kubernetes so no need to fuss with clearing anything out as it's a new pod.

1
AleBaba•

Symfony. Reloading via "docker-compose restart app".

1
joaojacome•

I tried using it, and the base php response time jumped from 30ms to 110ms. I’ve tried profiling the app, to track down what made it slower, and still have no idea on what happened.

1
AFX626•

Use the XDebug profiler with cachegrind.

2
joaojacome•

Will do!

1
systematical•

Yes, in one of my applications it's a 24% boost (448 rps vs 335 rps for endpoints that pull multiple records i.e. collections). The restart is easy for docker-based applications, since deploying the new image should restart the container and the preload generator builder is part of the image (when the env build-arg is prod). I built this https://github.com/cnizzardini/cakephp-preloader so I can just call bin command.

If you are not using docker you can simply restart php-fpm as part of some sort of deploy script. How complex that needs to be depends on your needs. For most of the stuff I work on, I am not worried about a small "hiccup" restart.

Edit: Question, does preloading matter for things like swoole/roadrunner?

1
Rikudou_Sage•

does preloading matter for things like swoole/roadrunner?

Not really, you will be obviously get a tiny boost when you restart the app, but other than that, no. Saving a few milliseconds on every request is kinda huge, but saving few milliseconds over a longer period? Not at all.

5
wolfy-j•

> Edit: Question, does preloading matter for things like swoole/roadrunner?

It was dead on arrival for such modes. JIT on another hand provides a massive performance boost for long-running processes since your runtime becomes thinner.

1
AFX626•

No. I never saw the point. If I have opcache turned on, the first request might be 230ms, but then the maze of Laravel files are compiled and hanging out in RAM, and the second request is 50ms (half of which is waiting for MySQL.) If that isn't fast enough I can take a crack at Swoole, and I won't have to wait for Laravel to bootstrap either.

1
eldadfux•

We use preloading inside a Docker container. Because we already us Swoole, whenever we make a code update we need to restart the server. We also handle some exclusions as part of our preloading library because some vendor libs are not supporting it well.

1
pfsalter•

Just haven't really had the time to investigate deploying this for our servers, got a ticket faaar down in the backlog to try it out. Concerned for odd bugs to appear due to files changing on the drive (e.g. container cache) but not changing in the opcache.

1
jpresutti•

Honestly, at least for my framework, I saw zero performance gain with preload.

1
0x18•

I'm one of the many "no but would like to" ... we're still supporting PHP 5.6. Thanks, WordPress.

0