Seite Lahmt sehr stark, immer öfters Fehler 500!

[Siggi84]

Hallo, allgemein würde ich sagen ist das VMS kein Performance wunder das ist klar

Bei der datenbank würde ich mal versuchen ob die Mailreloads geleert werden könnten denn 11MB sind glaube ich schon ein bisschen viel.

Zum fehler 500.

Zu 1.
Wenn dir einen gefallen tun willst und ein etliches an Zeit sparen willst, dann wirst bei der Tabelle kurz und schmerzlos machen müssen..11 MB sind ein haufen Zeug^^

Tabelle leeren und fertig. Wird sich mit ein paar Kampagnen überschneiden, aber besser so, als anders^^

Zu 2.
Die php.ini liegt im root Verzeichnis. Wenn du der Betreiber von dem Server bist, und root rechte hast, kannst drauf zu greifen.

Zu. 3
Hier: http://www.designerscripte.net/downl...?do=file&id=69

Die muss leicht angepasst werden, gibts aber auch schon Threads dazu, einfach mal sufu benutzen

LG

Das kommt natürlich darauf an, wie das Addon, das diese Tabelle angelegt hat, die Werte interpretiert. Vermutlich wird es aber ähnlich wie bei den Forcedbanner Reloads sein, also so in etwa:

db_query('DELETE FROM `vms_reloads_mail` WHERE bis <  '.time()); 

Einen 500'er Fehler näher einzugrenzen ohne vollen Zugriff auf Logs und Konfiguration ist quasi kaum möglich, aufgrund des Webspace Pakets würde ich einfach mal von einer Überlastung ausgehen.

Im phpmyadmin sieht man normalerweise iwo eine Statistik, wie viele Anfragen pro Sekunde gemacht werden etc., evtl. schaust du das mal rein.

Vielen lieben Dank an euch drein !!!

Habe jetzt DB_Optimize Installiert und an das VMS 1.2 angepasst.

Und einmal laufen laufen lassen, laut den Forenbeiträgen, hätte ich mir es länger vorgestellt, ca. 2sek.

Siehe das, das hat es gebracht:

Vorher:
Datenbank: 80 Tabellen | Gesamt | 249,195 | MyISAM | latin1_german1_ci | 21,7 MiB | 1,6 MiB

Top10:

[tableold="head"]Tabelle | Größe | Überhang
vms_reloads_mail | 11,1 MiB | -
laendercode | 4,8 MiB | -
vms_gebuchte_werbung | 2,9 MiB | 758,1 KiB
vms_vcheck_codes | 1,0 MiB | 690,3 KiB
vms_reloads | 796,8 KiB | 130,0 KiB
vms_buchungen | 51,2 KiB | -
stg_bilanz | 250,4 KiB | -
stg_support | 64,2 KiB | -
vms_paidmails_empfaenger | 57,2 KiB | 6,3 KiB
vms_kontodaten | 27,2 KiB | -
[/tableold]

Nachher:
Datenbank: 80 Tabellen | Gesamt | 134,574 | MyISAM | latin1_german1_ci | 8,8 MiB | 80,1 KiB

Top10:

[tableold="head"]Tabelle | Größe | Überhang
laendercode | 4,8 MiB | -
vms_gebuchte_werbung | 1,9 MiB | -
vms_vcheck_codes | 555,0 KiB | -
vms_reloads_mail | 554,3 KiB | -
vms_buchungen | 175,5 KiB | 80,1 KiB
stg_bilanz | 254,8 KiB | -
vms_reloads | 197,2 KiB | -
stg_support | 59,9 KiB | -
vms_kontodaten | 22,3 KiB | -
vms_shoutbox | 23,3 | -
[/tableold]

Ich denke das sollte doch etwas ausmachen, werde es jetzt mal genau beobachten!

Wie es jpwfour schon vermutet hat, denke ich auch das der 500ter Fehler durch die größere Last zu Stande kommt, sonst müsste er ja theoretisch immer sein.

Hätte aber trotzdem noch einmal eine allgemeine Fragen dazu.

1. Welcher intervall wäre empfehlenswert um den Cron laufen zu lassen, täglich oder wöchentlich ?

Nochmals DANKE

Falk alias Siggi84

[SilentRunner]

den kannste doch täglich laufen lassen, nachts wenn nix los ist, frisst ja kein Brot

[WaechterMedia]

Wenn das mit dem 500 Fehler bleibt würde ich darüber nachdenken den host zu wechseln wenn es geht.

Ansonsten alle crons die nichts mit werbung zu tun haben in die morgen stunden schieben also so 1-5 Uhr da ist eigentlich nicht so viel los

[Siggi84]

Ich muss mich leider nochmal melden.

Habe jetzt einige User, bei denen die V-Check Statistik bei ganzen 0% liegt.

Kann es sein DB_optimizer da zuviel gelöscht hat?

Das die Banner etc. noch im Reloed sind und somit vom V-Check nicht vergütet werden.

Oder ist das gerade ein dummer Zufall?

db_query('DELETE*FROM*`vms_reloads_mail`*WHERE*bis *<*'.time());*

Wenn ich das richtig verstehe wird alles gelöscht, älter ist als "jetzt" !?

[Basell]

Dumme gesagt

Mal im Serverlasst mal geschaut?
Vielleicht ist der Server zu schwach

dann kommt 2 Leute Schnell drauf aber die anderen sind in der warteschleife und brauchen was länger beim laden oder es geht gar nicht

[Siggi84]

Dumme gesagt

Mal im Serverlasst mal geschaut?
Vielleicht ist der Server zu schwach

dann kommt 2 Leute Schnell drauf aber die anderen sind in der warteschleife und brauchen was länger beim laden oder es geht gar nicht

Hi, das ist ja das Problem, es ist kein eigener Server sondern "nur" ein Webspacepaket.

Da es eine reine "Klickseite" ist, macht das rein "Kostentechnisch" keinen Sinn, sonst hätte ich mir schon längst einen Server geholt.

du hast auch die vchecks bereinigt soweit ich es sehe da kann sowas passieren

An den V-Check Codes habe ich garnichts gemacht, ist im Cron nicht mit drin, kann jedoch sein das

db_query ("OPTIMIZE TABLE `".$table_name."`"); 

hier was verändert hat !? Da das ja im Cron mit inbegriffen ist !?

Das ist richtig, dazu gehört aber auch, das der Wert der gespeichert wird "bis" heist, sprich alles was älter als "jetzt" ist, ist auch schon veraltet .

Wie sieht der Cron denn genau bei dir aus? Evtl. wurden Einträge aus den V-Check Tabellen gelöscht.

Hier der komplette Cron!

$buchlimit = '10'; // Buchungen welche aelter als XX Tage sind, aus Datenbank loeschen.
 $inaktivlimit = '100'; // Wenn User laenger als XX Tage inaktiv ist, wird er mit Hinweis gesperrt (Wengier als 10 Tage nicht möglich!).
 $sperrhinweis = 'Account wegen inaktivität gesperrt! Bitte an den Support wenden!'; // Sperrhinweis bei Inaktivitaets-Sperrung!

 // Ungueltige Reload-Sperren loeschen
 db_query('DELETE FROM `vms_reloads` WHERE bis < '.time());
 db_query('DELETE FROM `vms_reloads_mail` WHERE bis < '.time());

   // Tabellenanzahl und IDs auslesen
   $result = mysql_list_tables($db_base);
   $menge = mysql_num_rows($result);
   for($x=0;$x<$menge;$x++){

     // Tabellennamen holen
     $table_name = mysql_tablename($result,$x);

     // Tabelle optimieren
     db_query ("OPTIMIZE TABLE `".$table_name."`");
   }

 // Zeit setzen
   db_query ("UPDATE ".$db_prefix."_crons SET laufzeit = '".time()."' WHERE bezeichnung = 'Datenbank optimieren'");

 // User, welche ueber 100 Tage inaktiv, sperren mit Hinweis
   if($inaktivlimit < 10) { $inaktivlimit = 10; }
   db_query ("UPDATE ".$db_prefix."_kontodaten SET status = 2, hinweis = '".$sperrhinweis."' WHERE last_active < ".(time()-($inaktivlimit*86400))." AND last_active > 0");

 // Buchungen loeschen aud DB, wenn diese aelter als xx Tage sind
   db_query ("DELETE FROM ".$db_prefix."_buchungen WHERE buchungszeit < ".(time()-($buchlimit*86400)));

    die('<font color="green">Cron erfolgreich gelaufen!</font>');
  ?> 

Hatte gestern den Usern auch mal einen NL geschickt, das es eine "Optimierung" gab und das sie doch bitte mal vorbei schauen sollten zum kurzen Speed Test, nur über die hälfte ist der Meinung das sich nichts verbessert hat.

Mir selbst ist zwar nichts aufgefallen das es lahm war, hatte aber gestern auch Weihnachtsfeier und konnte nicht ganz so viel beobachten.

Gibt es vielleicht noch eine Möglichkeit, die Seite zu beanspruchen um das mal "hier und jetzt" zu testen ?

Mit dem V-Check hat sich heute auch wieder gelegt, ist zwar heute auch noch nicht viel geklickt worden, aber ich stehe momentan bei ~86% gesamt.

Im Umgehrschluss ist es vielleicht auch logisch, wenn die Seite "hängt" das es mit dem Check nicht so positiv aussieht, da die "Rückmeldung" ja dann sicher auch hängt, oder ?

Möchte nochmal betonen, ihr seit Spitze, hier wird einen bei Problemen noch geholfen!

[jpwfour]

