Wordpress homepage laadt traag

Pagina: 1
Acties:
  • 2.881 views

Onderwerpen


Acties:
  • 0 Henk 'm!

  • Nyxium
  • Registratie: September 2009
  • Laatst online: 10-11-2024
Beste Tweakers,

Sinds een week draait een website die ik lokaal heb gebouwd op mijn laptop op een server (ubuntu 10.04 LTS + Plesk 10) in een datacenter. Echter wanneer ik de website benader is de homepage erg traag, de rest van de website laadt wel goed/snel.

Hier een screenshot van firebug:

Afbeeldingslocatie: http://cyoniq.com/projecten/wordpress-traag.jpg

Zoals je kunt zien doet hij enorm lang de get aanvraag van het domeinnaam, wat ik dus niet goed begrijp. Een andere website die ook op die server draait heeft maar 30ms nodig voor de eerste GET aanvraag. Lokaal draai ik dus ook een exacte kopie van de Wordpress site + Database en dan doet de homepage het wel gewoon goed. Het zou dan aan de server moeten liggen maar ik heb geen idee wat het kan zijn.

Nu vroeg ik mij af jullie misschien weten waar dit aan kan liggen, alvast bedankt.

Acties:
  • 0 Henk 'm!

  • Wolfboy
  • Registratie: Januari 2001
  • Niet online

Wolfboy

ubi dubium ibi libertas

Het zit volgens jouw afbeelding volledig in de serverside code. Wat er dus exact gebeurt is een beetje de vraag, maar ik zou bijna denken dat er ergens een timeout bereikt wordt (probeert externe server te bereiken, moet 5s wachten op een timeout, etc...)

Het zit iig ergens aan de serverkant.

Je zou deze plugin kunnen gebruiken om te zien of het in de database zit: http://wordpress.org/extend/plugins/debug-queries/

Blog [Stackoverflow] [LinkedIn]


Acties:
  • 0 Henk 'm!

  • simon
  • Registratie: Maart 2002
  • Laatst online: 17:45
de get van de domeinnaam bedoel je de index.php? Blijkbaar moet je in die index.php gaan kijken naar wat hij doet. Een normale Wordpress install zou niets geks moeten doen, disable eens wat dingen die WP op je homepage laat zien. Misschien een brak geprogrammeerde plugin?

|>


Acties:
  • 0 Henk 'm!

  • Nyxium
  • Registratie: September 2009
  • Laatst online: 10-11-2024
Bedankt voor de tips. Het lijkt erop dat het probleem toch in de slider zit.

Ik heb het hele zaakje opnieuw gekopieerd van de server en weer lokaal gedraait + database van de server. Nu heb ik dezelfde problemen als dat hij live draait. De laadtijd bedraagt weer 5 seconden. Ik heb alle plugins uitgezet maar daar lag het niet aan.

Het lijkt hem toch in de slider te zitten op de homepage. Deze bevat 3 slides die ieder een plaatje uit de wp-content/uploads map halen. Elke plaatje is een verkleinde versie van grote foto(4/5 MB). Deze verkleinde plaatjes zijn 25KB max. Toch blijkt hier het probleem in te zitten want wanneer ik een "thumbnail" pak van een kleiner plaatje (800px * 600px) laad de website dus wel gewoon goed. Maar ik zou toch gewoon zo'n thumbnail kunnen gebruiken een groot plaatje of zie ik dat verkeerd?

Acties:
  • 0 Henk 'm!

  • sopsop
  • Registratie: Januari 2002
  • Laatst online: 09:28

sopsop

[v] [;,,;] [v]

Doe je de resize in code? en iedere keer weer opnieuw?

Acties:
  • 0 Henk 'm!

  • André
  • Registratie: Maart 2002
  • Laatst online: 08-07 16:59

André

Analytics dude

Installeer anders een cache module (W3 Total Cache is een aanrader) en kijk wat er dan gebeurd. Je respons zou dan vele malen sneller moeten zijn.

Acties:
  • 0 Henk 'm!

  • Zoefff
  • Registratie: September 2001
  • Laatst online: 20:23

Zoefff

❤ 

Nyxium schreef op maandag 28 mei 2012 @ 14:22:
Bedankt voor de tips. Het lijkt erop dat het probleem toch in de slider zit.

Ik heb het hele zaakje opnieuw gekopieerd van de server en weer lokaal gedraait + database van de server. Nu heb ik dezelfde problemen als dat hij live draait. De laadtijd bedraagt weer 5 seconden. Ik heb alle plugins uitgezet maar daar lag het niet aan.

Het lijkt hem toch in de slider te zitten op de homepage. Deze bevat 3 slides die ieder een plaatje uit de wp-content/uploads map halen. Elke plaatje is een verkleinde versie van grote foto(4/5 MB). Deze verkleinde plaatjes zijn 25KB max. Toch blijkt hier het probleem in te zitten want wanneer ik een "thumbnail" pak van een kleiner plaatje (800px * 600px) laad de website dus wel gewoon goed. Maar ik zou toch gewoon zo'n thumbnail kunnen gebruiken een groot plaatje of zie ik dat verkeerd?
Kan de verkleinde afbeelding wel weggeschreven worden, of wordt deze ieder keer opnieuw verkleind? Want dat verklaart een dergelijke laadtijd wel.


FotoblogWerkaandemuur.nlMoestuincursus.nlTwitter


Acties:
  • 0 Henk 'm!

  • TheNephilim
  • Registratie: September 2005
  • Laatst online: 09-07 12:20

TheNephilim

Wtfuzzle

André schreef op donderdag 31 mei 2012 @ 15:29:
Installeer anders een cache module (W3 Total Cache is een aanrader) en kijk wat er dan gebeurd. Je respons zou dan vele malen sneller moeten zijn.
In dit geval symptoom bestrijding, 5s gewoon voor de website zonder caching is veel te veel. Dus beter met caching gaan werken als dit probleem is opgelost.

Foto's worden in Wordpress 1x verkleind, en wel bij het uploaden. Dus niet wegschrijven/opnieuw verkleinen/etc is niet aan de orde. Ik gok op een foutje in je code waardoor dingen niet helemaal goed lopen. Welke plugins heb je aan staan?

Wat doe je op je frontpage?

Acties:
  • 0 Henk 'm!

  • Nyxium
  • Registratie: September 2009
  • Laatst online: 10-11-2024
mijn excuses voor mijn late reactie, door omstandigheden kon ik niet eerder reageren.

Het probleem is niet opgelost. In eerste instantie leek de website sneller te lopen maar dit was van korte duur. Ik heb nog eens de debug queries plugin gedraaid en kwam tot de volgende resultaten:

alle queries worden vrij rap uitgevoerd behalve 6 stuks. (Zie screenshot)

Afbeeldingslocatie: http://cyoniq.com/images/query_debug_prev.jpg

De totale laadtijd van de pagina bedroeg hier 15 seconden, op deze pagina wordt alleen een slider (3 slides met kleine plaatjes), menu en wat tekst geladen.

Ik neem aan dat ik hier uit kan concluderen dat de MYSQL server de boosdoener hier is

Acties:
  • 0 Henk 'm!

  • RobIII
  • Registratie: December 2001
  • Niet online

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

(overleden)
Het zou sowieso wel fijn zijn / schelen als je een leesbare screenshot plaatst i.p.v. lichtgrijs op iets minder grijs. Mijn monitor is niet al te best, maar ik moest toch even scheel kijken voor ik 't kon lezen. Nog beter: gebruik gewoon [code] of [cmd] tags en plak de melding er in. Hebben andere bezoekers die een/onze zoekmachine gebruik ook nog iets aan je topic ;)

Ik weet overigens niet waar je die gegevens vandaan haalt, maar ik zie daar staan: 9.322166448711E-5; je beseft dat dat 0.000093... is? Sterker nog: als 't 9 seconden was had je pagina minimaal ~1 minuut nodig gehad om te laden...

[ Voor 36% gewijzigd door RobIII op 12-06-2012 10:00 ]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij


Acties:
  • 0 Henk 'm!

  • Nyxium
  • Registratie: September 2009
  • Laatst online: 10-11-2024
oeps, E-5 niet opgemerkt.

De code wordt gegenereerd door de plugin Debug Queries, kleur aanpassen is niet mogelijk.

Dit eindresultaat kreeg ik bij een nieuwe refresh:

Total query time: 0.10879s for 63 queries.
Total num_query time: 6.580 for 64 num_queries.
Page generated in 6.45068s, 98.31% PHP, 1.69% MySQL

98.31% van de tijd is dus PHP bezig? Maar wat ik gek vind is dat lokaal de website dus wel gewoon redelijk snel is 400-500ms voor de eerste GET

Acties:
  • 0 Henk 'm!

  • Zoefff
  • Registratie: September 2001
  • Laatst online: 20:23

Zoefff

❤ 

Tsja, stap 1 is volgens mij altijd alle plugins uitschakelen en dan een voor een aanzetten totdat je de boosdoener tegenkomt (als het probleem in een plugin zit). Dan kan je vanuit daar weer verder zoeken. Wat zijn bijvoorbeeld verschillen tussen je lokale omgeving en online? Versieverschillen in PHP en MySQL, andere PHP configuratie, sommige mappen niet schrijfbaar, etcetera :)


FotoblogWerkaandemuur.nlMoestuincursus.nlTwitter


Acties:
  • 0 Henk 'm!

  • Nyxium
  • Registratie: September 2009
  • Laatst online: 10-11-2024
Alle plugins uit geeft geen verbetering. Ik heb hier thuis nog trial versie van plesk en zelfde ubuntu versie. Mysql PHP en plesk zijn allemaal hetzelfde. Alleen is het hele zaakje in het datacenter is geïnstalleerd door de partij waar ik de VPS huur.

Enige verschil zijn de beschikbare resources, hier thuis heb ik meer geheugen meer cpu kracht. Maar de VPS gebruikt amper CPU en zit momenteel op 500 mb geheugen wat in gebruik is van de 1 gig.

Schrijfbare bestanden kan het probleem ook niet zijn. Heb al eens een versie van de website geprobeerd met 777 rechten

edit:

Website op de VPS met 1 pagina, zonder PHP of MYSQL heeft een GET request van 20 ms. Het moet dus echt aan de PHP liggen maar hoe kan ik dat goed testen.

[ Voor 12% gewijzigd door Nyxium op 12-06-2012 11:31 ]


Acties:
  • 0 Henk 'm!

  • bartbh
  • Registratie: Maart 2004
  • Niet online
Is het nu alleen de home pagina of alle pagina's? Heb je ook al eens een anders thema geprobeerd?

En heb je de plugins ook allemaal gedeactiveerd zoals deze in het dashboard staan?

Acties:
  • 0 Henk 'm!

  • Nyxium
  • Registratie: September 2009
  • Laatst online: 10-11-2024
Ja het probleem doet zich nu voor bij vrijwel alle pagina's zowel de buiten als de binnenkant (wp admin pagina's)

Standaard thema + alle plugins uit heeft geen enkel positief of negatief effect

edit:

hier nog wat stats van de huidige gebruikte/beschikbare resources van de VPS:

code:
1
2
3
4
5
top - 13:21:36 up 10:24,  1 user,  load average: 0.12, 0.20, 0.13
Tasks: 102 total,   1 running, 101 sleeping,   0 stopped,   0 zombie
Cpu(s):  3.3%us,  8.4%sy,  0.0%ni, 88.3%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   1023456k total,   756388k used,   267068k free,    64164k buffers
Swap:  3997688k total,     5840k used,  3991848k free,   234724k cached

[ Voor 54% gewijzigd door Nyxium op 12-06-2012 13:24 ]


Acties:
  • 0 Henk 'm!

  • bartbh
  • Registratie: Maart 2004
  • Niet online
En als je een nieuwe, lege WP-installatie plaatst in een subdomein/map, is die dan ook zo traag of alleen de betreffende WP-installatie?

Acties:
  • 0 Henk 'm!

  • Nyxium
  • Registratie: September 2009
  • Laatst online: 10-11-2024
Subdomein en een ander domein geprobeerd. Allebei zelfde probleem als de rest. 4-6 seconden voor de GET request nodig. En als ik naar overzicht van berichten wil gaan kan dat 30-40 seconden duren voordat de berichten pagina van wp-admin wordt getoond.

Acties:
  • 0 Henk 'm!

  • MueR
  • Registratie: Januari 2004
  • Laatst online: 19:35

MueR

Admin Tweakers Discord

is niet lief

