-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
suggestion #1
Comments
@abdelhai if I understand it right the build process runs locally that would make it really complicated to deploy/build from windows without using batch scripts which would be possible, but I get where you are coming from and marked it in my to-dos when I have time, mostly to make smaller bins if people don't need all the extensions. This is at the moment more like a POC, I also need to optimize the base config, so timeout and memory is more optimized for deta and firstly the Web server needs to be replaced for real usage. |
the build runs on our build server, not locally. |
@abdelhai great did not know that than I will change it. |
I apparently completely misunderstood how the new system works it's awesome I was still thinking we need to build bins locally because of lambda, but the new build process is awesome will change the whole setup here when I tested everything. |
I tried having a different spacefile from here: https://github.com/tbdsux/space-custom-apps/blob/main/php/Spacefile It works for now, but not tested on more complex frameworks / applications. |
@tbdsux I'm doing it the same way now, but I use the Node.js base using it as a reverse proxy, so it handles static files and files from drive directly if configured. Custom stuff will work, but everything which want to write outside /tmp will make problems. |
It would be a different issue if we include static files. |
@tbdsux your repo is btw. awesome looks like we have the same interpretation of fun ;) I tried building nginx and FPM, but it overwhelmed me, killed the PHP process all the time not sure if there are deta or lambda limits to process creation etc. not really my field. So I ended up with the Node.js reverse proxy. Debugging on the micro is kinda complicated, like always in these situations. Also, the way how micros works makes it so that you could have multiple at the same time tried multi threading and reverse proxying via nginx, but that also ended up unstable not sure if it even makes sense to have multiple php -s servers on the same micro or if it always switches to a new one if one has load should read more about that. So I ended up with the setup I'm working on at the moment, routing everything static or on drive through express for performance and fallback to the PHP server is there is no resolution. I have some other performance ideas, but I need to test at some point if I'm just wasting time. |
Deta micros is serverless while Nginx is a web server, I don't think they complement each other, I'm not sure. Hey thanks for the compliment btw :) |
Sessions will not really work in the php-cli context, that's why I thought of using nginx for fpm/cgi because it's pretty easy to build statically node or python has probably a CGI module as well. Nginx runs perfectly find in the micro context it's just I think the php-cli server does not like running multiple at the same time or something like that it could probably be fixed by having a watcher, but it gets overengineered pretty quickly and needlessly. Building PHP statically is a pain in the ass, trying around with it for years and never got anything out of it, which is consistent if you don't build all the time, I will try to modify one of my older scripts for building fpm and make changes, so it builds the latest version if it works out we could probably have a proper server version as well. Cli is my preferred choice, but most scripts are optimized for the web version. Sessions will still be an issue tho because we have ephemeral instances I'm already working around with syncing with base and drive, but that will not really work for sessions. |
Wow, amazing! Would love to see your progress on this one. |
@tuefekci https://www.php.net/manual/en/ini.core.php#ini.auto-prepend-file & https://www.php.net/manual/en/ini.core.php#ini.auto-append-file for session handling via drive |
that's my active work repo https://github.com/tuefekci/deta-php-server still not done for FPM I will look into it tomorrow when im done with the base on the PHP server. |
I implemented sessions via session_set_save_handler but it looks like its not really available so for session we would need a custom cgi build but then we also need all the extension build against it so the question is do we need reliable sessions. Error is btw. Call to undefined function session_set_save_handler() i never really tried to do more than setting the path manually if somebody else knows better feel free to push your own implementation. |
much appreciation, as it seem @abdelhai 's suggestion in having a prebuilt php unable to push due to the size of php binary ~33mb |
33mb shouldn't be an issue to push. what error are you getting? |
@abdelhai did a push without binary and it succeeded although the deta documentation mentions max file size 10 mb. |
ok now getting |
builder log
|
ok, please report on our discord. this is a separate issue. https://go.deta.dev/discord |
tracing upload when push always result in failure when reaching 10mb.
any specifics on that ?! like what should be the max file size and maximum files allowed when push ?! it always same result when reaching 10mb |
great job. one suggestion, it's probably a better idea to install the PHP binary and pack it with the code ding the Deta build process. like what I did here with the Deno runtime: https://github.com/abdelhai/oden/blob/1a05cb08ad467c37b3c791b5803c1d6df7c03d0d/Spacefile#L6..L16
The text was updated successfully, but these errors were encountered: