We hebben een website bij een externe hoster draaien waarbij de backend echt te > langzaam is. Eerst was hij wel snel, medio eind december 2014. Ik was bang dat dat door shared hosting te veel websites op een dezelfde server staan.
Indicatie vertragingen:
- Front-end site snel en is gewoon goed
- Oproepen inlogscherm administrator gewoon snel
- Inloggen duurt maar liefst 36 seconden
- Oproepen van b.v. een artikel in artikelbeheer duurt 11-16 s
Antwoord hosting bedrijf:
Dit lijkt gelukkig niet te maken te hebben met de hoeveelheid gebruikers op de server, aangezien de belasting op de server ver onder de capaciteit ligt. Zie voor een globale indicatie de grafiek in de bijlage; lichtblauw is hierin ongebruikte CPU capaciteit. Hierin lijkt het probleem dan ook niet te zitten, aangezien de server meer dan voldoende resources tot zijn beschikking heeft.
We kunnen echter wel met enige zekerheid controleren of er iets op de server voor vertraging zorgt. Dit doen we door jouw webhostingpakket te migreren naar ons nieuwe (en snellere) Gen4 platform.
Na de overzetting naar een snellere server blijkt nu alles binnen Joomla backend weer soepel te lopen. Het heeft dus wel effect gehad, hoewel nog niet de optimale snelheid wordt bereikt..
Wij hebben geen verstand van MySQL databases en laten alles aan Joomla over. Toch blijft het fenomeen bestaan dat de MySQL database momenteel nog steeds groot is, n.l. 556 MB
Enkele feiten van onze website: www.rtvridderkerk.nl
Joomla 3.4.1
PHP 5.5.22
MySQL 5.5.40
Momenteel 717 artikelen met diverse fotos.
720 image bestanden, totaal 33,7 MB (35.390.641 bytes). Standaard procedure is dat fotos verkleind worden tot maximaal 450 pixels breed
Een totale backup van website via Akeeba Backup bedraagt 52 MB (54.494.067 bytes)
Via Joomla Backend => Admin Tools => Optimaliseer database tabellen
Via Direct Admin hosting provider => optimize
Nu is mijn vraag, is een MySQL database van 556 MB logisch voor bovengenoemde content of is de database op een of andere manier vervuild/ corrupt wat een eerdere vertraging kan veroorzaken ??
Antwoord hosting bedrijf:
Een database van bijna 600MB is vrijwel nooit logisch, tenzij het bijvoorbeeld om enorme grote datasets gaat. Bij een 'gewone' website zou je dit niet verwachten.
Er bestaat dus inderdaad een kans dat bepaalde tabellen in de database vervuild zijn geraakt. Denk hierbij bijvoorbeeld aan comment-spam of een onbeveiligd gastenboek - dit is een oorzaak die vaak tot grote databases leidt.
Je kan dit het beste eens controleren door via PHPMyAdmin in te loggen op de database , en dan na te gaan of deze extreem grote tabellen bevat, en zo ja, welke.
Nu ga ik me op glad ijs bewegen en heb de stoute schoenen aangetrokken en ingelogd in de database. Het resultaat is dat ik een tabel jos_session van 429 MiB heb gevonden (session counter).
Dat lijkt dus de boosdoender te zijn maar geen idee om op te lossen. Nog eens mijn Joomla instellingen bekeken :o:
- sessielevensduur 99999 (voorkomen onverwacht eruit gooien)
- sessieafhandeling => database
Kan dit de boosdoener zijn en wat moet ik instellen in Joomla ? Kan ik de tabel jos_session zomaar op een of andere manier leegmaken. ?
Ik ben benieuwd wie ons kan helpen,
Groeten,
Wessel
Indicatie vertragingen:
- Front-end site snel en is gewoon goed
- Oproepen inlogscherm administrator gewoon snel
- Inloggen duurt maar liefst 36 seconden
- Oproepen van b.v. een artikel in artikelbeheer duurt 11-16 s
Antwoord hosting bedrijf:
Dit lijkt gelukkig niet te maken te hebben met de hoeveelheid gebruikers op de server, aangezien de belasting op de server ver onder de capaciteit ligt. Zie voor een globale indicatie de grafiek in de bijlage; lichtblauw is hierin ongebruikte CPU capaciteit. Hierin lijkt het probleem dan ook niet te zitten, aangezien de server meer dan voldoende resources tot zijn beschikking heeft.
We kunnen echter wel met enige zekerheid controleren of er iets op de server voor vertraging zorgt. Dit doen we door jouw webhostingpakket te migreren naar ons nieuwe (en snellere) Gen4 platform.
Na de overzetting naar een snellere server blijkt nu alles binnen Joomla backend weer soepel te lopen. Het heeft dus wel effect gehad, hoewel nog niet de optimale snelheid wordt bereikt..
Wij hebben geen verstand van MySQL databases en laten alles aan Joomla over. Toch blijft het fenomeen bestaan dat de MySQL database momenteel nog steeds groot is, n.l. 556 MB
Enkele feiten van onze website: www.rtvridderkerk.nl
Joomla 3.4.1
PHP 5.5.22
MySQL 5.5.40
Momenteel 717 artikelen met diverse fotos.
720 image bestanden, totaal 33,7 MB (35.390.641 bytes). Standaard procedure is dat fotos verkleind worden tot maximaal 450 pixels breed
Een totale backup van website via Akeeba Backup bedraagt 52 MB (54.494.067 bytes)
Via Joomla Backend => Admin Tools => Optimaliseer database tabellen
Via Direct Admin hosting provider => optimize
Nu is mijn vraag, is een MySQL database van 556 MB logisch voor bovengenoemde content of is de database op een of andere manier vervuild/ corrupt wat een eerdere vertraging kan veroorzaken ??
Antwoord hosting bedrijf:
Een database van bijna 600MB is vrijwel nooit logisch, tenzij het bijvoorbeeld om enorme grote datasets gaat. Bij een 'gewone' website zou je dit niet verwachten.
Er bestaat dus inderdaad een kans dat bepaalde tabellen in de database vervuild zijn geraakt. Denk hierbij bijvoorbeeld aan comment-spam of een onbeveiligd gastenboek - dit is een oorzaak die vaak tot grote databases leidt.
Je kan dit het beste eens controleren door via PHPMyAdmin in te loggen op de database , en dan na te gaan of deze extreem grote tabellen bevat, en zo ja, welke.
Nu ga ik me op glad ijs bewegen en heb de stoute schoenen aangetrokken en ingelogd in de database. Het resultaat is dat ik een tabel jos_session van 429 MiB heb gevonden (session counter).
Dat lijkt dus de boosdoender te zijn maar geen idee om op te lossen. Nog eens mijn Joomla instellingen bekeken :o:
- sessielevensduur 99999 (voorkomen onverwacht eruit gooien)
- sessieafhandeling => database
Kan dit de boosdoener zijn en wat moet ik instellen in Joomla ? Kan ik de tabel jos_session zomaar op een of andere manier leegmaken. ?
Ik ben benieuwd wie ons kan helpen,
Groeten,
Wessel
Probleem Backend Joomla 3.3.6/ 3.4 traag