Hi mailinglist
**
*I am having troubles with the time to first byte (TTFB) on a newly deployed Mediawiki in a Docker image.*
*
With a freshly booted Image (w/o extensions), the initial TTFB is very high. (Browser: ~5s , Google Page Speed: ~3s). When i refresh the Page in the Browser or in the Page Speed test, the page is delivered quite fast. After not doing anything for about 30 mins, it is very slow again. I disabled all caching mechanisms and could still reproduce this behavior, so i looked in the DB, if there are still some caching actions. It seems, things stored in the table objectcache have a TTL, so i am trying out some combinations of file cache with prefilled page caches and php APCu.
I am using the official Docker Image based on MW 1.32 (apache with mod php 7.2) and i modified it to use a couple of extensions. It runs in a kubernetes environment on the Google Cloud Platform and the DB Backend is a Google Cloud SQL instance with MySQL 5.7. A Google Cloud Storage Bucket is fuse mounted to store uploads permanently. In order to scale horizontally there is a Pod with a redis service to provide all sessions infos to all instances of MW. The plan is to run also a Varnish Caching proxy in front of the LoadBalancer.
*My question is, what are the best practices to solve this issue?*
**
*Best regards,*
*Philipp *
*
Generally speaking: Make sure you have objectcache setup properly (e.g. if using APCu, set $wgMainCacheType = CACHE_ACCEL, if using redis it would be something else. Check the size of the cache, to make sure its something appropriate. If using apcu that is the apcu.shm_size config variable. If you are using more than one MW instance, then you shouldn't use apc, you should use redis or memcached instead [In that case, apcu will still be used for some keys if its available, if the key is very hot and doesn't need to worry about being cleared, so you should still have apcu installed] ).
Setting $wgCacheDirectory to somewhere writable by the webserver (But not in the web directory) can also improve things.
MediaWiki supports many different types of caching, and they have different effects. For example, varnish caching will significantly improve performance for logged out users, but do very little for logged in users (Might improve speed of JS/images)
Beyond the generals, its best to collect data before making optimization decisions. If you could include profiling data ( https://www.mediawiki.org/wiki/Manual:Profiling ) it'd be easier to give specific advice as then we would be able to see what part is behaving slowly. It would also be good to include details about all the types of caches you have setup, and what the value of all the cache related variables in LocalSettings.php are.
-- Brian
On Tue, Feb 19, 2019 at 1:43 PM Philipp Mohr ppm@heavy-internet.com wrote:
Hi mailinglist
**
*I am having troubles with the time to first byte (TTFB) on a newly deployed Mediawiki in a Docker image.*
With a freshly booted Image (w/o extensions), the initial TTFB is very high. (Browser: ~5s , Google Page Speed: ~3s). When i refresh the Page in the Browser or in the Page Speed test, the page is delivered quite fast. After not doing anything for about 30 mins, it is very slow again. I disabled all caching mechanisms and could still reproduce this behavior, so i looked in the DB, if there are still some caching actions. It seems, things stored in the table objectcache have a TTL, so i am trying out some combinations of file cache with prefilled page caches and php APCu.
I am using the official Docker Image based on MW 1.32 (apache with mod php 7.2) and i modified it to use a couple of extensions. It runs in a kubernetes environment on the Google Cloud Platform and the DB Backend is a Google Cloud SQL instance with MySQL 5.7. A Google Cloud Storage Bucket is fuse mounted to store uploads permanently. In order to scale horizontally there is a Pod with a redis service to provide all sessions infos to all instances of MW. The plan is to run also a Varnish Caching proxy in front of the LoadBalancer.
*My question is, what are the best practices to solve this issue?*
**
*Best regards,*
*Philipp *
MediaWiki-l mailing list To unsubscribe, go to: https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
Hi Brian,
thank you for your input :)
I used APCu for testing purposes. For the live version i use memcached. It seems that the combination of different caches gets the best performance: objectcache like memcache and file cache with prerendered html pages.
Thanks for the tip with profiling data. I'll take a look at it.
It also turned out, that i have some problems with extensions like VisualEditor and MobileDetection with MobileFrontend. These three extensions are slowing down my performance. But this is a different problem.
Best regards
Philipp
Am 19.02.19 um 15:48 schrieb Brian Wolff:
Generally speaking: Make sure you have objectcache setup properly (e.g. if using APCu, set $wgMainCacheType = CACHE_ACCEL, if using redis it would be something else. Check the size of the cache, to make sure its something appropriate. If using apcu that is the apcu.shm_size config variable. If you are using more than one MW instance, then you shouldn't use apc, you should use redis or memcached instead [In that case, apcu will still be used for some keys if its available, if the key is very hot and doesn't need to worry about being cleared, so you should still have apcu installed] ).
Setting $wgCacheDirectory to somewhere writable by the webserver (But not in the web directory) can also improve things.
MediaWiki supports many different types of caching, and they have different effects. For example, varnish caching will significantly improve performance for logged out users, but do very little for logged in users (Might improve speed of JS/images)
Beyond the generals, its best to collect data before making optimization decisions. If you could include profiling data ( https://www.mediawiki.org/wiki/Manual:Profiling ) it'd be easier to give specific advice as then we would be able to see what part is behaving slowly. It would also be good to include details about all the types of caches you have setup, and what the value of all the cache related variables in LocalSettings.php are.
-- Brian
On Tue, Feb 19, 2019 at 1:43 PM Philipp Mohr ppm@heavy-internet.com wrote:
Hi mailinglist
**
*I am having troubles with the time to first byte (TTFB) on a newly deployed Mediawiki in a Docker image.*
With a freshly booted Image (w/o extensions), the initial TTFB is very high. (Browser: ~5s , Google Page Speed: ~3s). When i refresh the Page in the Browser or in the Page Speed test, the page is delivered quite fast. After not doing anything for about 30 mins, it is very slow again. I disabled all caching mechanisms and could still reproduce this behavior, so i looked in the DB, if there are still some caching actions. It seems, things stored in the table objectcache have a TTL, so i am trying out some combinations of file cache with prefilled page caches and php APCu.
I am using the official Docker Image based on MW 1.32 (apache with mod php 7.2) and i modified it to use a couple of extensions. It runs in a kubernetes environment on the Google Cloud Platform and the DB Backend is a Google Cloud SQL instance with MySQL 5.7. A Google Cloud Storage Bucket is fuse mounted to store uploads permanently. In order to scale horizontally there is a Pod with a redis service to provide all sessions infos to all instances of MW. The plan is to run also a Varnish Caching proxy in front of the LoadBalancer.
*My question is, what are the best practices to solve this issue?*
**
*Best regards,*
*Philipp *
MediaWiki-l mailing list To unsubscribe, go to: https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
MediaWiki-l mailing list To unsubscribe, go to: https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
mediawiki-l@lists.wikimedia.org