Codex

Interested in functions, hooks, classes, or methods? Check out the new WordPress Code Reference!

Difference between revisions of "High Traffic Tips For WordPress"

m (W3 Total Cache)
m (Hardware Limitations)
 
(30 intermediate revisions by 15 users not shown)
Line 1: Line 1:
  +
{{Languages|
Have you wondered whether WordPress can handle high-volume traffic? Think of creating a high-traffic site or generating volumes of writing? Think that something you write might get enough attention to get "slashdotted" or dugg by digg, or some other high-traffic-generating site. Wonder if WordPress can handle the sheer volume of traffic or fail. Can WordPress handle all these situations?
 
  +
{{en|High Traffic Tips For WordPress}}
 
  +
{{ja|WordPress_の最適化/高トラフィック_WordPress_サイト向けのヒント}}
The simple answer is "Yes," but this is a conditional yes. There is a lot you need to consider and understand before you decide on WordPress as your publishing platform, and if you expect high traffic volumes. Running WordPress on ''basic shared hosting'' will not be sufficient for truly high-traffic sites.
 
  +
}}
 
  +
__TOC__
Before [[Hosting_WordPress|selecting WordPress]] for your high-traffic site, you will need to check the following to ensure your site is ready for the anticipated traffic: The site server and it's software, upon which WordPress is dependent, needs to be sufficient for the traffic you anticipate and expect.
 
  +
Before [[Hosting_WordPress|using WordPress]] for a high-traffic site, you need to make sure the site is ready to deal with high traffic volumes. WordPress is certainly capable of managing large amounts of traffic, but there are limitations on what any website platform can do by itself. When you make changes to your web hosting/server, caching system, or file sizes, you must ensure your site will not crash after receiving only a few thousand hits.
   
 
See also [[WordPress Optimization]]
 
See also [[WordPress Optimization]]
Line 9: Line 10:
 
== Hardware Limitations ==
 
== Hardware Limitations ==
   
"Can WordPress handle my traffic?" is the wrong question. Virtually any blogging platform -- indeed, any web application -- is only able to handle as much traffic as can be supported by the [[Hosting_WordPress|hardware]] on which it runs.
+
Like any other web application, WordPress is only able to handle as much traffic as the [[Hosting_WordPress|hardware]] on which runs it can support.
   
