I have a Plesk reseller VPS and have set it up for running SilverStripe sites. For the most part the sites load well (under a second on average) and works as expected.
The admin also performs as expected, with the exception of Save and Publish. Doing a save and publish (even with one small change) takes over 60 seconds (where as a standard write action takes maybe a few seconds). This is happening for all page types. We are not using any custom onBeforeWrite or onAfterWrite calls and are not using static publisher.
On our development server (also Apache based), save and publish time is less than 10 seconds. Switching to Dev mode on live seems to make no difference.
I am kind of at a loss as to why this is happening or how to diagnose the issue. Has anyone else had this issue?
I am running SilverStripe 3.5, PHP 5.6.3 and Mysql 5.5.
EDIT: I have checked all the logs, the only thing being logged that I can see was the timeout error (which goes away when I increase script execution time).
UPDATE - 13/06/17: I have now installed a smaller (largely vanilla) SilverStripe site on the same server, Save and Publish for this site works as expected (and is very snappy).
I am assuming that this is a module causing the error. I have also contacted support, the on only thing they can think could cause this would be a script is accessing a third party server (which is being stopped by a network firewall). The only module that springs to mind would be the Live SEO module (as this talks to google for it's scoring system).
OK, finally managed to get this sorted. The hosting provider were quite helpful (they usually are), it turned out to be an routing issue in their data centre.
The hosting provider told me that they had identified an issue with IP6 routing that was causing a timeout in some instances. They have resolved this and "Save and Publish" is now working as expected.
If anyone else gets this issue and has ruled out the items mentioned above, I would advise contacting their hosting provider, it may be an external issue.
Related
Evening All,
At by absolute wits end and hoping someone may be able to save me! I am in the process of migrating a number of PHP applications into Azure. I am using:
Linux based App Service running PHP 7.4 (2 vCPUs, 8Gb RAM) at a cost of £94 a month.
Azure Database on MySQL 8.0 (2 vCPUs) at £114 a month.
My PHP apps run well, decent load time of under 1 second per page. Wordpress performance however is awful. I am going from a 1 second page load to around 10 seconds, particularly on the back end. I have read all of the Azure guides and have implemented the following obvious points:
Both the App Service and the MySQL install are in the same data center
App Service is set to 'Always On'
Connection Redirection is set to Preferred and tested as working
The same app runs fine on a very basic £10 or so a month shared hosting package. I have also tried the same setup in Amazon Web Services today and page load is back to a second or so.
In Chrome Console, the delay is in TTFB. I have disabled all the plugins and none stand out as making a huge difference. Each adds a second or so page load, suggesting to me a consistent issue when a page requires a number of database calls.
What is going on with Azure and the awful Wordpress performance?! Is there anything else I can investigate or try? Really keen to stay with Azure but can't cope with the huge increase in cost for a performance hit.
The issue turned out to be the way the file system runs in the app service. It is NOT an issue with the database. The App Service architecture is just too slow at present with file read/writes, of which Wordpress uses a lot. Investigated the various file cache options but none improved enough.
Ended up setting up a fairly basic, and significantly cheaper, virtual machine, running with the same database and performance is hugely improved.
Not a great answer, but App Services are not up to Wordpress at present!
The comments below are correct. The "problem" is the database. You can either move MySQL to a Virtual Machine (which will give you a better performance) or you can also try to use cache plugins such as WP Super Cache as well decrease the number of requests.
You can find a full list of tips in the following link:
https://azure.microsoft.com/en-us/blog/10-ways-to-speed-up-your-wordpress-site-on-azure-websites/
PS: ignore the date, it's still relevant
My site is experiencing slowness ever since we moved over to AWS from a different server provider - the site is built on a LAMP stack and we're not sure what is causing the slowness. We did not experience such significant lag on the previous server.
Some notes:
The site runs fine on a localhost environment which is why we think it's something with our AWS setup (however, feel free to correct me)
For reference, the site IS image-heavy, uses PHP5.6 (so it's outdated), and DOES use a few SELECT * queries on various pages, etc.
We just don't believe the above is the issue, but please let me know if there's often dispensaries between localhost and production environments, because this is the first time I'm experiencing such.
As noted, we did not experience such significant lag on the previous server.
We have tried asking AWS support, where they made a suggestion which made a noticeable difference to the site, but the site still experiences around 5sec lag time per page. They now say they can't find any reason for the lags, but at the same time because of the lags, our site is experiencing much lower traffic (most of the lags occurred with high traffic volume)
We've updated the aws settings a few different times in a few different ways, such as:
Updating the EC2 instance
Updating RDS
Implementing this: https://aws.amazon.com/elasticache/
Some people have reported that there's no lagtime unless a user logs into the site
Any suggestions are helpful! We are hoping to not have to move the site's server again.
I'm having this issue on my production server but not in local development:
Loading any page of the CMS (excluding secondary tabs) fires off a "success" notification, sometimes 5-6+ of them at the same time. I can not seem to track down where they're even coming from let alone what's causing them. I'm at such a loss I feel like I'm even having a tough time explaining it so I'll attach a screenshot.
Server is Cloudways PHP stack: 1GB RAM, Apache/Nginx
That's an issue that was already fixed. See this issue on github.
It only happens on SSL/HTTP2 servers, so that explains why you don't get this issue on your local dev environment.
You should be able to solve your problem by updating the CMS.
We're running a magento web store on Knownhost (VPS).
Most of the time the site works fine. Occasionally (every few hours?) the site will get very slow and unresponsive, and will throw '500 Internal Server Errors'. There doesn't seem to be anything relevant in the webserver or Magento system/exception logs.
Also, it seems that we're seeing high CPU usage on this account.
I have increased the memory limit to 512MB, and tried everything else I could find. No dice.
We have a managed VPS, so we can change pretty much everything. We had our hosted provider install ImageMagick after reading a suggestion online - didn't help.
Any ideas?
(website is available at myerstownsheds.com if anyone would like a look)
TL;DR; You have an under resourced server. Any code or configuration steps you take to reduce load are only going to postpone the inevitable.
It's impossible to provide a concrete answer to your question with the information given. If you could look at your server logs and see the full error message being generated it would be a big help. "Server logs" probably mean "Apache Logs" in this situation, since the error text you provided is a standard Apache/PHP error, and not a Magento error.
All that said, the most likely culprit is a PHP out of memory error. Magento's performance profile is different than most LAMP stack applications, and most generic VPS hosts are unable/unwilling to make the tweaks needed to run it. If you want to solve this problem long term you need a web host that specializes in Magento. I recommend Nexcess (affiliate link) these days, but Magento has a list of recommended hosting partners, and the Magento Speed Test site offers a nice breakdown of the top Magento hosts.
Take a look at your host's plans
The highest level plan tops out at 4GB of RAM (4096 MB).
Take a look at the starting Nexcess plans
The entry level plan provides 16GB. Four times as much RAM as your current host. Magento is a RAM hungry application. Your current host isn't equipped to handle Magento. Any code or configuration steps you take to reduce load are only going to postpone the inevitable.
I followed the instructions posted by allendar:
Backup and delete app/etc/local/local.xml
Go to site in browser, and follow the configuration process
So far, everything seems to be working fine! It's a little hard to say this soon since the issue was so intermittent, but our site has remained responsive for nearly two hours.
I'm going to mark this as Answered in a couple days. I'll look into getting a better hosting plan.
Thanks everyone!
Error
I have a web app with a mass uploader (Plupload) for photos and when I upload say twenty photos, about six (around 30 %) will fail with an Internal Server Error. I have checked the Apache error.log for this domain and it has nothing new (I know I'm looking at the right error.log since older errors did show here).
This only happens on my VPS on Dreamhost (my hosting provider) servers while on my development server it runs silky smooth.
Oh, and things used to work just fine a month ago and then just started to fail. Back then I was using Uploadify and since that used Flash, it was impossible for me to debug where the upload failed.
Files and script
Uploaded files are photos, all about 100 kB big, even though I've successfully uploaded (and still can) 3 MB photos. My .htaccess naturally doesn't change during uploads. On the server side is a PHP script that uses GD2 library to move and resize the photo.
Server state
I have recently upgraded my VPS from 300 to 400 MB of RAM. This thing used to work and I upgraded it just so that memory is ruled out as a reason. Also my memory limit for PHP is at 200 MB, so this should sufice.
I am getting mighty frustrated that Dreamhost does not want to help, stating that "we can not be responsible for an error your code causes" and "We still will not be able to assist you in debugging the issue unfortunately."
It has been a week of sparse "support" while my app doesn't work and my clients are frustrated.
Questions
Is this kind of "You're on your own" support a standard across the
industry, i.e. would your host handle this differently?
How exactly can I debug this?
I'm going to assume that you have a standard Apache + PHP setup. One possible configuration is the pre-forked setup; in this case Apache will adapt to system load by forking more children of itself.
With only 400 MB of RAM you're pretty tight, so if you're running 20 processes that each take 200MB (assuming every process handles pretty big files using GD) you're getting into some hot waters with the memory manager.
I would reduce the total number of instances to 2 first to see how this will go; also keep an eye on the memory usage by running top.
Regardless, it might be beneficial for you to run a separate task manager such as Gearman to perform resize tasks so that the upload only has to focus on moving the uploaded file and run the resize task; this way you can greatly reduce the memory required to run your PHP instances.
As to your Q1: the simple answer is that you get what you pay for. A 300Mb RAM Dreamhost VPS costs ~$360 per annum. For this you get the VPS service and responses on service failure relating to the provision of the virtual environment. The OS, the software stack and the applications are outside this service scope. Why? This sort of custom knowledge-base support could cost $50-300 per hour. You are being unreasonable and deluding yourself if you expect Dreamhost to provide such services pro-bono. That's what sites like this one do.
So my suggestion is that you suck up that anger and frustration and work out how to help yourself.
As to your Q2. (i) You need to understand where your Apache errors go to; (ii) Ditto any SQL errors if you are using a D/B. (iii) You need to ensure that PHP error logging is enable and verify where the PHP logs are going to. (iv) You need to inspect those logs, and verify that logging is working correctly, by using a small script which generates runtime errors.
You should also consider using enhanced facilities such as php_xdebug to enhance logging levels and introducing application logging.
In my experience systems and functions rarely die silently. However, applications programmers often ignore return statuses, etc. For example in the GD library, imagecopyresized() can fail and it returns a status code to tell the application when it has, but if the application doesn't test this status and act accordingly then it can end up going down bizarre execution paths silently, and just appear to the user (or developer) as "it just stopped working".
My last comment is that you should really consider setting up a private VPS within your development environment which mirrors your Dreamhost production config, and use this for integration, acceptance test and support. This is pretty easy to do and you can mess this and add debug / what if options and then roll back without polluting your production environment. Tools like VMare Appliances and VirtualBox make this easy. See this blog post for a description of how I did this for my hosted service.
trying to respond the question 2: if you checked all your code and you didn't see any bug, I thing that the best thing that you can do is to check the version of all the programs running on the server (apache, php, ...), e.g., I remember that I had a problem with a web service it was running on apache and php, the php version was 5.2.8, and after a lot of investigation I found out that that version had a problem parsing xml data.
Regarding the first part of the question: Dreamhost do offer a paid support service with "call back". We used this once to get the low down on something. They are very good with general support (better than many hosts IMO) but you can't expect dedicated service, and they must handle a lot of piddling questions. But pay for a call back and, in about 2 minutes on the phone, you can get the answer you want, plus they get their $10 (recurring) for the time. You both win. Just remember to cancel the recurring charges.
Regarding the second part of the question, we had this very same issue with them. Their response (as suggested by Linus in the comments) was that they keep a tally of the CPU use of all processes used by your "user". If that total exceeds a threshold, they will simply kill the process(es) to get the cycles down. No error messages, no warnings, no nothings. Processes can include MySQL, CGI (perl) or PHP. No way to monitor or predict, and we couldn't program round it. Solution... not DreamHost, unfortunately. (webhostingtalk.com will give you loads of host ideas). So we use for some sites, but not for others.