Nyxium schreef op dinsdag 12 juni 2012 @ 11:19:
Enige verschil zijn de beschikbare resources, hier thuis heb ik meer geheugen meer cpu kracht. Maar de VPS gebruikt amper CPU en zit momenteel op 500 mb geheugen wat in gebruik is van de 1 gig.
Dat is heel leuk, maar die CPU en geheugen zijn virtueel. Als de fysieke bak zwaar belast wordt (wat vaak zo is bij goedkope VPS boeren die te veel klanten op een fysieke server zetten), zijn dingen als mysql ook niet vooruit te branden.

Anyone who gets in between me and my morning coffee should be insecure.


Acties:
  • 0 Henk 'm!

  • Nyxium
  • Registratie: September 2009
  • Laatst online: 10-11-2024
Dus jij zou een dedicated server aanraden?

Acties:
  • 0 Henk 'm!

  • Zoefff
  • Registratie: September 2001
  • Laatst online: 20:23

Zoefff

❤ 

Volgens mij moet je eerst op zoek naar de oorzaak van de traagheid en aan de hand daarvan stappen ondernemen waarvan het opschalen of overstappen naar een ander platform er een kán zijn.

Draai bijvoorbeeld eens iets van benchmarks met een kaal PHP script of een klein script dat een paar MySQL verbindingen maakt. Je hebt nu nog steeds geen idee wat het probleem is. Misschien zit er wel ergens een configuratiefout waardoor Wordpress gruwelijk traag is, maar is de bak an sich supersnel. Who knows :P


FotoblogWerkaandemuur.nlMoestuincursus.nlTwitter


Acties:
  • 0 Henk 'm!

  • bartbh
  • Registratie: Maart 2004
  • Niet online
Nyxium schreef op dinsdag 12 juni 2012 @ 14:25:
Subdomein en een ander domein geprobeerd. Allebei zelfde probleem als de rest. 4-6 seconden voor de GET request nodig. En als ik naar overzicht van berichten wil gaan kan dat 30-40 seconden duren voordat de berichten pagina van wp-admin wordt getoond.
Met een lege, nieuwe installatie getest neem ik aan? En niet de betreffende site.

Wat MueR aangeeft klopt gedeeltelijk wel, maar als het goed is heb je in ieder geval een gedeelte van het geheugen voor jou gereserveerd. Hoe dat precies op CPU-basis zit weet ik niet, maar ik dacht ook opdezelfde manier.

Maar dan nog, een WP-installatie stelt niet zoveel voor aangezien dit ook op genoeg shared hosting environments draait. Dus ik zou inderdaad eerst eens gaan zoeken waar de fout nu precies ligt.

Maak wat connecties met MySQL en kijk hoe lang dat duurt. Of misschien zijn er nog wel meer debug tools voor WP.

Acties:
  • 0 Henk 'm!

  • Nyxium
  • Registratie: September 2009
  • Laatst online: 10-11-2024
Het was een lege wordpress installatie ja. Maar ik zit nu een beetje te testen en kijken wat de CPU en RAM doen via top commando. Wanneer ik de website zonder mysql/php bezoek piekt hij naar 0.3% CPU gebruik. Wanneer ik 1 van de wordpress websites benader piekt de CPU naar 90-95% :/

ik heb ook apache ab test uitgevoerd met een simpel php script op een lege webruimte op de server:

code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
Server Software:        Apache
Server Hostname:        -------.nl
Server Port:            80

Document Path:          /php/index.php/
Document Length:        55629 bytes

Concurrency Level:      10
Time taken for tests:   3.052 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Keep-Alive requests:    0
Total transferred:      5576800 bytes
HTML transferred:       5562900 bytes
Requests per second:    32.76 [#/sec] (mean)
Time per request:       305.217 [ms] (mean)
Time per request:       30.522 [ms] (mean, across all concurrent requests)
Transfer rate:          1784.33 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       11   17   4.0     16      31
Processing:   102  276 133.5    244     931
Waiting:       16  107  72.7     91     369
Total:        116  293 134.1    258     950

Percentage of the requests served within a certain time (ms)
  50%    258
  66%    318
  75%    344
  80%    368
  90%    465
  95%    589
  98%    640
  99%    950
 100%    950 (longest request)


32 requests lijkt mij niet heel veel, ik heb ook langere test uitgevoerd daar kwam 27 req/s uit

Acties:
  • 0 Henk 'm!

  • bartbh
  • Registratie: Maart 2004
  • Niet online
En naar welke host heb je dit gedraait, het domein dat op je server draait? Zelf ben ik niet zo bekend met AB.

Als je MySQL uitschakelt en je gaat dan naar je Wordpress pagina, schiet je CPU dan ook zo omhoog?

Acties:
  • 0 Henk 'm!

  • Nyxium
  • Registratie: September 2009
  • Laatst online: 10-11-2024
Dat is naar een van de websites op die server ja. Mysql uischakelen, hoe bedoel je dat precies? Gewoon mysql stoppen op de server?

Als ik dat doe krijg een error van WP dat er geen database connectie is (600MS GET request)

Acties:
  • 0 Henk 'm!

  • NMe
  • Registratie: Februari 2004
  • Laatst online: 04-07 15:03

NMe

Quia Ego Sic Dico.

....maar schiet je CPU nou ook omhoog tijdens zo'n request zonder MySQL of niet?

'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.


Acties:
  • 0 Henk 'm!

  • Nyxium
  • Registratie: September 2009
  • Laatst online: 10-11-2024
Met mysql aan ongeveer 40%-60% piek CPU load bij een request van een homepage van een site die op de server draait.

Zonder mysql is dit 4-6% CPU load, een stuk minder dus.

Acties:
  • 0 Henk 'm!

  • NMe
  • Registratie: Februari 2004
  • Laatst online: 04-07 15:03

NMe

Quia Ego Sic Dico.

Nou, dan weet je waar je het moet zoeken. Check je MySQL-logs eens.

'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.


Acties:
  • 0 Henk 'm!

  • bartbh
  • Registratie: Maart 2004
  • Niet online

Acties:
  • 0 Henk 'm!

  • Nyxium
  • Registratie: September 2009
  • Laatst online: 10-11-2024
Dit staat er in de error log:

code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
120612 21:37:30 [Note] Event Scheduler: Purging the queue. 0 events
120612 21:37:30  InnoDB: Starting shutdown...
120612 21:37:32  InnoDB: Shutdown completed; log sequence number 0 32458868
120612 21:37:32 [Note] /usr/sbin/mysqld: Shutdown complete

120612 21:37:32 [Note] Plugin 'FEDERATED' is disabled.
120612 21:37:33  InnoDB: Started; log sequence number 0 32458868
120612 21:37:33 [Note] Event Scheduler: Loaded 0 events
120612 21:37:33 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.1.41-3ubuntu12.10'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)
120612 21:46:40 [Note] /usr/sbin/mysqld: Normal shutdown

120612 21:46:40 [Note] Event Scheduler: Purging the queue. 0 events
120612 21:46:40  InnoDB: Starting shutdown...
120612 21:46:42  InnoDB: Shutdown completed; log sequence number 0 32460108
120612 21:46:42 [Note] /usr/sbin/mysqld: Shutdown complete

120612 21:46:42 [Note] Plugin 'FEDERATED' is disabled.
120612 21:46:43  InnoDB: Started; log sequence number 0 32460108
120612 21:46:43 [Note] Event Scheduler: Loaded 0 events
120612 21:46:43 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.1.41-3ubuntu12.10'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)


Dit lijken mij geen errors die ontstaan zijn tijden het bezoeken van de pagina's maar tijdens het herstarten van het mysql proces aan de tijd te zien.

Als ik google op "[Note] Plugin 'FEDERATED' is disabled" kom op problemen uit waarbij er een fout in myslq.cnf file zou kunnen zitten. Echter zie ik er niets verkeerd in zo 1 2 3:

code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
# The MySQL database server configuration file.
#
# You can copy this to one of:
# - "/etc/mysql/my.cnf" to set global options,
# - "~/.my.cnf" to set user-specific options.
#
# One can use all long options that the program supports.
# Run program with --help to get a list of available options and with
# --print-defaults to see which it would actually understand and use.
#
# For explanations see
# http://dev.mysql.com/doc/mysql/en/server-system-variables.html

# This will be passed to all mysql clients
# It has been reported that passwords should be enclosed with ticks/quotes
# escpecially if they contain "#" chars...
# Remember to edit /etc/mysql/debian.cnf when changing the socket location.
[client]
port            = 3306
socket          = /var/run/mysqld/mysqld.sock

# Here is entries for some specific programs
# The following values assume you have at least 32M ram

# This was formally known as [safe_mysqld]. Both versions are currently parsed.
[mysqld_safe]
socket          = /var/run/mysqld/mysqld.sock
nice            = 0

[mysqld]
local-infile=0
#

# * Basic Settings

#
# * IMPORTANT
#   If you make changes to these settings and your system uses apparmor, you may
#   also need to also adjust /etc/apparmor.d/usr.sbin.mysqld.
#

user            = mysql
socket          = /var/run/mysqld/mysqld.sock
port            = 3306
basedir         = /usr
datadir         = /var/lib/mysql
tmpdir          = /tmp
skip-external-locking
#
# Instead of skip-networking the default is now to listen only on
# localhost which is more compatible and is not less secure.
bind-address            = 127.0.0.1
#
# * Fine Tuning
#
key_buffer              = 16M
max_allowed_packet      = 16M
thread_stack            = 192K
thread_cache_size       = 8
# This replaces the startup script and checks MyISAM tables if needed
# the first time they are touched
myisam-recover         = BACKUP
#max_connections        = 100
#table_cache            = 64
#thread_concurrency     = 10
#
# * Query Cache Configuration
#
query_cache_limit       = 1M
query_cache_size        = 16M
#
# * Logging and Replication
#
# Both location gets rotated by the cronjob.
# Be aware that this log type is a performance killer.
# As of 5.1 you can enable the log at runtime!
#general_log_file        = /var/log/mysql/mysql.log
#general_log             = 1

log_error                = /var/log/mysql/error.log

# Here you can see queries with especially long duration
#log_slow_queries       = /var/log/mysql/mysql-slow.log
#long_query_time = 2

#log-queries-not-using-indexes
#
# The following can be used as easy to replay backup logs or for replication.
# note: if you are setting up a replication slave, see README.Debian about
#       other settings you may need to change.
#server-id              = 1
#log_bin                        = /var/log/mysql/mysql-bin.log
expire_logs_days        = 10
max_binlog_size         = 100M
#binlog_do_db           = include_database_name
#binlog_ignore_db       = include_database_name
#
# * InnoDB
#
# InnoDB is enabled by default with a 10MB datafile in /var/lib/mysql/.
# Read the manual for more InnoDB related options. There are many!
#
# * Security Features
#
# Read the manual, too, if you want chroot!
# chroot = /var/lib/mysql/
#
# For generating SSL certificates I recommend the OpenSSL GUI "tinyca".
#
# ssl-ca=/etc/mysql/cacert.pem
# ssl-cert=/etc/mysql/server-cert.pem
# ssl-key=/etc/mysql/server-key.pem

[mysqldump]
quick
quote-names
max_allowed_packet      = 16M

[mysql]
#no-auto-rehash # faster start of mysql but no tab completition

[isamchk]
key_buffer              = 16M

#
# * IMPORTANT: Additional settings that can override those from this file!
#   The files must end with '.cnf', otherwise they'll be ignored.
#
!includedir /etc/mysql/conf.d/


Het zou ook kunnen zijn dat de mysql database waar ik het mee ben begonnen (lokaal) een andere versie is vergeleken met de mysql database op de server maar dat is ook niet het geval. Beide versie 5.1 en ik heb ook al geprobeerd een database via de VPS te maken dmv schone install wordpress op een leeg domein. Dus dat kan het ook niet zijn.

edit:

slow log aangezet maar zo te zien is alleen het log bestand aangemaakt en is er geen query in geplaatst

code:
1
2
3
/usr/sbin/mysqld, Version: 5.1.41-3ubuntu12.10-log ((Ubuntu)). started with:
Tcp port: 3306  Unix socket: /var/run/mysqld/mysqld.sock
Time                 Id Command    Argument


edit 2:

long_query_time op 5 seconden gezet maar ook dan staat er niks in het log bestand

edit 3:

Zojuist nog eens slow-query log bestand bekeken en toen kwam ik dit tegen. Ik heb een apt-get update uitgevoerd en server restart.

code:
1
2
3
4
5
6
7
8
9
10
11
12
# Time: 120613 13:46:42
# User@Host: debian-sys-maint[debian-sys-maint] @ localhost []
# Query_time: 6.569856  Lock_time: 0.001626 Rows_sent: 253  Rows_examined: 505
SET timestamp=1339588002;
select concat('select count(*) into @discard from `',
                    TABLE_SCHEMA, '`.`', TABLE_NAME, '`')
      from information_schema.TABLES where ENGINE='MyISAM';
# Time: 120613 13:46:52
# User@Host: debian-sys-maint[debian-sys-maint] @ localhost []
# Query_time: 6.732629  Lock_time: 0.000794 Rows_sent: 0  Rows_examined: 505
SET timestamp=1339588012;
select count(*) into @discard from `information_schema`.`PARTITIONS`;


Google resultaten laat zien dat debian-sys-maint zorgt voor afsluien en opstarten van mysql?

[ Voor 8% gewijzigd door Nyxium op 13-06-2012 14:01 ]


Acties:
  • 0 Henk 'm!

  • Nyxium
  • Registratie: September 2009
  • Laatst online: 10-11-2024
Net een plugin WP Super Cache geïnstalleerd, dan laden gecachde pagina's wel super snel. Wanneer pagina's benaderd worden die nog niet in de cache staan heb ik nog steeds hetzelfde probleem.

Nog eens gekeken naar de CPU wanneer ik een pagina aanklik die nog niet in de cache staat en dan zie ik dat Apache wel direct aan werk gaat, mysql heeft trouwens echt een hele lage load wanneer pagina's benaderd worden.

Acties:
  • 0 Henk 'm!

  • CH4OS
  • Registratie: April 2002
  • Niet online

CH4OS

It's a kind of magic

TheNephilim schreef op donderdag 07 juni 2012 @ 15:27:
In dit geval symptoom bestrijding, 5s gewoon voor de website zonder caching is veel te veel. Dus beter met caching gaan werken als dit probleem is opgelost.
Daarnaast heeft W3 Total Cache (Super Cache ook overigens) de narigheid meer te slopen dan je lief is, is mijn ervaring.

[ Voor 3% gewijzigd door CH4OS op 24-06-2012 14:45 ]


Acties:
  • 0 Henk 'm!

  • NMe
  • Registratie: Februari 2004
  • Laatst online: 04-07 15:03

NMe

Quia Ego Sic Dico.

Nyxium schreef op woensdag 13 juni 2012 @ 23:21:
Nog eens gekeken naar de CPU wanneer ik een pagina aanklik die nog niet in de cache staat en dan zie ik dat Apache wel direct aan werk gaat, mysql heeft trouwens echt een hele lage load wanneer pagina's benaderd worden.
Nogal wiedes, want MySQL cachet by default query's. Veruit de meeste query's die een simpele WP-site doet zijn prima cachebaar. Het is pas spannend als je een nieuwe query uitvoert of je query cache leegt. ;)

