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(a)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