Beiträge von ice-breaker

Welche SOAP-Library du verwendest könnte da auch noch interessant sein
Ext/Soap? Eine PHP-Implementation?

Zitat von killerbees19;30407

Aber kannst du diese Aussagen auch irgendwie belegen, was daran so schlecht ist? Denn irgendwie kann ich das so allgemein nicht im Raum stehen lassen

Es wird einfach auf den x Jahre alten Vorurteilen herumgeritten, dass Java 1.2 und 1.3 wirklich grotten langsam war.

Zitat von ferrarajunior;29972

Was das palaber mit den Tickrate > Fps oder wie das sein soll kapier ich ned.

merkt man

Zitat von ferrarajunior;29972

Tick = Pakete Pro Zeit

1 Tick = 1 Ausführung der Logik auf dem Server, kein Pakete senden

Zitat von ferrarajunior;29972

100er Tick = 100Pakete in 1000ms also alle 10ms ein Paket
33er Tick = 33Pakete in 1s(1000ms) alle 33ms ein Paket
Je mehr FPS ein Server hat desto mehr Power hat er Ereignisse Vorzurechnen.

33 Ticks bedeutet also, dass der Server alle 30.3 Millisekunden den Zustand der "Welt" neu berechnet. Also wer sich wohin bewegt hat usw

Zitat von ferrarajunior;29972

Bsp. Spieler schießt, läd nach, geht rechts.
Das rechnet er vor und nicht erst bei eintreffen des Ereignisses.

nein, der Server rechnet nicht vor, dass der Spieler schießt oder nach rechts geht
Einzig und alleine wenn du angefangen hast zu Laufen kann Server im Zuge der "Lag Prevention" vorberechnen, dass du sich seit deinem letzten Paket noch ein Stückchen weiter bewegt hast, das macht er aber auch nur, wenn du wirklich mit dem Laufen schon begonnen hast.
Du kannst gerne nachlesen wie das funktioniert.

Zitat von ferrarajunior;29972

Also wenn ich am PC SCHIEßEN drück, dann hat der Server das schon "vorgerechnet" ....

da liegst du absolut falsch :eek:

Zitat von ferrarajunior;29972

Beim Tick spielen auch interp. die Fps des Clients usw usw eine Rolle.

tun sie nicht.
Wenn du also FPS 50 hast, bedeutet das auch nur dass dein Client die aktuelle Welt die er zu jedem Frame kennt 50 mal pro Sekunde auf deinen Bildschirm malen kann, nichts anderes bedeutet Frames per Second.

Zitat von ferrarajunior;29972

Es gilt Fps sollte > Tick beim CLIENT !
Sollte auch klar sein ... bei 60 Fps ist der "Tick" auch nur 60 also der von Server zu Client (Lowrate)

FPS und Ticks sind absolut unabhängig

Viel geschrieben und genauso viel falsch, eigentlich nichtmal eine wahre Aussage im Text.

Zitat von Steinle92;29850

Ich habe es bereits mit Zend Framework versucht, aber das hat auf meinem Webserver nicht funktioniert...

Zend Framework ist ein Framework, und weit mehr als eine Template-Engine, wenn du die Fehler postest, kann mir da da auch helfen.

Ansonsten:
PHP ist an sich schon eine wunderbare Template-Engine, wenn man Logik und Ausgabe trennt erreicht man auch mit PHP schöne Templates.

Zitat von vmk;29502

Aber was passiert wenn der sshd-Prozeß sich irgendwann mal beendet?

dann hat man größere Probleme, als ein Game-Server der sich beendet

Was hat die Bandbreite damit zu tun, wenn dein vServer scheinbar vollkommen ausgelastet war?

Zitat von chitypo;29364

nu schau doch mal nach den rechten.

jup, da ihm die Namen egal sind und scheinbar auch die Definition bleiben nur die Rechte.

CREATE TABLE a (
  b int(11) NOT NULL AUTO_INCREMENT,
  PRIMARY KEY (b)
) ENGINE=MyISAM;

Was passiert dabei ?

Ok, das ist noch mysteriöser.
Ein #1005 kann zwar kommen wenn beim Erstellen der Tabelle die Foreign Key Relation nicht stimmt, aber er erstellt ja keine InnoDB-Tabelle.
Ich würde vermuten, dass InnoDB in dem Link angegeben ist, weil es die häufigste Fehlerursache ist.

Ich kann mich aber an ein Problem aus dem 4er und frühen 5er MySQL erinnern, als bestimmte Tabellennamen nicht funktionierten, da ein Fehler im überprüfen der Tabellennamen mit reservierten Keywords war.

@killer: was passiert wenn du die Tabelle anders bennenst? a? foobar? test?

Wieso InnoDB wenn er eine MyISAM Tabelle anlegen will ?

der Gutschein gilt nur für die v(olks)server-Reihe

Zitat von killerbees19;29156

Ohne das Thema jetzt unnötig zu pushen, aber bei meinem MySQL Problem vor einem Jahr war es ähnlich. Dann gab es ein Kernel Update und alles lief wieder.

ah stimmt, ich erinner mich
Du hattest mich dadurch erst auf die Idee gebracht, dass es genau der gleiche Grund sein könnte, warum mein Java (Problem von damals) auf einmal ohne jegliche Probleme lief.

Zitat von killerbees19;29156

Eine bestimmte Inkompatibilität mit einigen Kernel Versionen und bestimmten Softwareprodukten oder Systemaufrufen könnte ich mir also auch durchaus vorstellen.

das ist ausgeschlossen, auf hunderten Servern läuft alles ohne Probleme.
(tut mir leid, konnte ich mir nicht verkneifen das man einmal nicht für den absolut dummen gehalten wird ist angenehm *kiss*)

Zitat von killerbees19;29156

Interessant wären trotzdem die Versionen der verwendeten Programme und die Kernel Version auf deinem vServer. Oder in deinem Fall - wenn du den Webserver selbst geschrieben hast - welche speziellen Systemaufrufe du verwendest. Daten über deine Systemauslastung wären auch interessant. Außerdem solltest du beachten, dass sehr viele Programme immer etwas von der Festplatte lesen oder darauf schreiben, das könnte im Zusammenhang mit dem Scheduling dann zu Verzögerungen führen, wenn nicht genügend Ressourcen vorhanden sind.

Kernel: 2.6.35.8-vs2.3.0.36.33
Java-Version: 1.6.0_22 (aktuellste Debianversion)
Systemauslastung: kompletter Host absolut idle (3%)
Ramauslastung: 36/500MB belegt
Festplattenzugriffe: ausgeschlossen, mein eigener Test-Webserver operierte rein im Ram.

ich will da auch nicht drauf rumreiten, Netcup kann sich die Daten notieren, wenn sie wollen, falls noch mehr irgendwann das Problem vermelden sollten, aber mir ist es schnuppe

Verzögerung wird gemessen von dem Beginn der HTTP-Anfrage (Socket öffnen) bis alle Daten da sind (Response da).

Genaue Messwerte habe ich jetzt nicht mehr hier stehen, die Messreihe ist schon zu alt, es bewegt sich im Bereich um die 2 Sekunden, wurde das erste Mal der Webserver von irgendeinem PC aufgerufen funktioniert auch der Aufruf von einem anderen PC innerhalb von wenigen Millisekunden, also es hat nichts mit dem eigentlichen starten einer Socket-Verbindung zu tun, sonst müsste jeder PC die 2 Sekunden Verzögerung haben.

Den genauen Grund zu finden ist eben schwer, denn wenn von irgendeinem PC einmal die 2 Sekunden gewartet wurden funktioniert alles wieder wie es sollte und es dauert wieder lange bis man einen erneuten Test durchführen kann, es hat eben haargenau die Swapping-Merkmale nur dass ich in meinem vServer kein Swapping habe, daher kam eben die nicht begründbare Idee des Swappings auf dem Hostsystem, beweisen kann ich es natürlich nicht, ich wüsste auch nicht warum es so sein sollte, es ist nur eben die einzige Erklärung, die ich habe, die genau zu dem Verhalten passt.