'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.


Acties:
  • 0 Henk 'm!

  • Nyxium
  • Registratie: September 2009
  • Laatst online: 10-11-2024
ja precies, dan is alles weer zo traag als voorheen. Heb trouwens ook geprobeerd te achterhalen met welke query de server bezig is tijdens het opvragen van een pagina met de command show processlist; maar daar is ook niets te zien.

Acties:
  • 0 Henk 'm!

  • CH4OS
  • Registratie: April 2002
  • Niet online

CH4OS

It's a kind of magic

Hoe heb je die query gedaan dan? Probeer het anders bijvoorbeeld met PHPMyAdmin even of, als je console toegang hebt, op de console.

[ Voor 73% gewijzigd door CH4OS op 13-06-2012 23:58 ]


Acties:
  • 0 Henk 'm!

  • Nyxium
  • Registratie: September 2009
  • Laatst online: 10-11-2024
Ik had hem op de console uitgevoerd

edit:

deze uitvoer krijg ik in phpmyadmin terwijl ik een niet gecachde pagina opvraag (pagina laadtijd 4sec)

code:
1
2
3
4
Kill Kill   2169    hofenzo     localhost   testdb  Sleep   1       NULL
Kill Kill   2171    admin   localhost   psa     Sleep   1       NULL
Kill Kill   2172    pma_svlZ4MPjpe78    localhost   NULL    Sleep   0       NULL
Kill Kill   2173    admin   localhost   NULL    Query   0   NULL    SHOW PROCESSLIST


De bovenste regel is er bijgekomen vergeleken met een processlist waarbij de server niks doet (en ik dus geen pagina's opvraag).

[ Voor 89% gewijzigd door Nyxium op 14-06-2012 00:26 ]


Acties:
  • 0 Henk 'm!

  • CH4OS
  • Registratie: April 2002
  • Niet online

CH4OS

It's a kind of magic

Dan kan je in ieder geval dus uitsluiten dat het een SQL-query is. Is er overigens niet iets terug te vinden in de logfile? Aangezien het lokaal wel goed werkt, zijn er enige software of configuratie verschillen? Wellicht zit het hem daar in?

Acties:
  • 0 Henk 'm!

  • RobIII
  • Registratie: December 2001
  • Niet online

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

(overleden)
NMe schreef op woensdag 13 juni 2012 @ 23:35:
[...]

Nogal wiedes, want MySQL cachet by default query's.
:Y Klopt. Tenzij. Misschien is dat dus ook nog even een puntje om naar te kijken (en anders is 't altijd handig te weten voor 'n volgende keer ;) )

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij


Acties:
  • 0 Henk 'm!

  • Nyxium
  • Registratie: September 2009
  • Laatst online: 10-11-2024
in de mysql error log staat niets vreemd voor zover ik kan zien:

code:
1
2
3
4
5
6
7
8
120613 13:44:39 [Note] Event Scheduler: Purging the queue. 0 events
120613 13:44:39  InnoDB: Starting shutdown...
120613 13:44:41  InnoDB: Shutdown completed; log sequence number 0 33231029
120613 13:44:41 [Note] /usr/sbin/mysqld: Shutdown complete

120613 13:46:31 [Note] Plugin 'FEDERATED' is disabled.
120613 13:46:33  InnoDB: Started; log sequence number 0 33231029
120613 13:46:34 [Note] Event Scheduler: Loaded 0 events


slow-query op 1seconde gezet en nu komt dit naar boven in de slow-query log:

code:
1
2
3
4
5
6
7
8
9
# User@Host: debian-sys-maint[debian-sys-maint] @ localhost []
# Query_time: 2.323276  Lock_time: 0.005684 Rows_sent: 0  Rows_examined: 5495
SET timestamp=1339626814;
select count(*) into @discard from `information_schema`.`COLUMNS`;
# Time: 120614  0:33:36
# User@Host: debian-sys-maint[debian-sys-maint] @ localhost []
# Query_time: 1.989958  Lock_time: 0.130794 Rows_sent: 0  Rows_examined: 505
SET timestamp=1339626816;
select count(*) into @discard from `information_schema`.`PARTITIONS`;


Query time van 2.3 sec is vrij lang lijkt me

Acties:
  • 0 Henk 'm!

  • Nyxium
  • Registratie: September 2009
  • Laatst online: 10-11-2024
in de apache log zie ik ook niet veel vreemds behavle dat een aantal (volgens mij) chinese sites directories opvragen die niet bestaan.

code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
PHP Deprecated:  Comments starting with '#' are deprecated in /etc/php5/apache2/conf.d/imap.ini on line 1 in Unknown on line 0
PHP Warning:  Directive 'safe_mode' is deprecated in PHP 5.3 and greater in Unknown on line 0
[Thu Jun 14 02:28:28 2012] [notice] mod_python: Creating 8 session mutexes based on 150 max processes and 0 max threads.
[Thu Jun 14 02:28:28 2012] [notice] mod_python: using mutex_directory /tmp
[Thu Jun 14 02:28:29 2012] [warn] RSA server certificate CommonName (CN) `Parallels Panel' does NOT match server name!?
[Thu Jun 14 02:28:29 2012] [warn] RSA server certificate CommonName (CN) `Parallels Panel' does NOT match server name!?
[Thu Jun 14 02:28:29 2012] [warn] RSA server certificate CommonName (CN) `Parallels Panel' does NOT match server name!?
[Thu Jun 14 02:28:29 2012] [warn] Init: Name-based SSL virtual hosts only work for clients with TLS server name indication support (RFC 4366)
[Thu Jun 14 02:28:29 2012] [notice] Apache/2.2.14 (Ubuntu) DAV/2 mod_fcgid/2.3.6 mod_python/3.3.1 Python/2.6.5 mod_ssl/2.2.14 OpenSSL/0.9.8k mod_perl/2.0.4 Perl/v5.10.1 configured -- resuming normal operations
[Thu Jun 14 03:52:50 2012] [error] [client 72.9.159.168] client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23): /w00tw00t.at.ISC.SANS.DFind:)
[Thu Jun 14 04:16:16 2012] [error] [client 58.218.199.227] script '/var/www/vhosts/default/htdocs/proxyheader.php' not found or unable to stat
[Thu Jun 14 06:50:34 2012] [error] [client 74.63.232.6] client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23): /w00tw00t.at.ISC.SANS.DFind:)
[Thu Jun 14 08:38:56 2012] [error] [client 91.102.162.194] client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23): /w00tw00t.at.ISC.SANS.DFind:)
[Thu Jun 14 08:39:57 2012] [error] [client 122.70.129.72] File does not exist: /var/www/vhosts/default/htdocs/phpmyadmin
[Thu Jun 14 08:39:58 2012] [error] [client 122.70.129.72] File does not exist: /var/www/vhosts/default/htdocs/phpMyAdmin
[Thu Jun 14 08:39:59 2012] [error] [client 122.70.129.72] File does not exist: /var/www/vhosts/default/htdocs/PMA
[Thu Jun 14 08:39:59 2012] [error] [client 122.70.129.72] File does not exist: /var/www/vhosts/default/htdocs/pma
[Thu Jun 14 08:40:00 2012] [error] [client 122.70.129.72] File does not exist: /var/www/vhosts/default/htdocs/admin
[Thu Jun 14 08:40:01 2012] [error] [client 122.70.129.72] File does not exist: /var/www/vhosts/default/htdocs/dbadmin
[Thu Jun 14 08:40:02 2012] [error] [client 122.70.129.72] File does not exist: /var/www/vhosts/default/htdocs/sql
[Thu Jun 14 08:40:04 2012] [error] [client 122.70.129.72] File does not exist: /var/www/vhosts/default/htdocs/db
[Thu Jun 14 08:40:08 2012] [error] [client 122.70.129.72] File does not exist: /var/www/vhosts/default/htdocs/web
[Thu Jun 14 08:40:21 2012] [error] [client 122.70.129.72] File does not exist: /var/www/vhosts/default/htdocs/phpmyadmin2
[Thu Jun 14 08:40:22 2012] [error] [client 122.70.129.72] File does not exist: /var/www/vhosts/default/htdocs/phpMyAdmin2
[Thu Jun 14 08:40:23 2012] [error] [client 122.70.129.72] File does not exist: /var/www/vhosts/default/htdocs/phpMyAdmin-2
[Thu Jun 14 08:40:23 2012] [error] [client 122.70.129.72] File does not exist: /var/www/vhosts/default/htdocs/php-my-admin
[Thu Jun 14 08:40:24 2012] [error] [client 122.70.129.72] File does not exist: /var/www/vhosts/default/htdocs/php-myadmin
[Thu Jun 14 08:40:25 2012] [error] [client 122.70.129.72] File does not exist: /var/www/vhosts/default/htdocs/phpadmin
[Thu Jun 14 08:40:26 2012] [error] [client 122.70.129.72] File does not exist: /var/www/vhosts/default/htdocs/sqlmanager
[Thu Jun 14 08:40:27 2012] [error] [client 122.70.129.72] File does not exist: /var/www/vhosts/default/htdocs/mysqlmanager
[Thu Jun 14 08:40:27 2012] [error] [client 122.70.129.72] File does not exist: /var/www/vhosts/default/htdocs/typo3
[Thu Jun 14 08:40:28 2012] [error] [client 122.70.129.72] File does not exist: /var/www/vhosts/default/htdocs/p
[Thu Jun 14 08:40:32 2012] [error] [client 122.70.129.72] File does not exist: /var/www/vhosts/default/htdocs/pma2005
[Thu Jun 14 08:40:34 2012] [error] [client 122.70.129.72] File does not exist: /var/www/vhosts/default/htdocs/phpmanager
[Thu Jun 14 08:40:37 2012] [error] [client 122.70.129.72] File does not exist: /var/www/vhosts/default/htdocs/php-myadmin
[Thu Jun 14 08:40:38 2012] [error] [client 122.70.129.72] File does not exist: /var/www/vhosts/default/htdocs/phpmy-admin
[Thu Jun 14 08:40:38 2012] [error] [client 122.70.129.72] File does not exist: /var/www/vhosts/default/htdocs/webadmin
[Thu Jun 14 08:40:39 2012] [error] [client 122.70.129.72] File does not exist: /var/www/vhosts/default/htdocs/sqlweb
[Thu Jun 14 08:40:40 2012] [error] [client 122.70.129.72] File does not exist: /var/www/vhosts/default/htdocs/websql
[Thu Jun 14 08:40:41 2012] [error] [client 122.70.129.72] File does not exist: /var/www/vhosts/default/htdocs/webdb
[Thu Jun 14 08:40:48 2012] [error] [client 122.70.129.72] File does not exist: /var/www/vhosts/default/htdocs/mysql-admin
[Thu Jun 14 08:40:48 2012] [error] [client 122.70.129.72] File does not exist: /var/www/vhosts/default/htdocs/mysqlmanager
[Thu Jun 14 08:40:52 2012] [error] [client 122.70.129.72] File does not exist: /var/www/vhosts/default/htdocs/admin
[Thu Jun 14 13:07:42 2012] [error] [client 178.154.211.250] File does not exist: /var/www/vhosts/default/htdocs/robots.txt
[Thu Jun 14 13:51:18 2012] [error] [client 134.102.96.173] client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23): /w00tw00t.at.ISC.SANS.DFind:)


Ik ga maar is een expert inschakelen om uit te zoeken waarom de pagina's zo traag laden,

Acties:
  • 0 Henk 'm!

  • bartbh
  • Registratie: Maart 2004
  • Niet online
Dat zijn standaard "aanvallen" op website, om te kijken of ze een admin systeem kunnen vinden dat te kraken is. Heeft mijns inziens niets van doen met jouw probleem, tenzij het er zoveel zouden worden dat het je site als geheel vertraagd.

Acties:
  • 0 Henk 'm!

  • Wolfboy
  • Registratie: Januari 2001
  • Niet online

Wolfboy

ubi dubium ibi libertas

RobIII schreef op donderdag 14 juni 2012 @ 00:38:
[...]

:Y Klopt. Tenzij. Misschien is dat dus ook nog even een puntje om naar te kijken (en anders is 't altijd handig te weten voor 'n volgende keer ;) )
Sowieso wordt de query cache getrasht zodra je iets van updates op de tabel doet.

Ik zou dan ook heel voorzichtig zijn met het gebruik, kan zinnig zijn maar in een aantal gevallen zal het eerder vertragend werken.

Blog [Stackoverflow] [LinkedIn]


Acties:
  • 0 Henk 'm!

  • Nyxium
  • Registratie: September 2009
  • Laatst online: 10-11-2024
Uit frustratie een nieuwe VPS gehuurd omdat ik bang was dat ik de instellingen van de andere VPS had verziekt. Dus weer precies dezelfde VPS specificaties genomen (Plesk 10.4.4 + Ubuntu 10.04 LTS). Weer een test domein aangemaakt met verse wordpress installatie en ja hoor weer gewoon 3-5 seconden laadtijd bij de homepage. Het moet dus gewoon aan de combinatie plesk 10.4.4 + Ubuntu 10.04 + wordpress liggen op 1 of andere manier. Wanneer ik google op plesk 10.4.4 + ubuntu 10.04 kom ik nergens vergelijkbare verhalen tegen wat het nog frustrerender maakt.

De reden dat ik voor Ubuntu heb gekozen is omdat ik daar aardig mijn weg in kan vinden maar om 1 of andere reden werkt het gewoon niet met plesk en wordpress. Althans werkt het bij mij niet. Statische pagina's wel super snel.

Wat ik overigens gek blijf vinden is dat alles het wel goed heeft gedaan maar dat de problemen sinds vorige week zijn ontstaan. Waardoor mijn hoster bijna wel de oorzaak moet zijn :/. Ik hou jullie op de hoogte.

Acties:
  • 0 Henk 'm!

  • Wolfboy
  • Registratie: Januari 2001
  • Niet online

Wolfboy

ubi dubium ibi libertas

In dat geval... gokje, ergens een DNS resolving probleem? Probeer eens op IP adres met de database te verbinden ofzo

Blog [Stackoverflow] [LinkedIn]


Acties:
  • 0 Henk 'm!

  • Nyxium
  • Registratie: September 2009
  • Laatst online: 10-11-2024
Je bedoelt via mysql query browser of iets dergelijks?

Acties:
  • 0 Henk 'm!

  • bartbh
  • Registratie: Maart 2004
  • Niet online
Heb je de grafische installatie draaien van Ubuntu?

Wolfboy doelt denk ik op het serveradres van MySQL. Maar ik gok dat dat gewoon localhost is, aangezien je een VPS’je draait. In dat geval zou dat geen DNS probleem zijn.

En installeer eens een ander CMS dan, iets van Joomla of whatever. Zo kun je in ieder geval uitsluiten of het een WP specifiek probleem is.

Acties:
  • 0 Henk 'm!

  • Nyxium
  • Registratie: September 2009
  • Laatst online: 10-11-2024
Het is opgeslost zo blijkt... De VPS is volgens de hoster op een andere server gezet en alle problemen lijken als sneeuw voor de zon te zijn verdwenen. Pagina's laden weer met de juiste snelheid (300-400 ms GET request). Hij stond dus toch gewoon op een overvolle server blijkbaar :/,

Dagen frusratie omdat ik dacht dat bij mij de fout lag, voor niks. Nouja ik heb wel weer een hoop geleerd mbv jullie suggesties, bedankt jongens!

Acties:
  • 0 Henk 'm!

  • bartbh
  • Registratie: Maart 2004
  • Niet online
Vreemd, ik ben (was) in de veronderstelling dat je juist bij een VPS geen last had van andere gebruikers.

Acties:
  • 0 Henk 'm!

  • Nyxium
  • Registratie: September 2009
  • Laatst online: 10-11-2024
Ja ik maar blijkbaar oversellen ze toch ofzo. Het is een van de grootste hosters van Nederland.

Acties:
  • 0 Henk 'm!

  • bartbh
  • Registratie: Maart 2004
  • Niet online
Om welke hoster gaat het in dit geval dan?

Acties:
  • 0 Henk 'm!

  • Nyxium
  • Registratie: September 2009
  • Laatst online: 10-11-2024
Leaseweb.

Nu nog proberen om m'n geld terug te krijgen van de extra VPS die ik heb aangeschaft, waarmee ik uiteindelijk kon aantonen dat het probleem toch echt bij hun lag en niet bij mij. Daardoor zijn ze beter gaan kijken naar het probleem.

Acties:
  • 0 Henk 'm!

  • Nyxium
  • Registratie: September 2009
  • Laatst online: 10-11-2024
Nou ik heb met Leaseweb gepsroken en heb m'n geld terug gekregen van de tweede VPS dus uiteindelijk is alles netjes afgehandeld.

Nogmaals dank voor jullie reacties.

Acties:
  • 0 Henk 'm!

  • BtM909
  • Registratie: Juni 2000
  • Niet online

BtM909

Watch out Guys...

Wil je volgende keer even oplettten dat je niet zomaar een dubbel of triple post maakt? Gewoon je laatste bericht editen (als die jonger dan 24uur is), aub! :)

Ace of Base vs Charli XCX - All That She Boom Claps (RMT) | Clean Bandit vs Galantis - I'd Rather Be You (RMT)
You've moved up on my notch-list. You have 1 notch
I have a black belt in Kung Flu.


Acties:
  • 0 Henk 'm!

  • MueR
  • Registratie: Januari 2004
  • Laatst online: 19:35

MueR

Admin Tweakers Discord

is niet lief

Grappig, zo'n vermoeden had ik al.
bartbh schreef op vrijdag 15 juni 2012 @ 10:03:
Vreemd, ik ben (was) in de veronderstelling dat je juist bij een VPS geen last had van andere gebruikers.
Jawel hoor. Je zit net zo goed op een fysieke server te werken als bij een shared hosting omgeving. Het enige voordeel van een VPS omgeving is dat het praktisch onmogelijk is voor anderen om bij jouw files te komen. Als er te veel VPSjes op zo'n bak staan, of een van de gebruikers trekt asociaal veel CPU/RAM is het alsnog op.

[ Voor 9% gewijzigd door MueR op 20-06-2012 10:50 ]

Anyone who gets in between me and my morning coffee should be insecure.


Acties:
  • 0 Henk 'm!

  • bartbh
  • Registratie: Maart 2004
  • Niet online
Ik dacht dat het idee van zo'n VPS juist was dat je een max aantal cores of percentage van het RAM kunt gebruiken. Dus als 1 gebruiker vol aan z'n max CPU/RAM zit, dat een ander daar geen last van heeft.

Hoe kan ik überhaupt controleren of mijn VPS (andere leverancier overigens) overselled is, als je problemen ondervind met geheugen/snelheid etc.? Of is dat niet na te gaan, zoals bij Nyxium het geval is?

Acties:
  • 0 Henk 'm!

  • Nyxium
  • Registratie: September 2009
  • Laatst online: 10-11-2024
@BtM909, ik zal er in het vervolg op letten.

@MueR, ik dacht echt dat dat tegenwoordig wel goed geregeld was m.b.v. software die voorkomt dat zo'n fysieke bak het te druk krijgt maar niet dus.

Ik zit sowieso te denken om over te stappen op een dedicated server want de stabiliteit van de VPSjes die ik heb getest laat nog wel wat te wensen over.

Hoe je kunt controleren of je VPS niet op een te drukke server staat heb ik geen idee. Bij versio kun je iig wel zelf je VPS op een andere server zetten had ik gehoord. Ik heb hier echter geen ervaring mee.

Acties:
  • 0 Henk 'm!

Anoniem: 840121

Hallo,

Misschien heb je er wat aan..
Wij hebben ook veel plugins geprobeerd en gezocht naar het probleem van een trage Wordpress site.
Ook hebben we gezocht naar een goede provider voor Wordpress. Eerst gekeken bij Transip maar daar bleek de website niet snel genoeg. Prijs was wel laag, maar onze website moest juist snel laden.
Wordpress is toch best een zwaar platform.. :-(

Uiteindelijk wat verschillende bedrijven die gespecialiseerd zijn in Wordpress Hosting onze website laten testen. Dat werkte wel heel goed. We hebben nu een speciale server met Varnish / Supercache via *spam*. Dat werkt toch veel sneller dan een goedkoop hosting.


Succes in ieder geval met de zoek

[ Voor 2% gewijzigd door NMe op 27-11-2016 23:49 ]


Acties:
  • 0 Henk 'm!

  • DJMaze
  • Registratie: Juni 2002
  • Niet online
Anoniem: 840121 schreef op woensdag 16 november 2016 @ 09:16:
Uiteindelijk wat verschillende bedrijven die gespecialiseerd zijn in Wordpress Hosting onze website laten testen. Dat werkte wel heel goed. We hebben nu een speciale server met Varnish / Supercache via *spam. Dat werkt toch veel sneller dan een goedkoop hosting.
Ik host veel websites en heb 0 problemen qua snelheid en gebruik geen Varnish noch Supercache.
Het probleem is niet de hosting, maar de website zelf.

[ Voor 3% gewijzigd door NMe op 27-11-2016 23:51 . Reden: Overduidelijke spam citeren is niet zo handig. ]

Maak je niet druk, dat doet de compressor maar


Acties:
  • 0 Henk 'm!

  • vinz98
  • Registratie: Mei 2001
  • Laatst online: 07-02-2022

vinz98

Whatmovesyou? Tell me

Sites zoals Yslow en een plugin zoals P3 Profiler geeft op zich al veel inzicht.

Acties:
  • 0 Henk 'm!

  • Aer0
  • Registratie: Maart 2009
  • Laatst online: 16-08-2024

Aer0

Prutsert.

Eh, dit is een necro van een topic van vier jaar, en dat alleen voor wat lijkt op een advertentiepoging.

Acties:
  • 0 Henk 'm!

  • NMe
  • Registratie: Februari 2004
  • Laatst online: 04-07 15:03

NMe

Quia Ego Sic Dico.

Ik mag hopen dat de TS vier jaar later het probleem wel heeft opgelost. Een topic kicken alleen om je spamlinkje hier te dumpen wordt sowieso niet gewaardeerd op GoT.

'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.

Pagina: 1

Dit topic is gesloten.