Der Cron ist so in Ordnung und sollte den V-Check nicht weiter beeinflussen, evtl wirklich nur Zufall, oder du hast (sofern du den VCheck Version 4 hast) ausversehen den vcheck_reset.php Cron ausgeführt?

...Speed Test, nur über die hälfte ist der Meinung das sich nichts verbessert hat.
...

Viel dürfte sich dadurch auch nicht verbessern, bei "grossen" Tabellen die viel Überhang haben, kann es natürlich sein, dass einzelne Anfragen etwas länger brauchen, aber normalerweise sollte das noch nicht so stark ins Gewicht fallen, sofern Indizes gut gesetzt sind.

Der nächste Schritt könnte sein, dass man versucht, die Anzahl der Anfragen generell zu minimieren, und schaut, ob es irgendwo "kritische" Anfragen gibt, Beispiele wären:
Anzeige der verbleibenden Klicks im Menü für jeden User
mehrfaches Auslesen der Userdaten für Anzeigen in den Menüs
eine schlecht programmierte Chatbox und/oder zu gerine Reload Zeit in der Chatbox
uvm.

Hast du die Bettelfunktion aktiviert und/oder deine Seite in Traffic/Besuchertausch etc eingetragen?
Dadurch entsteht auch sehr viel Last (und das unnötig, da man durch Traffic/Besuchertausch zu 99,9% nur Hits bekommt, aber nur 1 Anmeldung im Jahr ).

[WaechterMedia]

bezüglich last würde ich übers cachen nachdenken wenn es wirklich nicht am hoster liegt bin dir da auch gern behilflich ist eigentlich recht einfach wenn man nur bestimmte Segmente cachen will hat aber hallt den Nachteil das nicht immer alles hallt sofort sichtbar ist.

[Siggi84]

Der Cron ist so in Ordnung und sollte den V-Check nicht weiter beeinflussen, evtl wirklich nur Zufall, oder du hast (sofern du den VCheck Version 4 hast) ausversehen den vcheck_reset.php Cron ausgeführt?



Viel dürfte sich dadurch auch nicht verbessern, bei "grossen" Tabellen die viel Überhang haben, kann es natürlich sein, dass einzelne Anfragen etwas länger brauchen, aber normalerweise sollte das noch nicht so stark ins Gewicht fallen, sofern Indizes gut gesetzt sind.

Der nächste Schritt könnte sein, dass man versucht, die Anzahl der Anfragen generell zu minimieren, und schaut, ob es irgendwo "kritische" Anfragen gibt, Beispiele wären:
Anzeige der verbleibenden Klicks im Menü für jeden User
mehrfaches Auslesen der Userdaten für Anzeigen in den Menüs
eine schlecht programmierte Chatbox und/oder zu gerine Reload Zeit in der Chatbox
uvm.

Hast du die Bettelfunktion aktiviert und/oder deine Seite in Traffic/Besuchertausch etc eingetragen?
Dadurch entsteht auch sehr viel Last (und das unnötig, da man durch Traffic/Besuchertausch zu 99,9% nur Hits bekommt, aber nur 1 Anmeldung im Jahr ).

Zu den Anfragen:

Die verbleibenden Klicks werden "nur" auf den entsprechenden Seiten Sichtbar, klick4/textlink/etc...

Im Menü werden "nur", Kontostand/APs Heute/ APs Gesamt angezeigt.

Chatbox, da habe ich Maddin´s SB, da schreibt aber so gut wie keiner rein.

Bettelfunktion habe ich keine, war zwar geplant, aber momentan nicht.

Besuchertausch und Werbung habe ich aktuell keine, wollte ja das "Problemchen" nicht noch verschlimmern.

bezüglich last würde ich übers cachen nachdenken wenn es wirklich nicht am hoster liegt bin dir da auch gern behilflich ist eigentlich recht einfach wenn man nur bestimmte Segmente cachen will hat aber hallt den Nachteil das nicht immer alles hallt sofort sichtbar ist.

Was meinst du genau unter "cachen" ?

Edit:
Was mir aber gerade aufgefallen ist, die SB hat sich alle 5sek aktualisiert, denke hier könnten wir das Problemchen schon haben, oder ???
In der Einstellung stand Reload, ich bin davon ausgegangen das ist die Zeit wann ein User wieder schreiben kann und nicht wenn die SB sich aktualisiert. Wären alle 5sek - 200 Einträge, von der Datenmenge zwar nicht viel, aber viele Zeichen.

[WaechterMedia]

Ich muss mich leider nochmal melden.

Habe jetzt einige User, bei denen die V-Check Statistik bei ganzen 0% liegt.

Kann es sein DB_optimizer da zuviel gelöscht hat?

Das die Banner etc. noch im Reloed sind und somit vom V-Check nicht vergütet werden.

Oder ist das gerade ein dummer Zufall?



Wenn ich das richtig verstehe wird alles gelöscht, älter ist als "jetzt" !?

du hast auch die vchecks bereinigt soweit ich es sehe da kann sowas passieren