One place for hosting & domains


      How to Fix Fatal Error: Maximum Execution Time Exceeded in WordPress (6 Methods)

      Updating your plugins and themes regularly is necessary to keep your site running at full capacity. However, the fatal WordPress error “maximum execution time exceeded” can prevent updates and leave you feeling concerned about your website’s performance.

      Fortunately, you can use a few methods to remove the error or increase the maximum execution time: You can uninstall the problem software, use a plugin, or edit your site’s code directly to solve the issue in no time.

      In this article, we’ll look at what the WordPress maximum execution time error is and why it happens. Then we’ll walk you through six methods you can use to solve the problem and keep your site running smoothly:

      1. Uninstall problem software
      2. Use a plugin
      3. Adjust the wp-config.php file
      4. Update the php.ini file
      5. Edit the .htaccess file
      6. Contact your hosting provider

      Let’s get started!

      What the WordPress Max Execution Time Error Is (And Why It Happens)

      The maximum execution time error is one of the most common WordPress errors. It can appear when you are trying to update your WordPress plugins or themes.

      The maximum execution time exceeded error in WordPress.

      It alerts you that your site was unable to perform the updates you requested.

      This error happens because of the PHP scripts on your website. PHP is a scripting language that is the foundation of WordPress sites. It is made up of code that controls how the website functions and shows different elements to users. As such, the maximum execution error directly relates to how long a PHP script takes to run.

      PHP scripts have a maximum execution time to keep your site functional and secure. For example, if there were no limit, a hacker or malicious software could use neverending scripts to dismantle your website’s server and make your data vulnerable. Furthermore, PHP scripts running for a long time can divert resources from your server.

      Plugins are more likely to trigger the error because they come with a lot of code from external sources. WordPress is an open-source platform, so any developer can design and upload plugins for it. If you install content from lesser-known developers, it may come with flawed code and cause issues in your site’s PHP scripts.

      Themes and general WordPress updates can also cause the problem. However, this is less common.

      What the Standard Max Execution Time Is

      At DreamHost, we set the maximum execution time on our end. As with most other hosting providers, it usually has a duration of 30 seconds. This is typically enough time for most PHP scripts to run successfully. If you’re using a different hosting provider, you should be able to contact them directly to find out what your site’s maximum execution time is.

      However, large websites with multiple resources may need slightly longer maximum execution times. Otherwise, they may not be able to complete their processes before the clock runs out.

      Additionally, some developers may use very long execution times of more than 300 seconds. However, we don’t recommend this for most websites because of the security issues that we discussed previously.

      How to Figure Out if the Error Has Occurred

      It is usually obvious that the maximum execution time error has happened because you will see a notification in your WordPress dashboard.

      But it may not always have the same wording. For example, it may read as “fatal error” or ‘critical error.” The notification also might not reference the maximum execution time. However, all of the warnings share similar components that can alert you to the source of the problem.

      Front-end users may also be able to see the error. If they visit the site when the update process has failed, they might see a message telling them that your website is experiencing technical difficulties.

      Wikipedia experiencing technical difficulties.

      However, this error message doesn’t only appear because your maximum execution time has been exceeded. As such, you’ll want to check and see if it shows up in your WordPress dashboard as well.

      Finally, you may receive an email from WordPress alerting you that the maximum execution time has been exceeded. This happens because of the WordPress 5.2 update, which introduced PHP error protection that automatically notifies you when your site has problems with its themes or plugins. As such, you will almost immediately know that there is an issue with your updates.

      Skip the Stress

      Avoid troubleshooting when you sign up for DreamPress. Our friendly WordPress experts are available 24/7 to help solve website problems — big or small.

      How to Fix the Max Execution Time WordPress Error (6 Methods)

      There are a few different methods you can use to eliminate the max execution time error or increase your site’s maximum execution time.

      You may first want to consider your comfort level with directly editing your site’s files and adding new code. If this method sounds beyond your technical abilities, there are fortunately other options available.

      1. Uninstall the Problem Software

      One of the simplest ways to fix the maximum execution time error is to uninstall the software causing the issue. One of your plugins or your site’s theme is likely the culprit, so you can start there.

      We recommend using this method if you have a hunch that a specific application is causing the problem. For example, you may have recently added a new plugin or updated an old one.

      If the error locks you out of your site, you can access the dashboard via Recovery Mode. If you received an email from WordPress about the failed updates, it usually includes a link to Recovery Mode and may even tell you which plugin caused the problem.

      Then, navigate to Plugins > Installed Plugins and click on Deactivate underneath the relevant item. Click on Delete to remove it.

      If you don’t know what is causing the maximum execution time exceeded error, you can deactivate all of your plugins and reactivate them one by one. Refresh each time and see if you can find the one that triggered the problem.

      You can use Secure File Transfer Protocol (SFTP) to remove the plugin. Alternatively, if you have a fully hosted DreamHost account, you can do it with your control panel file manager.

      Navigate to Websites > Manage Websites, and hover over the preview above your domain name. Then click on Manage.

      How to manage websites on DreamHost.

      Scroll down and select Manage Files.

      How to reach the file manager on DreamHost.

      Then navigate to your website’s directory folder. Enter the Plugins folder, right-click on the plugin you want to remove, and select Delete.

      Deleting a plugin using the DreamHost file manager.

      Hopefully, this will resolve the error. If not, you can move on to the following methods.

      2. Use the WP Maximum Execution Time Exceeded Plugin

      One of the easiest ways to increase the maximum execution time is by using the WP Maximum Execution Time Exceeded plugin.

      The WP Maximum Execution Time Exceeded plugin home page.

      This tool enables you to increase the maximum execution time to 300 seconds (five minutes) while you have it activated.

      You may prefer to use this instead of the previous method because it can increase your maximum execution time globally. This can be beneficial if you want to give functional plugins and themes a little more time to complete their updates.

      To use the plugin, you can download the .zip file and head to your WordPress dashboard. Navigate to Plugins > Add New and click on Upload File > Choose File.

      Adding a new plugin on the WordPress dashboard.

      Click on Install Now. Once the plugin is installed, select Activate Plugin to complete the process.

      The plugin automatically increases your site’s maximum execution time right away, so you don’t need to do anything else. If you ever want to remove it and revert to the original settings, you can head to Plugins > Installed Plugins and click on Deactivate.

      How to deactivate the WP Maximum Execution Time Exceeded plugin.

      This is a straightforward fix for the maximum execution time exceeded error. However, it does not enable you to choose a custom duration. If that’s something you’re looking for, you may prefer to use one of the following more intensive methods.

      3. Increase the Maximum Execution Time via wp-config.php

      You can increase the maximum execution time in your site’s wp.config.php file. This is a core file that contains a lot of important information about your site. For example, it has your website’s name, host name, login username, and password.

      We recommend this method if you want to customize your maximum execution time. It enables you to add code directly into your WordPress directory file. Furthermore, it’s relatively quick and easy to do.

      Before you start editing the file, we recommend backing up your entire WordPress site. The wp-config.php file is essential for your website, so you don’t want to make a critical and irreversible mistake. With a backup on file, you can revert to your original settings with minimal effort.

      You can find the file by using the DreamPress file manager or your SFTP application and looking for wp-config.php. Right-click on it and select Edit.

      How to edit the wp-config.php file in the DreamHost file manager.

      Alternatively, you can click on Download and edit the file with a simple text editor like Notepad. Once you’re in the wp-config.php file, scroll to the bottom and insert the following code:


      “X” represents the maximum execution time in seconds. For example, you can replace it with “300”, and it will extend the duration to five minutes.

      Now you can save the file, and you’ve successfully changed the maximum execution time!

      4. Increase the Maximum Execution Time in php.ini

      You can also increase the maximum execution time by creating a new php.ini file. This is a document that controls your PHP settings, such as resource limits, upload sizes, and file timeouts.

      This method can be an excellent option if you use a Content Management System (CMS) like WordPress. php.ini affects all the scripts in your system, so you won’t have to edit each one individually.

      Not all servers support php.ini files, so you’ll need to check first to make sure yours does. Then you can increase the PHP execution time with this method.

      In the DreamHost server, php.ini files are called phprc. First, you’ll need to create a new phprc file. Go to your SFTP dashboard and navigate to your user directory.

      Locate the phprc file in your site’s version of PHP. Then right-click on it and select View/Edit to add your new code. You may see this warning.

      A warning message in FileZilla.

      Click on the check box next to Always use selection for all unassociated files and select OK. This will open the file with your text editor. Next, you can enter the following code to change the maximum execution time:

      max_execution_time = 500

      This will change the max execution time to 500 seconds. Then you need to kill the existing PHP processes to update the phprc file and make the changes take effect.

      5. Increase the Maximum Execution Time in .htaccess

      The .htaccess file is another place where you can adjust the maximum execution time. This file controls changes across the different directories of your WordPress site. However, not all servers use it, and it is most commonly found in Apache servers.

      You may prefer to use this method if you don’t want to play around with the wp-config.php file and if your server doesn’t support php.ini files.

      Before starting, we recommend backing up your .htaccess file. By doing so, you can reinstate it if you make any major mistakes. Simply make a copy of it and save it elsewhere on your computer.

      Then use your chosen SFTP to edit the original .htaccess file. If you’re using the DreamHost file manager, you can right-click on it and select Edit.

      How to edit the .htaccess file with DreamHost.

      Otherwise, you can open it with your text editor. Then enter this code to change the maximum execution time:

      php_value max_execution_time 300

      You can substitute the “300” for any other amount you prefer. Finally, save the changes, and the file will apply them to your site.

      6. Contact Your Hosting Provider to Request an Increase in Maximum Execution Time

      If you would prefer not to change your site’s files yourself, you have another option. You can contact your hosting provider directly, and they can increase the maximum execution time on your behalf.

      This method could be an excellent option if you’re short on time or have limited technical skills. However, it may cost extra depending on your hosting provider.

      With a DreamHost account, you can contact our Professional Services team to make these changes for you. Navigate to the Contact Support page in your account dashboard and submit a ticket.

      How to contact the DreamHost support team.

      There, you can outline your desired changes and add any details about your site. Our team may ask for more details, and then we’ll get to work on making the changes!

      Bonus WordPress Error Articles

      Need to resolve other technical issues on your website? We’ve got you covered! Our team has put together several guides to help you troubleshoot the most common WordPress errors:

      And if you’d like a soup-to-nuts walkthrough on running a successful WordPress site, be sure to check out our WordPress Tutorials. It’s a collection of 42 guides written by our WordPress experts that’ll help you navigate the WordPress dashboard like a pro.

      Take Your WordPress Website to the Next Level

      Whether you need help navigating the WordPress dashboard, fixing incorrect database credentials, or choosing a web host, we can help! Subscribe to our monthly digest so you never miss an article.

      Fixing the Fatal Error: Maximum Execution Time Exceeded

      The maximum execution time exceeded error in WordPress can get in the way of updating your plugins and themes. Although it can be frustrating when it happens, there are several ways to solve the problem quickly.

      You can fix the maximum execution time WordPress error with the following strategies:

      1. Uninstall the problem item.
      2. Increase the maximum execution time with a plugin like WP Maximum Execution Time Exceeded.
      3. Adjust the maximum execution time by editing the wp-config.php file.
      4. Increase the maximum execution time in the php.ini file.
      5. Edit the .htaccess file to increase the maximum execution time.
      6. Contact your hosting provider to change the file on your behalf.

      Are you looking for a hosting provider that can take care of all your site’s technical issues? Check out our DreamPress packages and leave the troubleshooting to the experts!

      Image credit: Wikimedia Commons.

      Source link

      How to Implement Microsoft SQL Servers in a Private Cloud for Maximum Performance

      There are many considerations to take into account when implementing a Microsoft SQL Server in a private cloud environment. Today’s SQL dependent applications have different performance and high availability (HA) requirements. As a solutions architect, my goal is to provide our customers the best performing, highly available designs while managing budgetary concerns, scalability, supportability and total cost of ownership. Like so many tasks in IT infrastructure strategy, success is all about planning. There are many moving pieces and balancing everything to reach our goal becomes a challenge if we don’t ask the right questions up front.

      In this two-part series, I’ll share my approach to scoping, sizing and designing private cloud infrastructure capable of migrating or standing up new Microsoft SQL Server environments. In part one, I’ll identify performance considerations and provide real world examples to make sure that your SQL Server environment is ready to meet application, growth and DR requirements of your organization. In part two, I’ll focus on SQL Server deployment options with high availability.

      If you need a review on SQL server basics before we dive into the private cloud design, you can brush up here.

      Here’s what we’ll cover in this post, with links if you’d prefer to jump ahead:

      SQL Server Performance Considerations: RAM, IOPS, CPU and More

      What follows are the basic performance considerations to take into account when designing a Microsoft SQL Server environment.

      RAM—These requirements are based on database size and developer recommendations. Ideally, you’ll have enough RAM to put the entire database into RAM. However, that’s not always possible with large DB sizes. RAM is delicious to SQL and the server will eat it up, so be generous if your budget allows. Leave 20 percent of RAM reserved on the server for OS and other services.

      IOPS—The SQL Server is mostly a read/write machine, and its performance is dependent on disk IO and storage latency. With SSDs becoming more affordable, many SQL DBAs now prefer to run on SSDs due to high IOPS provided by SSD and NVMe drives. In the past, many 15K SAS disks in RAID10 were the norm for data volumes.

      Low latency is essential to SQL performance. By today’s standards, keeping latency below 5ms per IO is the norm. Sub 1ms latency is very common with local SSD storage. However, 10ms is still a good response time for most medium performance applications.

      CPU—Bare metal CPU allocation is easy. Your server has a number of CPUs and all of them can be allocated to SQL with no negative considerations, other than licensing costs. However, allocating CPU to a SQL Server in a VMWare private cloud environment should be done with caution. Licensing is based on CPU cores. Too much assigned, but unused, vCPU GHz in a VMWare VM can negatively impact performance. Rightsizing is key.

      The SQL Server is not normally a CPU hog. Unexpected and prolonged high CPU usage during production time means something is not right with the database or SQL code. Adding CPU in those cases may not solve the issue. These unexpected conditions should be checked by SQL DBAs and developers. Higher than normal CPU utilization is to be expected during maintenance time. In instances where a database may require high CPU utilization as a norm, a developer or SQL DBA should check the database for missing indexes or other issues before adding more vCPUs to virtual servers.

      SQL as a VM

      Based on the above considerations, when designing a SQL Server environment, budgetary and licensing considerations may start leaning your design toward SQL as a VM on a private cloud with a restricted number of assigned vCPUs. Running SQL on a private cloud is a great way to save on licensing costs. It’s also a good performer for most application loads, and because SQL is more of an IO-dependent system, its performance will greatly depend on the latency and IO availability of your storage system.

      Storage Systems IO Availability

      SAN storage will normally provide great amounts of IO based on the amount of disks and disk types on the SAN. The norm to expect from many SAN systems is 5ms to 15ms of latency per IO. When your application desires sub 1ms latency, such as gaming, financial or ad-tech systems, a local SSD RAID10 disk array will save the day. These local disk arrays are easy to set up and use with both VMs and bare metal server implementations. You may ask, “What about the HA and extra redundancy features of using a SAN instead of local disk?” I will be discussing High Availability in a performance-demanding environment in Part 2: Deploying Microsoft SQL Servers in a Private Cloud with High Availability. Check back soon.

      In the end, your application’s performance requirements and budget will drive your decision whether to run a private cloud or a bare metal SQL deployment. Both VM and bare metal deployments can be configured with high availability and will easily integrate into your private cloud environments.

      With these performance considerations in mind, let’s discuss other scoping and sizing matrices that we’ll need to design our high-performing and future-proofed SQL deployment.

      Scoping and Sizing for Microsoft SQL Deployments in a Private Cloud

      As a Solution Engineer at INAP, I collect numerous measurements during the SQL scoping process. Before delving into numbers, I start by evaluating pain points clients may have with their current SQL Servers. I want to know what hurts.

      Asking these and other questions helps me understand how to resolve issues and future proof your next SQL deployment:

      • Is it performing to your expectation?
      • Are you meeting your SQL database maintenance time window?
      • Do your users complain that their SQL dependent application freezes sometimes for no reason?
      • When was the last time you restored a database from your backup and how long did that take?
      • What’s your failover plan in case your production database server dies?
      • What backup software is being used for SQL?
      • Are your databases running in simple or full restore mode?

      Once I know the exact problem, or if I’m designing for a new application, I start by collecting specific technical details. The most common specific measurements and requirements collected during the scoping phase are:

      • DB sizes for all databases per SQL instance
      • Instances (Is there more than one SQL instance, and why?)
      • Growth requirements (Usually measured in daily change rate to help with other considerations like backups and replication for DR purposes)
      • RAM requirements & CPU requirements
      • Performance requirements, such as latency/ IO and IOPS requirements
      • HA requirements (Can your customer base wait for you to restore your SQL Server in case of an outage? How long does it take to restore?)
      • Regulatory/Compliance requirements such as HIPAA and PCI
      • Maintenance schedule (Do the maintenance jobs complete on time every day)
      • Replication requirements
      • Reporting requirements (Does this deployment need a reporting server so as to not interrupt production workloads)
      • Backup (What is used today to backup production data? Has it been tested? What are the challenges?)

      In environments requiring high performance database response times, we utilize native Windows Server tools, such as perfmon, to collect very detailed performance matrixes from exiting SQL Servers to identify performance bottlenecks and other considerations that help us resolve these issues in current or future database deployments. Because a good SQL Server’s performance is heavily dependent on the disk sub-systems, we will go deeper in disk design recommendations for private clouds, VMs and bare metal deployments.


      SQL Server Disk Layout for Performance, HA and DR

      Separating database files into different disks is a best practice. It helps performance and helps your DBA easily identify performance issues when troubleshooting. For example, you could have a runaway query beating up your TempDB. If your TempDB is on a separate disk from your prod database files, you can easily identify that the TempDB disk is being thrashed and that same TempDB issue is not stepping on other workloads in your environments.

      For high performance requirements, SSDs are recommended. The following is a basic disk layout for performance:

      • Data (MDF, NDF files): Fast read/write disk, many drives in an array preferred for best performance
      • Index (NDF files, not often used): Fast read/write disk, many drives in an array preferred for best performance
      • Log (LDF files): Fast write performance, not much reading happens here
      • TempDB (Temp database to crunch numbers and formulas): Should be a fast disk. SSD is preferred. Do not combine with other data or log files.
      • Page File (NTFS): Keep this on a separate disk LUN or Array if possible. C: drive is not a good place for a page file on a SQL Server.

      In a SQL deployment that requires DR, the above disk layout will allow you to granularly replicate just the SQL data and the OS that needs to be replicated, leaving TempDB and pagefile out of the replication design since those files are reset during reboot. TempDB and pagefile also produce lots of noisy IO. Replicating those files will result in unnecessarily heavy bandwidth and disk utilization.

      Check back soon for Part 2: Deploying Microsoft SQL Servers in a Private Cloud with High Availability

      Rob Lerner


      Source link