How come all of wordpress files not uploaded in EFS? #19
Comments
|
Hi Welby, I think that could work if you copy all of the WordPress files onto the file system during deployment and use the document_root option serve the mounted directory. You would need a script to manage the copy operation and avoid overwriting the files after installation. |
|
Can you elaborate on "You would need a script to manage the copy operation and avoid overwriting the files after installation" Also this would mean I can just update the files on EFS and have it instantly change on all the servers right? (I don't have to go through eb deploy) |
|
I agree with @wobeng that things would be easier if the setup was just a php beanstalk environment with document root pointing to an EFS folder. Plugins could be installed and updated through the UI without any redeployment. I've googled a lot and nobody seems to be doing this. Do you know why ? Is it only for performance reasons or would it cause stability issues ? |
|
I'm going to test this out with OPcache to see how well it works |
|
After the mount script, you could have another script copy the WordPress files onto the mounted file system. You only want to do this once, but the script will run every time an instance is added to your environment by AutoScaling, or if you upgrade to a newer Beanstalk platform version. Please try it and post your findings! |
|
@mwunderl not sure if we are all on the same line. In our scenario there would be nothing to copy because the whole wordpress install will be in EFS. |
|
@oadam that's exactly what I was going to ask. |
|
How would you get the WordPress files onto EFS? |
|
@mwunderl I was thinking of updating EFS separately from ELB. This way if I update my EFS, all my servers are updated instantly |
|
github --> codebuild --> mount efs --> upload/update files All elb servers updated. |
|
@mwunderl my setup would be mounting the EFS on my personal machine, unzip a fresh wordpress in it, and launch the environment using the EFS volume as the webroot. |
|
@oadam there might a lag maybe..that's why I suggested OPcache |
|
The benefit of the current design is portability and ease of setup. Everything runs through Beanstalk environment creation and deployment. I would like to see an alternate version where the EFS file system is independent (see 15) as long as the deployment was automated with CloudFormation templates and scripts. Processes that involve mounting shares or SSHing into hosts locally are too fragile. |
|
The wp-config.php in this project is modified to use environment variables through Beanstalk for configuration. The mount configuration is built with that and the deployment concerns noted above in mind. |
|
The flaw with the current setup is not being able to install a plugin or update WordPress via admin panel. so it's easy to setup for hard to maintain. Mounting EFS local for development and mounting EFS as web root in ELB seems to be the best option. |
|
@welby, what you're describing is the difference between two methodologies
of running WordPress.
The eb-php-wordpress is intended to be a throw-away service that scales up
and down with a static WP installation that is maintained outside WP and
deployed dynamically as things / code / versions change. This is by design
an unstable environment - as in - it doesn't care if an instance of WP
dies, since another will scale into place. Visitors get stability because
there is always an instance ready to respond, even if it only turned up 3
seconds ago. Instance uptime is generally measured in hours or days.
What you describe, the ability to install a plug-in and have it available
across everything instantaneously is a long-lived cluster where the code is
updated within the running WP installation and plug-ins / upgrades /
enhancements are run within the environment. This is by design a stable
environment and intended to stay up, no matter what. Visitors get stability
because the server continues to run, no matter what. Docker thus far
doesn't in my experience have uptime measured in years, let alone months or
weeks.
In my opinion, if you combine both, the ability to have a throw-away
service and the ability to install a plug-in, you get the worst of both
worlds. An inherently unstable environment combined with an inherently
stable environment.
If you want (unskilled) end-users to be able to install plug-ins, you need
a stable environment. If you want (skilled) developers only upgrading the
environment, then you need the eb-php-wordpress implementation.
Ultimately your selection depends on who is in charge of what's installed
on WP.
…On 21 February 2018 at 03:17, Welby Obeng ***@***.***> wrote:
The flaw with the current setup is not being able to install a plugin or
update WordPress via admin panel. so it's easy to setup for hard to
maintain.
Mounting EFS local for development and mounting EFS as web root in ELB
seems to be the best option.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#19 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AXj-JDZd6rJLq-4mlHRnTh3tBpP_6XLsks5tWxozgaJpZM4SMULo>
.
--
Onno Benschop
()/)/)() ..ASCII for Onno..
|>>? ..EBCDIC for Onno..
--- -. -. --- ..Morse for Onno..
If you need to know: "What computer should I buy?" http://goo.gl/spsb66
ITmaze - ABN: 56 178 057 063 - ph: 04 1219 8888 -
onno@itmaze.com.au
|
|
I have a system setup now with a zipped wordpress installation saved on EFS and unzipping it to a new folder with it being mounted on an EC2 is incredibly slow. Copying an existing folder is also incredibly slow. With my basic setup and around 20 plugins, it takes about 10-15 minutes to do this vs ~5s on my EBS. I recently mounted an efs to my apache folder and have redirected the root to use efs. Page loading is fine, but deploying new installs with my current method as well as updating plugins are incredibly slow. I'm thinking of either pregenerating and caching these unused installations in my setup, or a way to have the wordpress install (with plugins) sit on my EBS2 on the EC2 and then run the wp-configs off of EFS. I'm open to new ideas, but the inability to spawn multiple wordpress installations in a fast manner seems like a big downer. Other tutorials have suggested preloading your EFS with a large file to shift it into the next tier for better IO but it seems like a hack implementation and you still won't get anywhere near the speed of EBS. |
|
Could you share the way your whole setup is? I have migrated a WP site (similar to urs, ~20 plugins) from a standalone server to AWS. Current architecture is a Nginx+Php-fpm+MySQL individual instance setup and mounted with EFS. All WP files are put on the EFS. The old server is a 2vCPUs-2GB Ram SSD machine while now I have 3 t2.micro instances + 1 EFS. The initial thought expects page loading should be much faster, yet it's terribly slow. DOM load time of the old server and AWS setup are ~4s and ~20s. I know there will be some overhead for communication using individual instances v.s. all-in-one server. Furthermore, the WP files are now at a network drive, the EFS, which introduces even more overhead. But such loading time could never be acceptable. I tried the Beanstalk but never success a single deployment even I followed the official BeanStalk for WP example. The BS is incredibly slow and those useless error messages drove me bonkers. This motivated me to use instances directly. However no good result at all. |
|
FTR I am in the process of migrating all of my WP sites OFF of AWS and onto
Flywheel. Unless you are doing something extremely out of the box with your
WP sites, AWS is over-kill in terms of complexity and adds a ton of
additional maintenance tasks - and at a higher cost than a WP-specific
webhost like Flywheel.
From: ihmc3jn09hk <notifications@github.com>
Sent: Saturday, February 9, 2019 11:32 AM
To: aws-samples/eb-php-wordpress <eb-php-wordpress@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Subject: Re: [aws-samples/eb-php-wordpress] How come all of wordpress files
not uploaded in EFS? (#19)
@wywarren <https://github.com/wywarren> Could you share the way your whole
setup is? I have migrated a WP site (similar to urs, ~20 plugins) from a
standalone server to AWS. Current architecture is a Nginx+Php-fpm+MySQL
individual instance setup and mounted with EFS. All WP files are put on the
EFS. The old server is a 2vCPUs-2GB Ram SSD machine while now I have 3
t2.micro instances + 1 EFS. The initial thought expects page loading should
be much faster, yet it's terribly slow. DOM load time of the old server and
AWS are ~4s and ~20s. I know there will be some overhead for communication
using individual instances v.s. all-in-one server. Furthermore, the WP files
are now at a network drive, the EFS, which introduces even more overhead.
But such loading time could never be acceptable. I tried the Beanstalk but
never success a single deployment even I followed the official BeanStalk for
WP example. The BS is incredibly slow and those useless error messages drove
me bonkers. This motivated me to use instances directly. However no good
result at all.
-
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#19 (comment)
58501> , or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADk_nwkAsR4Fm_ur0MGXE3E5T
UcQJl3tks5vLvftgaJpZM4SMULo> .
<https://github.com/notifications/beacon/ADk_n5sjztXH-nC5U-oaSz97QFeu0Iz1ks5
vLvftgaJpZM4SMULo.gif>
<https://t.sidekickopen78.com/s2t/o/5/f18dQhb0S7kC8dDMPbW2n0x6l2B9gXrN7sKj6v
5KRN6W56jT_C2BgZ2TW3LvrVv3ScfPdf197v5Y04?si=7000000001029516&pi=5c5dd378-61b
3-473e-b3a3-cce624468d25>
|
|
I ended up doing a neat cheat to leverage a setup that uses the best of EFS and the best of EBS to create a hybrid mix. After crawling through multiple blog posts and articles, it seems EFS as a whole is ~5 times slower in IOPS compared to EBS. In my tests it was much slower than that. The only recommended cheat from the readings were to stuff oversized large files into the EFS to bump up its tier to allow for higher IOPS. Also, at the end of the day, EFS's concurrent access capabilities are more expensive than EBS storage. So if you're running a single website, that requires high availability, putting all the core wp files onto the EFS is an OK approach. Although plugin updates and other IO will be a bit slower, all changes can be done once and propagated across all EC2 instances. In our case we're running multiple sites that require high availability and require better/scalable maintenance. We started by looking at how Wordpress Multisites are setup. We took a sample installation and modified the provided htaccess file and used that for our server. In this setup we begin by installing https://wordpress.org/plugins/amazon-s3-and-cloudfront/. It offloads all the image files onto S3. With this all we have sitting on the EBS is the single wordpress folder (with all the plugins). The wp-config.php on the EBS refers to different wp-config.php sitting on the EFS depending on the url path for each site. The EFS wp-config.php's refer to different database connections which determine which plugins in the folder are activated or not. If there are any future updates, we would end up just updating one EBS and creating a new image from it and then destroying and recreating them behind the load balancer. The amount of overhead storage on the EBS becomes significantly lower as it only contains one wordpress folder as a base and no media files. You could technically do custom routing for certain url paths to store test environments on certain EBS volumes as well and roll them over to production that way, but I'm still looking into more effective ways to do this. The downside (if you want to call it that), is that all sites have the same set of plugins installed although they can be selectively activated for each site. |
|
For anyone interested, to save your time, I have confirmed the major overhead is at the EFS junction, legit! |
|
I have set a new wordpress account on was with Fargate, EFS, Aurora My SQL using cloud formation. Now as an Infra set up all the components are in place. But let's say different developers work on different parts of WP like plugins/themes etc now we want to push that folder onto EFS via git repository. I am not sure what should be the correct way of deployment I don't want to run my stack again for WordPress image /efs/rds to setup again. There should be a proper way to upload those into EFS. I have one approach in mine, but not sure if it is the correct one. I can zip my plugins and themes folder and send it to S3 bucket through Jenkins. and then use Aws data sync to copy data to the efs directory. Can someone guide me in the right direction or what should be the correct approach . . ? |
Hi,
How come all of WordPress files not uploaded on EFS? This will make updating wordpress much easier.
The text was updated successfully, but these errors were encountered: