I'm currently migrating a wordpress installation to azure app services with containers. First I did a normal installation with everything inside the container for testing purpose. The performance was good and and things worked without problems.
Then I wanted to add the wp-content folder to a persistent folder, for this I created a file share and added it under Path mappings. This worked without problems and after the restart Wordpress could access the files.
But now every page load takes about 1-2 minutes and the page as whole is unusable in this stage. I double checked the the file share settings and everything else. Share is optimized for transactions and as soon as I remove the volume, the container is fast as light again.
Does anyone have the same problem? Any ideas how to fix this? This is a deal break for me tbh.
Thanks!
Not answering your question directly but an alternative is to use App Service Persistent Storage that store data in /home folder of the VM where your app is running. It should be a lot faster then using a File Share in a storage account. The ${WEBAPP_STORAGE_HOME} maps to the /home folder.
You need to enable by setting WEBSITES_ENABLE_APP_SERVICE_STORAGE to true in the application settings or by using the CLI:
az webapp config appsettings set --resource-group <group-name> --name <app-name> --settings WEBSITES_ENABLE_APP_SERVICE_STORAGE=TRUE
Related
I'm developing a website using Word Press (Elementor plugin) and I want to create a custom widget. I found a tutorial I want to follow (https://www.youtube.com/watch?v=Ko9i153o_iU), the only problem is that I have no idea how to access the code on my local machine to begin. From what I can tell, everything I'm doing is on the word press website, and the code isn't on my local machine. How do I go about getting the code onto my local machine so I can begin working with it in vscode?
You need a way to spin up local apache or nginx server and mysql, along with Wordpress. I suggest the app Local:
https://localwp.com/
Then, if you want to copy your production environment (your website), you need to get the files for the theme and any plugins onto your local environment. Local pairs with some hosting providers to make this easy. Otherwise you can install by downloading the files. Some hosting providers give you FTP or SFTP access to your site files. Figure out how you can gain access and download them.
Lastly, if you want, you can copy the database over to your local environment. There is a great plugin called WP Sync DB that does this for free. It can also be a way to push your local environment to your production environment, but I definitely suggest keeping backups if you are going to do that.
The Issue
I am currently in the process of integrating a pre-rendering service for SEO optimization, however we use an Azure App Service Plan to scale up or down when necessary.
One of the steps for setting up the proper configuration requires placing an applicationHost.xdt file in the /site/ directory, which is one level above the /site/wwwroot directory where the application itself gets deployed to.
What steps should I take in order to have the applicationHost.xdt file persist to new instances spawned by the scaling process?
Steps I have taken to solve the issue
So far I have been Googling a lot, but haven't succeeded in finding a lot of documentation on using an applicationHost.xdt file in combination with an Azure App Service Plan.
I am able to upload the file to an instance manually, however I have assumed that when we then scale up to more instances the manually uploaded file will not be present on the new instance(s).
Etcetera
We are using Prerender.io as pre-rendering service.
Should there be an easier to set-up & similarly priced service available, we would be open to suggestions as we are in an exploratory phase regarding pre-rendering.
Suppose this won't be a problem, cause all files under azure app are shared between all your instances. You could check it in this Kudu wiki:Persisted files. And in my test all instances will keep the file.
About upload the applicationHost.xdt, you don't have to do it manually, there is a IIS Manager Site Extension to lets you very easily create XDT files. And it will provide some sample XDT's for you.
I'm creating new Wordpress project and I want to make it easily scalable. It will be hosted on AWS (EC2 + RDS). I set up autoscaling group + code deploy and Jenkins builds and deploy the project after pushing into master branch. Now I have following question:
Shall I move whole wp-content out of the server and put it in some place available from other machines in the network? It would allow to keep content separately from the core project code and have it in one location. I cannot just move it to another server, because WP requires it to be available from filesystem. I was thinking about moving it to S3, but it does not seem to be good idea.
Can someone more experienced with WP advice what is the best option here?
I've been cleaning up my directories and noticed that each Meteor.js project takes up at least 77MB (and typically, more like 150MB)! To figure out what was happening, I went ahead and created a new app:
meteor create myapp
At this point, the folder takes up about 7kb.
But after I do this
cd myapp
meteor
the folder size balloons up to 77MB.
After some digging around, I managed to pinpoint to size increase the .meteor/db folder. More specifically, running the app creates these local* files inside .meteor/db which are each >16Mbs. I opened these and they're mainly just a long string of 0000s with a few non-0000s here and there.
If I start doing more -- adding data, to Meteor.collections, etc -- the size balloons to 100+MB.
My questions
What are these files for and why are they so huge?
Is there any way to make my app smaller (zipping the folder cuts the size down to 1.8MB so a lot of the additional bloat looks like it could be stripped away somehow.
Running meteor in development mode (the default) creates an instance of mongodb for you under your .meteor directory. It's huge, I know. But don't worry - this is only for development so you don't need to setup your own mongodb instance on your localhost. You can clean it up at any time by running:
$ meteor reset
When you go to deploy your app, you will bundle your project which does not include any of these files.
To add to what David Weldon said.
If the size of the app locally is an issue, you could always use a Mongo database that is not stored locally, like a mongodb-as-a-service provider such as: MongoLab or MongoHQ
Also, for me using jasmine tests created a mirrors folder totaling 15Gb...
I'm wondering how to pull (or fetch) all the changes that I made on a wordpress installation running on heroku.
Example:
I have a plugin that let me upload an avatar of me on the server (avoiding gravatar). Okay, the avatar is ready and uploaded on the server (in this case, the heroku instance). So, when I do a pull or a fetch to get that change (the image) on my local files, I get nothing else than "Already updated".
I do:
git pull heroku master
And nothing is actually added or changed on the local files. Instead, I get:
From: heroku.com:app-123-456
* branch master -> FETCH_HEAD
Already up-to-date.
So the image I've just upload is not in my local files, but yes in the remote files.
What am I missing here?
Changes made to the dyno filesystem that your app is running on will not be reflected in the git repository associated with your app. Also, the dyno filesystem is ephemeral and changes are lost across deploys and when dynos are recycled (which happens at least daily).
Instead of relying on the dyno filesystem for persistence, you should make sure files are persisted to S3 or similar services.
This custom Wordpress build pack should be a good start: https://github.com/mchung/heroku-buildpack-wordpress