Zitat von [netcup] Felix;29152

Wenn Sie einen Webserver programmieren können, sollten Sie doch auch in der Lage sein den Fehler der Verzögerung zu finden, oder nicht?

leider nein, ich sehe in meinem Webserver, dass das rendern nur einen Bruchteil der Wartezeit benötigt (gemessen von eingehender Socket-Verbindung bis Ende) - nur so lange wie auch jeder der weiteren Zugriffe benötigt - es passiert also irgendwo transparent.

Zitat von [netcup] Felix;29152

Fakt ist, wir haben über 3500 vServer in Betrieb. Auf fast jedem rennt ein gängiger Webserver wie Apache, ohne das uns Probleme gemeldet werden. Zu dem haben wir selber etliche vServer in unserer Verwaltung.

natürlich, ich will da auch niemandem einen Strick drehen, aber wie es eben so ist gibt es ja Probleme, die nur unter bestimmten Vorraussetzungen auftreten und dann kommt eben noch dazu, dass ich das Problem auch nur feststellen kann, wenn auf den Webserver lange nicht zugegriffen wurde.

Zitat von [netcup] Felix;29152

Das man seine persönlichen Probleme dann auf die Virtualisierung schiebt und man hier zu lesen bekommt "hade, dass Netcup das Problem nicht in den Griff bekommt", halte ich nicht für richtig.

wie gesagt will ich nicht sagen, dass es ein Problem eurer Virtualisierung ist und ihr das beheben sollt, ich habe es ja auch nie gemeldet, es ist mir eben egal, es wird also aus diesem Grund nur als Entwicklungssystem genutzt.
Ich sagte eben nur, dass es für mich am wahrscheinlichsten scheint, dass es das Host-System ist, weil es eben genau die Merkmale eines Swapping aufweist, ohne dass mein vServer meldet, dass er swappt und er auch nicht swappen dürfte (400MB Ram frei).

Zitat von [netcup] Felix;29152

Eventuell lag es an dem Zusammenspiel des eingesetzten Kernels und Ihrer Software. Da der Kernel vorgegeben ist, können Sie in dem Fall nur Ihre Software korrigieren. Java lief bislang auf jedem Kernel den wir eingesetzt haben, sprich es lag kein wesentliches Problem im Kernel vor.

das was ich an Java-Software getestet hatte waren voll ausgereifte Java-Anwendungen (Jetty, Tomcat, Hudson) usw, selbst ein Java-Prozess der nur alle 60 Sekunden eine Meldung ausgab verschwand einfach, das liegt dann denke ich eher weniger an der eigenen Software oder? (zumal ich diese Minimalsoftware auch auf dutzenden anderen Systemen ohne Probleme mehrere Tage laufen ließ)
Es gab keine Crashlogs, kein nichts gab, der Prozess verschwand einfach.
Da man bei solchen Problemen vom Support eben nur hört, dass man selbst Schuld ist - was sicherlich auf 99% der Probleme zutrifft - habe ich eben auch keine Mühe unternommen das Problem zu melden, die Antwort hätte ich ja eh gekannt.
Da nach dem genannten Neustart bzw. Kernel-Update haargenau die gleiche Software unter immernoch einem unveränderten System ohne jegliche Probleme dann für Monate lief, sah ich mich eben sehr bestätigt in meiner Vermutung, dass es einfach ein Problem zwischen dem Kernel und Java war.

Wie gesagt, mir ist das Problem aber eben auch egal, ich nutze aus diesem Grunde meinen vServer nur als Entwicklungssystem, ich wollte eben dem Threadersteller nur sagen, dass er nicht der einzige ist, der das Problem hat und ich auch bei mir Apache ausschließen konnte und viele weitere potentielle Probleme

das ist eben leider nicht feststellbar.
Das war der Grund warum ich es eben auf die Virtualisierung schob* (wobei ich auch nicht wüsste wieso), es tritt aber eben nur das erste Mal auf, wenn der Dienst länger nicht genutzt wurde.
Der vServer swapped jedoch zu keinster Zeit (90% des Rams frei), es ist wie als ob der Host den Prozess swappen würde, was ich mir aber eben nicht vorstellen kann, jedoch auch nicht ausschließen würde, denn eigentlich hätte er ja denke ich keinen Grund dafür.

* wie mein Problem mit einfach verschwindenden Java-Prozessen (ohne dass sie abstürzten usw) welches niemand nachvollziehen konnte, nach einem Neustart des Host-Systems oder Kernel-Update - eines von beiden - einige Wochen später aber nie wieder auftrat.

Hallo Felix,
ja ich weiß genau, was du meinst und dummerweise ist es eben mal nicht einer der gängigen Problemursachen, zumindest mein Webserver den ich testweise geschrieben habe läuft dauerhaft im Ram und greift auf keinerlei externe Ressourcen zu (Festplatte, Webservices).

Aber wie gesagt, ich kann mich damit abfinden, es ist nur ein Entwicklungssystem.

Zitat von Proyx;29114

Wenn es ihr nicht seid, ist es immer der Anbieter, bekennt euch doch mal selber für schuldig!

Nein natürlich nicht, aber das ist wie mein Problem damals, dass nach einigen Stunden bei mir immer Java-Applikationen einfach verschwunden sind, nach einem Kernel-Update war auf einmal alles wieder normal...

Neija wie gesagt habe ich eben 3 verschiedene Lösungen am laufen, davon auch selbstgeschriebene, die weder PHP benötigen, noch auf externe Zugreifen usw.

aber ist mir auch egal, ich habe das Problem nun einfach gelöst indem ein Cronjob alle 60 Sekunden einen Request auf den Webserver macht.

habe ich auch mit allen Webservern bei mir auf dem vServer, sowohl lighttpd als auch Jetty, ich schiebe es mittlerweile auf irgendeine Nebenwirkung der Virtualisierung.

Zitat von AkiGo;28785

Teamspeak ist sehr sicherer geworden, leider bin ich mir sicher, das bald wieder ein weg zum Hacken frei wird.

äh, ja ...

Zitat von [netcup] Felix;28401

Eine stündliche Abrechnung halten wir für "Abzocke" (wenn dieses natürlich mehrere Kunden wünschen, können wir auch solche Tarife anbieten (für entsprechendes Geld ist alles möglich)).

Da ich größtenteils mein Cloud-Server bei einem großen Bücherversender flexibel nur für einige Stunden starte, wenn mehr Berechnungen durchzuführen sind, denke ich wird das schon einige interessieren.

Zumal es das ist, was auch momentan als der Cloud-Begriff verstanden wird (oh Gott, er hat es wieder aufgegriffen): ich kann mir jederzeit einen solchen Server buchen und wieder abschalten und zahle auch nur für die Zeit, die ich genutzt habe. Dementsprechend muss ich mich dem Tenor anschließen, dass ich die momentane Lösung auch nur als vServer mit dynamisch wechselbaren Tarifoptionen sehe.

Zitat von [netcup] Felix;28346

Wird der Wechsel genau auf den Tag gelegt, zu dem die nächste Abrechnung geschieht, zahlt man als Kunde am wenigsten.

auf gut deutsch ich buche dauerhaft den teuersten Cloud-Server und ändere in 2 Tage vor der nächsten wieder schnell auf den Billigsten um viel günstiger wegzukommen?
Sind monatliche Beträge für Cloud-Server wirklich üblich? ich habe das ehrlich gesagt noch nie gesehen, bisher immer nur stündliche Abrechnung.