Two physical barriers prevent your site from handling a high volume of hits:
+
There are two main barriers that can prevent your site from functioning under a high volume of traffic:
   
 
* [[#Processor Limitations|Processor Limitations]]
 
* [[#Processor Limitations|Processor Limitations]]
Line 17: Line 18:
   
 
=== Processor Limitations ===
 
=== Processor Limitations ===
 
High traffic levels can put a great demand on your server's internal resources. Ensure that your server has sufficient processor power and memory resources to meet these demands.
   
  +
The default requirements for WordPress are listed below. However, individual sites may require additional resources.
To serve high-traffic web sites, you will have to contend with the demand that high traffic puts on your server's internal resources. Be sure that the general demand on your server is met by sufficient processor power and memory resources.
 
   
 
==== MySQL/MariaDB ====
There can be more dependencies than what follows for publishing your WordPress site, however these are the ones that WordPress requires by default.
 
   
 
As with many blogging and web applications, WordPress depends on [[Glossary#MySQL|MySQL]] or [[Glossary#MariaDB|MariaDB]] to store data for producing output. Every request WordPress makes to MySQL/MariaDB, including both read and write operations, creates a load on the server.
==== MySQL ====
 
   
 
WordPress is continuously optimized to minimize the number of database requests needed for regular operation. However, developmental practices used in plugins or themes can increase the amount of database usage needed to run a given site. In high-traffic situations, many simultaneous database connections can cause excessive strain on the server. An incomplete connection to a server causes the "Connection timed out" response in the visitor's browser.
WordPress, as with many blogging and web applications, depends on [[Glossary#MySQL|MySQL]] to store data for producing output. Every request that WordPress makes to MySQL for reading or writing data creates load on the server.
 
   
 
MySQL/MariaDB connection rates can be improved by either adjusting MySQL/MariaDB settings, or providing more memory and processing power to the overworked server. Using query caching and proper indexing can also help to improve MySQL/MariaDB performance. There is no single solution for every case, as all sites operate differently.
WordPress itself is continuously optimized to reduce the transactions required to perform its functions; However, the development practices in the plugins or theme you use in your WordPress installation can also play a role in the amount of use of MySQL. In high-traffic situations, many simultaneous connections to the database can cause excessive load on the server. In this case, connections to the server may not complete, causing the typical "Connection timed out" response in the visitor's browser.
 
   
  +
Another option worth considering for high traffic sites is creating a read-only slave of your master database server. Since most requests made of the database by your WordPress site are SELECT (or read) requests, these can be separated from other UPDATE or INSERT requests by using a database management plugin such as HyperDB, written by the core WordPress team.
Often MySQL connection rates can be improved by either adjusting settings for MySQL, or providing more memory and processing power to the overworked server. Additionally, the use of query caching and proper use of indexes play a role in improving MySQL performance. All sites are different, so there is no single solution for every case.
 
   
 
==== Web Service ====
 
==== Web Service ====
   
WordPress is a web-server-neutral application, meaning that it can run on many different platforms. [[Glossary#Apache|Apache]] and [[Glossary#Linux|Linux]] are the most robust platforms for running WordPress, but any server that supports [[Glossary#PHP|PHP]] and [[Glossary#MySQL|MySQL]] will do.
+
WordPress is a web server neutral application, meaning that it can run on many different platforms. [[Glossary#Apache|Apache]] and [[Glossary#Linux|Linux]] are the most robust platforms for running WordPress, but any server that supports [[Glossary#PHP|PHP]] and MySQL or [[Glossary#MariaDB|MariaDB]] will do.
   
Make sure your host features the most up-to-date and stable version of these platforms to create a strong environment in which to run WordPress.
+
Make sure your host features the most up-to-date and stable version of these platforms in order to create a strong environment in which to run WordPress.
   
Choosing the best method to run [[Glossary#PHP|PHP]], the language that interprets the WordPress code, can also affect your server's performance. In CGI mode, the server creates a new instance of the PHP program for every PHP file that a visitor requests. In shared module mode (or ISAPI), a single library instance is used for each PHP request. There are also many misconceptions about the benefits of multi-threaded implementations of Apache 2, do your own testing before deploying. In general, prefork performance of Apache 2 with mod_php is the most stable. There are advantages and drawbacks to each method - while choosing the method for your server, be sure to keep in mind traffic and its demands on the server.
+
The method chosen to run PHP -- the language that interprets the WordPress code -- can also affect your server's performance. In CGI mode, the server creates a new instance of the PHP program for every PHP file that a visitor requests. In shared module mode (or ISAPI), each PHP request is handled by a single library instance.
  +
  +
There are also many misconceptions about the benefits of multi-threaded Apache 2 implementations. In general, pre-fork performance of Apache 2 with mod_php is the most stable. There are advantages and drawbacks to each method - when choosing the method for your server, be sure to keep in mind traffic and its demands on the server, and make sure to run your own tests before deploying.
   
 
===Network Limitations===
 
===Network Limitations===
   
  +
A slow Internet connection can limit the number of pages your server can serve in a given space of time.
Depending on the quality of your server's connection to the Internet, you may not be able to serve as many pages as you want to as fast as you want to serve them.
 
   
Your server's network provider (your [[Glossary#Hosting provider|host]] or [[Glossary#ISP|ISP]]) will usually connect your server to their internal network via an ethernet adapter. Adapters typically operate at certain standard maximum speeds, usually 10Mb/s, 100Mb/s, or 1Gb/s. Your server is '''physically incapable''' of transferring files of any kind in excess of this speed. There are additional barriers to your transfer rate that will likely reduce your server's speed even more.
+
Your server's network provider (your [[Glossary#Hosting provider|host]] or [[Glossary#ISP|ISP]]) will usually connect your server to their internal network via an Ethernet adapter. Adapters typically operate at certain standard maximum speeds, usually 10Mb/s, 100Mb/s, or 1Gb/s. Your server cannot transfer files faster than the speed at which this network connection transmits. In addition, there are many other factors that can
  +
affect the actual transfer rate seen by your server.
   
First, it is important to note that many of these numbers (especially the speed of your server's network adapter) are theoretical. In practice, your server will never transfer files at the maximum rate specified by the adapter, because in addition to the actual data being transferred, the server is also sending and receiving routing information of different kinds that the internet requires to get data to your site visitors. Because of this "network overhead", only a fraction of the full bandwidth is available for actually transferring files.
+
First, it is important to note that many of these numbers (especially the speed of your server's network adapter) are theoretical. In practice, your server will never transfer files at the maximum rate specified by the adapter. This is because, in addition to the actual data being transferred, the server is also sending and receiving the routing information needed to get data to your site visitors. Because of this "network overhead", '''only a fraction of the server's full bandwidth is available for actually transferring files.'''
   
Second, your server is likely connected to various devices in your network provider's facilities that will limit your transfer rates more than the limits on your server's network adapter. These devices are in place because your network provider has to fraction out its limited bandwidth to many servers at its location, and all of the bandwidth must be shared.
+
Second, your server is likely connected to various devices in your network provider's facilities. These devices can also place limitations on the "real world" speeds your server can attain. They are in place because your network provider has to fraction out its limited bandwidth to many servers at its location, and all of the bandwidth must be shared.
   
Certain network providers allow you to "burst" data -- temporarily exceed a pre-set transfer speed limit -- in special cases when demand for your site content is high. The network provider's hardware is specially designed to know when this is required. Some providers charge extra for this feature, some do not, and others do not offer this feature at all. It's up to you to find out.
+
Certain network providers allow you to "burst" data -- temporarily exceed a pre-set transfer speed limit -- in cases when demand for your site content is especially high. The network provider's hardware is designed to know when this is required. Some providers charge extra for this feature, some do not, and others do not offer this feature at all. Contact your service provider to find out whether this feature is available to you.
   
 
==== Network Transfer Speeds in Use ====
 
==== Network Transfer Speeds in Use ====
Line 56: Line 61:
 
Assume your site receives 100,000 hits in a day. For the purpose of this computation, we will say that one "hit" is a single data transfer, whether that is a single file or a whole page and its supporting files. Averaged out, 100,000 hits in a day equates to 1.16 hits every second.
 
Assume your site receives 100,000 hits in a day. For the purpose of this computation, we will say that one "hit" is a single data transfer, whether that is a single file or a whole page and its supporting files. Averaged out, 100,000 hits in a day equates to 1.16 hits every second.
   
Also assume the average hit generates 160KB of transferred data; HTML, images, CSS, downloaded files, etc. Every second, your site is transferring 190KB of data (<tt>160KB/hit * 1.16 hits/s</tt>). The total, 190KB/s, equals about 1.5Mb/s of sustained throughput. (Note that <tt>KB = Kilo<i>bytes</i></tt> and <tt>Mb = Mega<i>bits</i></tt>. Most network speeds are rated in <i>bits</i> per second, whereas file sizes are measured in <i>bytes</i>.) Many network providers cap the transfer rate of a site to about this level; some higher, some lower. However, only if each user visits in a nice succession will this steady rate be maintained.
+
Let's also assume the average hit generates 160KB of transferred data; HTML, images, CSS, downloaded files, etc. This means that your site is transferring 190KB of data every second (<tt>160KB/hit * 1.16 hits/s</tt>). The total, 190KB/s, equals about 1.5Mb/s of sustained throughput. (Note that <tt>KB = Kilo<i>bytes</i></tt> and <tt>Mb = Mega<i>bits</i></tt>. Most network speeds are rated in <i>bits</i> per second, whereas file sizes are measured in <i>bytes</i>.) Many network providers cap the transfer rate of a site to about this level; some higher, some lower. However, this steady rate will only be maintained if each individual user visits the site at regular intervals.
   
Usually, more than one user at a time will access your site. Sometimes during the day, nobody might access your site at all. If 10 people hit the site simultaneously per second, and that hit rate is sustained over a lengthy period -- not uncommon for a high-traffic site -- then you would need a 15Mb/s connection just to keep up with the simultaneous connections.
+
Usually, more than one user at a time will access your site. On the other hand, there may be periods where nobody accesses your site at all. If 10 people suddenly hit the site in one second, and that hit rate is sustained over a lengthy period -- not uncommon for a high-traffic site -- then you would need a 15Mb/s connection just to keep up with the simultaneous connections.
   
If your network adapters maximum theoretical speed is only 10Mb/s, your demand has already exceeded your capacity. WordPress had nothing to do with it.
+
If your network adapter's maximum theoretical speed is only 10Mb/s, demand has already exceeded capacity. In this instance, the network is the source of your traffic problems, rather than WordPress.
   
It is not necessary to receive 100,000 hits to cause this problem. Sustaining this rate of connectivity for a mere hour generates only 36,000 hits. If visitors concentrate their access to a certain time of day (or an automated comment spam script attempts to access your system multiple concurrent times while posting comments) then you could be left with many dropped requests.
+
It is not necessary to receive hundreds of thousands of hits to experience this problem. Sustaining this rate of connectivity for a mere hour generates only 36,000 hits. If your site visitors tend to favor a certain time of day (or an automated comment spam script attempts to access your system multiple concurrent times while posting comments) then you could be left with many dropped requests.
   
A 100Mb/s connection could handle up to 70 simultaneous connections at the same rate of download, but it is not likely that your network provider would offer the bandwidth that could fully use this speed without paying a premium. This is generally not something you can get with current shared hosting plans.
+
A 100Mb/s connection could handle up to 70 simultaneous connections at the same rate of download, but most network providers would not offer the bandwidth needed to fully use this speed on their shared hosting plans. You would likely need to pay a premium in order to get this kind of bandwidth from your connection.
   
 
==== Transfer Overages ====
 
==== Transfer Overages ====
   
If you are hosting large files such as videos, podcasts, or large photo archives is transfer overages. Hosting services often provide a fixed amount of overall transfer with their hosting plans. A plan may include only so many MB of transferred data. After your account has reached that amount, you will be charged for any extra data that is transferred. Depending on the host, this could be as much as $1/MB.
+
Hosting large files such as videos, podcasts, or large photo archives can leave you at risk of transfer overages. Hosting plans often stipulate a maximum amount of data that can be transferred in a given space of time. After your account has reached that amount, you will be charged for any extra data that is transferred. Depending on the host, this could be as much as $1/MB.
   
At that rate, a single download of a 20MB file after you've reached your limit could cost you $20 extra on your hosting bill!
+
At that rate, a single 20MB download could cost you $20 extra on your hosting bill!
   
Usually, the higher the transfer limit, the more costly your hosting plan will be. Some hosting services offer plans with no transfer limitations, which can be quite costly, but certainly ''less'' costly than paying for transfer overages on a high-traffic site.
+
Usually, the higher the transfer limit, the more costly your hosting plan will be. Some hosting services offer plans with no transfer limitations. These can be quite expensive, but certainly ''less'' expensive than paying for transfer overages on a high-traffic site.
   
A popular method to maximize the performance of your web site and avoid overages is to use a Content Delivery Network (CDN) with your site. There are may affordable pay-as-you go solutions that help you avoid expensive overages and the bandwidth limitations of some hosting providers. Learn more about CDNs and offloading [http://codex.wordpress.org/WordPress_Optimization/Offloading#Commercial_Services here].
+
A popular method of maximizing your site's performance while avoiding overages is to use a Content Delivery Network (CDN) with your site. There are many affordable pay-as-you-go solutions that help you to avoid the bandwidth limitations implemented by some hosting providers. Learn more about CDNs and offloading [http://codex.wordpress.org/WordPress_Optimization/Offloading#Commercial_Services here].
   
 
== Typical Requirements by Benchmark ==
 
== Typical Requirements by Benchmark ==
Line 87: Line 92:
 
== High Traffic Solutions ==
 
== High Traffic Solutions ==
   
Like [http://en.wikipedia.org/wiki/Kobe_beef Kobe beef], WordPress will only be at its best when raised in the proper conditions. Here are a few things to try if you find that your WordPress site is not performing as well as it could due to high traffic issues.
+
Like [http://en.wikipedia.org/wiki/Kobe_beef Kobe beef], WordPress is only at its best when raised in the proper conditions. Here are a few things to try if you find that high traffic is limiting your blog's performance.
  +
  +
===Service-Oriented Architecture===
  +
  +
If you are preparing for truly high traffic (or have already experienced it and are clamoring for some help), you should consider splitting your WordPress application into as many separate layers as possible, and serving those layers independently. Instead of a single host machine running your web server and MySQL/MariaDB, your site speed and resiliency would be helped by running in concurrent layers. Here is an example:
  +
* Apache2 / nginx web front-end server(s) - to handle actual page rendering and site administration.
  +
* MySQL/MariaDB database server - or master/slave, using a read-replica.
  +
* Varnish / nginx HTTP proxy layer - to handle initial requests from users.
  +
* CDN or image server - to serve media files that support your site.
  +
Not only will your site be able to take more load in this architecture, but you can then identify bottlenecks or stress-points that need to be addressed specifically. Perhaps your MySQL/MariaDB database is performing poorly, or Apache2 needs more CPU, and so forth. Under the right design, these layers can also be scaled out and in, or up and down, with your traffic.
   
 
=== W3 Total Cache ===
 
=== W3 Total Cache ===
   
[http://wordpress.org/extend/plugins/w3-total-cache/ W3 Total Cache] (W3TC) is the latest generation in WordPress performance plugins, which combines the research of [http://developer.yahoo.com/performance/rules.html web development authorities] to provide an optimal user experience for WordPress sites. W3TC is unique in its ability to optimize server side and client side performance, adding functionality otherwise not natively available:
+
[http://wordpress.org/extend/plugins/w3-total-cache/ W3 Total Cache] (W3TC) is the latest generation in WordPress performance plugins, combining the research of [http://developer.yahoo.com/performance/rules.html web development authorities] to provide an optimal user experience for WordPress sites. W3TC is unique in its ability to optimize server side and client side performance, adding functionality otherwise unavailable natively:
   
* Page Caching: Similar to the plugins that came before it, W3TC can create static HTML versions of pages, so that the web server can serve them without invoking PHP (which decreases response time). It automatically updates the cache when comments are made or pages are edited.
+
* Page Caching: W3TC helps to decrease response time by creating static HTML versions of pages, allowing web servers to serve them without invoking PHP. It automatically updates the cache when comments are made or pages are edited.
* Minify: Remove unnecessary characters from HTML, CSS and JavaScript files, then respectively combine them and apply HTTP compression on the cached files.
+
* Minification: Removes unnecessary characters from HTML, CSS and JavaScript files, then respectively combines them before applying HTTP compression on the cached files.
* Database Caching: Database queries (objects) are also cached, allowing many sites to reduce the time to generate new pages; often an issue when a site receives lots of comments each day.
+
* Database Caching: Database queries (objects) are also cached, allowing many sites to reduce the time needed to generate new pages. This is especially useful for sites that receive a lot of comments.
* Headers: W3TC manages the headers (entity tag, cache-control, expires) which control the caching of files in web browsers - reducing server load and improving user's perceived performance.
+
* Headers: W3TC manages the headers (entity tag, cache-control, expires) which control the caching of files in web browsers, reducing server load and improving the user's perceived performance.
* Content Delivery Network (CDN): Use a CDN to "[http://codex.wordpress.org/WordPress_Optimization/Offloading#Commercial_Services offload]" resources from your hosting account. W3TC moves the requests for images, CSS, JavaScript and other static files, to a network of high performance servers. Then, the server closest to the visitor is automatically used to download the files, providing the fastest downloads possible.
+
* Content Delivery Network (CDN): Using a CDN allows you to "[http://codex.wordpress.org/WordPress_Optimization/Offloading#Commercial_Services offload]" resources from your hosting account. W3TC moves the requests for images, CSS, JavaScript and other static files to a network of high performance servers. The server closest to the visitor is automatically used to download the files, providing the fastest downloads possible.
   
  +
W3TC can be used to optimize WordPress in both single- and multi-server environments through either shared or dedicated hosting.
For one or more servers, no matter if shared or dedicated hosting, W3TC provides the options to fully optimize WordPress. Upon activation it starts working with safe default settings.
 
   
 
=== WP Super Cache ===
 
=== WP Super Cache ===
   
[http://wordpress.org/extend/plugins/wp-super-cache/ WP Super Cache] is a (static) page caching plugin for WordPress. It generates html files that are served directly by Apache without processing comparatively heavy PHP scripts. By using this plugin you will speed up your WordPress blog significantly.
+
[http://wordpress.org/extend/plugins/wp-super-cache/ WP Super Cache] is a static page caching plugin for WordPress. It generates HTML files that are served directly by Apache without processing comparatively heavy PHP scripts, helping you to make significant speed gains on your WordPress blog.
   
This plugin is a fork of the excellent [http://wordpress.org/extend/plugins/wp-cache/ WP Cache] by Ricardo Galli Granada. WP Cache caches the pages of your WordPress blog and delivers them without accessing the database. Unfortunately it still requires loading the PHP engine to serve the cached files, so use of this plugin is no longer recommended.
+
WP Super Cache is a fork of [http://wordpress.org/extend/plugins/wp-cache/ WP Cache] by Ricardo Galli Granada. WP Cache also caches your WordPress blog pages and delivers them without accessing the database. However, its use is no longer recommended, as WP Cache still needs the PHP engine to be loaded in order to serve the cached files.
   
WP Super Cache gets around that. When it is installed, html files are generated and are served without ever invoking a single line of PHP. How fast can your site serve graphic files? That's how fast it will be able to serve these cached .html files. If your site is struggling to cope with the daily number of visitors, or if your site appears on [http://digg.com/ Digg.com], [http://slashdot.org/ Slashdot.org] or any other popular site then this plugin is for you.
+
However, WP Super Cache gets around this problem, allowing HTML files to be generated and served without ever invoking a single line of PHP. Using WP Super Cache allows your server to serve cached HTML pages at the same speed it serves regular graphic files. Consider WP Super Cache if your site is struggling to cope with its daily number of visitors, or if it appears on [http://digg.com/ Digg.com], [http://slashdot.org/ Slashdot.org] or any other popular site.
   
  +
=== Varnish Cache ===
=== Turn Off or Limit WordPress Plugins and Graphics ===
 
   
  +
[https://www.varnish-cache.org/ Varnish Cache] works in concert with W3 Total Cache to store pre-built pages in memory and serve them quickly without requiring execution of the Apache, PHP, WordPress stack.
When the traffic increases on your WordPress blog, all aspects of your blog's code and design elements also increase.
 
   
  +
While Varnish gives excellent performance, administrators should be aware that Varnish is "allergic" to cookies. If deployed with default settings, Varnish will not recognize or honor normal WordPress cookies for logged in users, etc. Therefore, the configuration file should be written so that the presence of WordPress cookies triggers Varnish to bypass the cache and send the request on to the web server directly. In effect this means that logged-in users (site admins, authors, contributors) will make requests directly to the web server, while public (anonymous) users will make their requests from the Varnish cache. A quick search of GitHub should provide a variety of VCL configuration files specifically written to work with WordPress, such as [https://github.com/dreamhost/varnish-vcl-collection DreamHost's WordPress VCL example].
For example, let's say the front page of your blog calls upon 8 graphics to create the "look" of your blog's design. Add to this number the various WordPress template files it takes to build your page. You've got the header, sidebar, footer, and post content area at a minimum. That's four more "calls" to files on your site. For 100 visitors, those files get loaded 1200 times. For 1000 visitors, those files are accessed and loaded 12000 times. This increases your bandwidth and server activity.
 
  +
  +
Please be aware that Varnish, like most other caching mechanisms, will serve up the same content from the cache until it expires. This means that administrators will need to either clear the cache when new content is added, or install a management plugin such as [https://wordpress.org/plugins/varnish-http-purge/ Varnish HTTP Purge], which resets the cache for any pages or posts that have been updated, and gives administrators a simple interface to clear the cache when theme or menu changes have been made.
  +
  +
=== Sirv ===
  +
  +
[https://wordpress.org/plugins/sirv/ Sirv] is an image performance plugin that accelerates image delivery. It uses a separate platform to process and deliver your images, following these best-practices: resizing according to device; image compression; optimal image format conversion; retina image creation; meta stripping; caching; and CDN delivery.
  +
  +
* Image Optimization: the [https://sirv.com/blog/optimal-image-format/ optimal image format] is served (including WebP if the browser supports it), which generate images that are 30%-80% smaller.
  +
* Personalized Per Visitor: each user receives images tailored to their browser and device. This optimizes the user experience and avoids serving overly large images.
  +
* CDN Delivery: optimized images are cached and served from a CDN, which usually relieves the server of 30-50% of its data transfer.
  +
* HTTP/2 Delivery: images are served using TLS 1.3 and the [https://developers.google.com/web/fundamentals/performance/http2/ HTTP/2 protocol], which batch serves up to 20 images in a single TCP/IP packet. This "multiplexing" technique overcomes the latency issue of HTTP/1.1.
  +
* Reduced Server Load: requests go directly to the Sirv network, which helps lower requests by 20-30% on the WordPress server.
  +
  +
The plugin works by synchronizing your WordPress media library to your Sirv account (free or paid). New images are automatically fetched from your WordPress library on demand.
  +
 
=== Turn Off or Limit WordPress Plugins and Graphics ===
   
  +
You may notice the effects of high traffic more if your blog has a high number of code and design elements.
WordPress Plugins are also files that are "called" by your WordPress Theme. In turn, these make queries to your database to generate the information on your blog. The more WordPress Plugins, the more queries to your database.
 
   
 
For example, let's say the front page of your blog calls upon 8 graphics to create the "look" of your blog's design. Add this number to the various WordPress template files it takes to build your page. At minimum, this includes the header, sidebar, footer, and post content area, creating four more "calls" to files on your site. For 100 visitors, those files get loaded 1200 times. For 1000 visitors, those files are loaded 12000 times, increasing both bandwidth and server activity.
Combine all these access files and database queries with an exponential increase in visitors, and you have a lot of demand on your site.
 
   
 
WordPress Plugins are also files that are "called" by your WordPress Theme. In turn, these plugins make queries to your database to generate the information on your blog. The more WordPress Plugins, the more queries to your database. Combine all these access files and database queries with an exponential increase in visitors, and you have a lot of demand on your site.
You can lower the number of files accessed during heavy traffic times by limiting the number of graphics on your blog by editing the stylesheet and template files of your WordPress Theme.
 
   
You can also lower the number of files accessed and the queries to your database by turning off a few WordPress Plugins temporarily.
+
You can lower the number of files accessed and the queries to your database during periods of heavy traffic by:
   
 
#Limiting the number of graphics on your blog. You can do this by editing the stylesheet and template files of your WordPress Theme.
Go through your list of WordPress Plugins to see if there are any listed that you really could live without for a day or two.
+
#Turning off a few WordPress Plugins temporarily. Go through your list of WordPress Plugins to see if there are any listed that you could live without for a day or two.
   
Keep the access to files and your database to a minimum as much as possible. After the heavy traffic volume has died down a bit, then you can reactivate and restore these features.
+
Keep access to files and your database to a minimum as much as possible. Reactivate and restore these features after the heavy traffic volume has died down.
   
 
=== New Hosting ===
 
=== New Hosting ===
Line 131: Line 162:
 
As painful as it may be to hear it, you might simply require a more powerful server.
 
As painful as it may be to hear it, you might simply require a more powerful server.
   
Here is a simple outline of upgrade steps for a site that is having high-traffic problems. If you are having trouble with:
+
Here is a simple outline of upgrade steps for a site that is having problems with high traffic. If you are having trouble with:
   
* Shared hosting, try upgrading to Virtual Dedicated Hosting.
+
* Shared hosting: try upgrading to Virtual Dedicated Hosting.
* Virtual Dedicated Hosting, try upgrading to Dedicated Hosting.
+
* Virtual Dedicated Hosting: try upgrading to Dedicated Hosting.
* Dedicated Hosting, try upgrading to a higher-powered dedicated server.
+
* Dedicated Hosting: try upgrading to a higher-powered dedicated server.
* High-Powered Dedicated Hosting, it is time to talk with your host about multiple Load Balanced Servers.
+
* High-Powered Dedicated Hosting: talk to your hosting provider about multiple Load Balanced Servers.
   
In all cases, your server is only as capable as your network provider. If your provider does not provide the bandwidth you require, you may need to negotiate an increase with them, or find a different provider that can provide you with the bandwidth that your traffic requires.
+
In all cases, your server is only as capable as your network provider. If your provider does not provide the bandwidth you require, you may need to negotiate an increase, or find a different provider that can provide you with the bandwidth that your traffic requires.
   
 
[[Category:Advanced Topics]]
 
[[Category:Advanced Topics]]

Latest revision as of 20:26, 6 May 2020

Before using WordPress for a high-traffic site, you need to make sure the site is ready to deal with high traffic volumes. WordPress is certainly capable of managing large amounts of traffic, but there are limitations on what any website platform can do by itself. When you make changes to your web hosting/server, caching system, or file sizes, you must ensure your site will not crash after receiving only a few thousand hits.

See also WordPress Optimization

Hardware Limitations

Like any other web application, WordPress is only able to handle as much traffic as the hardware on which runs it can support.

There are two main barriers that can prevent your site from functioning under a high volume of traffic:

Processor Limitations

High traffic levels can put a great demand on your server's internal resources. Ensure that your server has sufficient processor power and memory resources to meet these demands.

The default requirements for WordPress are listed below. However, individual sites may require additional resources.

MySQL/MariaDB

As with many blogging and web applications, WordPress depends on MySQL or MariaDB to store data for producing output. Every request WordPress makes to MySQL/MariaDB, including both read and write operations, creates a load on the server.

WordPress is continuously optimized to minimize the number of database requests needed for regular operation. However, developmental practices used in plugins or themes can increase the amount of database usage needed to run a given site. In high-traffic situations, many simultaneous database connections can cause excessive strain on the server. An incomplete connection to a server causes the "Connection timed out" response in the visitor's browser.

MySQL/MariaDB connection rates can be improved by either adjusting MySQL/MariaDB settings, or providing more memory and processing power to the overworked server. Using query caching and proper indexing can also help to improve MySQL/MariaDB performance. There is no single solution for every case, as all sites operate differently.

Another option worth considering for high traffic sites is creating a read-only slave of your master database server. Since most requests made of the database by your WordPress site are SELECT (or read) requests, these can be separated from other UPDATE or INSERT requests by using a database management plugin such as HyperDB, written by the core WordPress team.

Web Service

WordPress is a web server neutral application, meaning that it can run on many different platforms. Apache and Linux are the most robust platforms for running WordPress, but any server that supports PHP and MySQL or MariaDB will do.

Make sure your host features the most up-to-date and stable version of these platforms in order to create a strong environment in which to run WordPress.

The method chosen to run PHP -- the language that interprets the WordPress code -- can also affect your server's performance. In CGI mode, the server creates a new instance of the PHP program for every PHP file that a visitor requests. In shared module mode (or ISAPI), each PHP request is handled by a single library instance.

There are also many misconceptions about the benefits of multi-threaded Apache 2 implementations. In general, pre-fork performance of Apache 2 with mod_php is the most stable. There are advantages and drawbacks to each method - when choosing the method for your server, be sure to keep in mind traffic and its demands on the server, and make sure to run your own tests before deploying.

Network Limitations

A slow Internet connection can limit the number of pages your server can serve in a given space of time.

Your server's network provider (your host or ISP) will usually connect your server to their internal network via an Ethernet adapter. Adapters typically operate at certain standard maximum speeds, usually 10Mb/s, 100Mb/s, or 1Gb/s. Your server cannot transfer files faster than the speed at which this network connection transmits. In addition, there are many other factors that can affect the actual transfer rate seen by your server.

First, it is important to note that many of these numbers (especially the speed of your server's network adapter) are theoretical. In practice, your server will never transfer files at the maximum rate specified by the adapter. This is because, in addition to the actual data being transferred, the server is also sending and receiving the routing information needed to get data to your site visitors. Because of this "network overhead", only a fraction of the server's full bandwidth is available for actually transferring files.

Second, your server is likely connected to various devices in your network provider's facilities. These devices can also place limitations on the "real world" speeds your server can attain. They are in place because your network provider has to fraction out its limited bandwidth to many servers at its location, and all of the bandwidth must be shared.

Certain network providers allow you to "burst" data -- temporarily exceed a pre-set transfer speed limit -- in cases when demand for your site content is especially high. The network provider's hardware is designed to know when this is required. Some providers charge extra for this feature, some do not, and others do not offer this feature at all. Contact your service provider to find out whether this feature is available to you.

Network Transfer Speeds in Use

To determine why the bandwidth of the connection is important to a high-traffic site, let's look at the math.

Assume your site receives 100,000 hits in a day. For the purpose of this computation, we will say that one "hit" is a single data transfer, whether that is a single file or a whole page and its supporting files. Averaged out, 100,000 hits in a day equates to 1.16 hits every second.

Let's also assume the average hit generates 160KB of transferred data; HTML, images, CSS, downloaded files, etc. This means that your site is transferring 190KB of data every second (160KB/hit * 1.16 hits/s). The total, 190KB/s, equals about 1.5Mb/s of sustained throughput. (Note that KB = Kilobytes and Mb = Megabits. Most network speeds are rated in bits per second, whereas file sizes are measured in bytes.) Many network providers cap the transfer rate of a site to about this level; some higher, some lower. However, this steady rate will only be maintained if each individual user visits the site at regular intervals.

Usually, more than one user at a time will access your site. On the other hand, there may be periods where nobody accesses your site at all. If 10 people suddenly hit the site in one second, and that hit rate is sustained over a lengthy period -- not uncommon for a high-traffic site -- then you would need a 15Mb/s connection just to keep up with the simultaneous connections.

If your network adapter's maximum theoretical speed is only 10Mb/s, demand has already exceeded capacity. In this instance, the network is the source of your traffic problems, rather than WordPress.

It is not necessary to receive hundreds of thousands of hits to experience this problem. Sustaining this rate of connectivity for a mere hour generates only 36,000 hits. If your site visitors tend to favor a certain time of day (or an automated comment spam script attempts to access your system multiple concurrent times while posting comments) then you could be left with many dropped requests.

A 100Mb/s connection could handle up to 70 simultaneous connections at the same rate of download, but most network providers would not offer the bandwidth needed to fully use this speed on their shared hosting plans. You would likely need to pay a premium in order to get this kind of bandwidth from your connection.

Transfer Overages

Hosting large files such as videos, podcasts, or large photo archives can leave you at risk of transfer overages. Hosting plans often stipulate a maximum amount of data that can be transferred in a given space of time. After your account has reached that amount, you will be charged for any extra data that is transferred. Depending on the host, this could be as much as $1/MB.

At that rate, a single 20MB download could cost you $20 extra on your hosting bill!

Usually, the higher the transfer limit, the more costly your hosting plan will be. Some hosting services offer plans with no transfer limitations. These can be quite expensive, but certainly less expensive than paying for transfer overages on a high-traffic site.

A popular method of maximizing your site's performance while avoiding overages is to use a Content Delivery Network (CDN) with your site. There are many affordable pay-as-you-go solutions that help you to avoid the bandwidth limitations implemented by some hosting providers. Learn more about CDNs and offloading here.

Typical Requirements by Benchmark

This space is reserved for showing the capabilities of a typical server setup under stressful load conditions. Comparing the configuration of a particular hosting service to these benchmarks may help give you a better idea of the capabilities of the server you're considering.

Note that any server you choose will likely be at least slightly different than the benchmarks shown here.

Still working on obtaining benchmarks.

High Traffic Solutions

Like Kobe beef, WordPress is only at its best when raised in the proper conditions. Here are a few things to try if you find that high traffic is limiting your blog's performance.

Service-Oriented Architecture

If you are preparing for truly high traffic (or have already experienced it and are clamoring for some help), you should consider splitting your WordPress application into as many separate layers as possible, and serving those layers independently. Instead of a single host machine running your web server and MySQL/MariaDB, your site speed and resiliency would be helped by running in concurrent layers. Here is an example:

  • Apache2 / nginx web front-end server(s) - to handle actual page rendering and site administration.
  • MySQL/MariaDB database server - or master/slave, using a read-replica.
  • Varnish / nginx HTTP proxy layer - to handle initial requests from users.
  • CDN or image server - to serve media files that support your site.

Not only will your site be able to take more load in this architecture, but you can then identify bottlenecks or stress-points that need to be addressed specifically. Perhaps your MySQL/MariaDB database is performing poorly, or Apache2 needs more CPU, and so forth. Under the right design, these layers can also be scaled out and in, or up and down, with your traffic.

W3 Total Cache

W3 Total Cache (W3TC) is the latest generation in WordPress performance plugins, combining the research of web development authorities to provide an optimal user experience for WordPress sites. W3TC is unique in its ability to optimize server side and client side performance, adding functionality otherwise unavailable natively:

  • Page Caching: W3TC helps to decrease response time by creating static HTML versions of pages, allowing web servers to serve them without invoking PHP. It automatically updates the cache when comments are made or pages are edited.
  • Minification: Removes unnecessary characters from HTML, CSS and JavaScript files, then respectively combines them before applying HTTP compression on the cached files.
  • Database Caching: Database queries (objects) are also cached, allowing many sites to reduce the time needed to generate new pages. This is especially useful for sites that receive a lot of comments.
  • Headers: W3TC manages the headers (entity tag, cache-control, expires) which control the caching of files in web browsers, reducing server load and improving the user's perceived performance.
  • Content Delivery Network (CDN): Using a CDN allows you to "offload" resources from your hosting account. W3TC moves the requests for images, CSS, JavaScript and other static files to a network of high performance servers. The server closest to the visitor is automatically used to download the files, providing the fastest downloads possible.

W3TC can be used to optimize WordPress in both single- and multi-server environments through either shared or dedicated hosting.

WP Super Cache

WP Super Cache is a static page caching plugin for WordPress. It generates HTML files that are served directly by Apache without processing comparatively heavy PHP scripts, helping you to make significant speed gains on your WordPress blog.

WP Super Cache is a fork of WP Cache by Ricardo Galli Granada. WP Cache also caches your WordPress blog pages and delivers them without accessing the database. However, its use is no longer recommended, as WP Cache still needs the PHP engine to be loaded in order to serve the cached files.

However, WP Super Cache gets around this problem, allowing HTML files to be generated and served without ever invoking a single line of PHP. Using WP Super Cache allows your server to serve cached HTML pages at the same speed it serves regular graphic files. Consider WP Super Cache if your site is struggling to cope with its daily number of visitors, or if it appears on Digg.com, Slashdot.org or any other popular site.

Varnish Cache

Varnish Cache works in concert with W3 Total Cache to store pre-built pages in memory and serve them quickly without requiring execution of the Apache, PHP, WordPress stack.

While Varnish gives excellent performance, administrators should be aware that Varnish is "allergic" to cookies. If deployed with default settings, Varnish will not recognize or honor normal WordPress cookies for logged in users, etc. Therefore, the configuration file should be written so that the presence of WordPress cookies triggers Varnish to bypass the cache and send the request on to the web server directly. In effect this means that logged-in users (site admins, authors, contributors) will make requests directly to the web server, while public (anonymous) users will make their requests from the Varnish cache. A quick search of GitHub should provide a variety of VCL configuration files specifically written to work with WordPress, such as DreamHost's WordPress VCL example.

Please be aware that Varnish, like most other caching mechanisms, will serve up the same content from the cache until it expires. This means that administrators will need to either clear the cache when new content is added, or install a management plugin such as Varnish HTTP Purge, which resets the cache for any pages or posts that have been updated, and gives administrators a simple interface to clear the cache when theme or menu changes have been made.

Sirv

Sirv is an image performance plugin that accelerates image delivery. It uses a separate platform to process and deliver your images, following these best-practices: resizing according to device; image compression; optimal image format conversion; retina image creation; meta stripping; caching; and CDN delivery.

  • Image Optimization: the optimal image format is served (including WebP if the browser supports it), which generate images that are 30%-80% smaller.
  • Personalized Per Visitor: each user receives images tailored to their browser and device. This optimizes the user experience and avoids serving overly large images.
  • CDN Delivery: optimized images are cached and served from a CDN, which usually relieves the server of 30-50% of its data transfer.
  • HTTP/2 Delivery: images are served using TLS 1.3 and the HTTP/2 protocol, which batch serves up to 20 images in a single TCP/IP packet. This "multiplexing" technique overcomes the latency issue of HTTP/1.1.
  • Reduced Server Load: requests go directly to the Sirv network, which helps lower requests by 20-30% on the WordPress server.

The plugin works by synchronizing your WordPress media library to your Sirv account (free or paid). New images are automatically fetched from your WordPress library on demand.

Turn Off or Limit WordPress Plugins and Graphics

You may notice the effects of high traffic more if your blog has a high number of code and design elements.

For example, let's say the front page of your blog calls upon 8 graphics to create the "look" of your blog's design. Add this number to the various WordPress template files it takes to build your page. At minimum, this includes the header, sidebar, footer, and post content area, creating four more "calls" to files on your site. For 100 visitors, those files get loaded 1200 times. For 1000 visitors, those files are loaded 12000 times, increasing both bandwidth and server activity.

WordPress Plugins are also files that are "called" by your WordPress Theme. In turn, these plugins make queries to your database to generate the information on your blog. The more WordPress Plugins, the more queries to your database. Combine all these access files and database queries with an exponential increase in visitors, and you have a lot of demand on your site.

You can lower the number of files accessed and the queries to your database during periods of heavy traffic by:

  1. Limiting the number of graphics on your blog. You can do this by editing the stylesheet and template files of your WordPress Theme.
  2. Turning off a few WordPress Plugins temporarily. Go through your list of WordPress Plugins to see if there are any listed that you could live without for a day or two.

Keep access to files and your database to a minimum as much as possible. Reactivate and restore these features after the heavy traffic volume has died down.

New Hosting

As painful as it may be to hear it, you might simply require a more powerful server.

Here is a simple outline of upgrade steps for a site that is having problems with high traffic. If you are having trouble with:

  • Shared hosting: try upgrading to Virtual Dedicated Hosting.
  • Virtual Dedicated Hosting: try upgrading to Dedicated Hosting.
  • Dedicated Hosting: try upgrading to a higher-powered dedicated server.
  • High-Powered Dedicated Hosting: talk to your hosting provider about multiple Load Balanced Servers.

In all cases, your server is only as capable as your network provider. If your provider does not provide the bandwidth you require, you may need to negotiate an increase, or find a different provider that can provide you with the bandwidth that your traffic requires.

This article is marked as in need of editing. You can help Codex by editing it.