Ich entwickle eine Rails 2.3, Ruby 1.9.1 Webapplikation, die vor jeder Anfrage eine Menge Berechnungen durchführt. Für jede Anfrage muss ein Graph mit 300 Knoten und ~ 1000 Kanten berechnet werden. Der Graph und alle seine Knoten, Kanten und anderen Objekte werden für jede Anfrage initialisiert (~ 2000 Objekte) - tatsächlich werden sie aus einem unberechneten Cachegraphen mit Marshal.load (Marshal.dump ()) geklont.
Leistung ist hier ein großes Problem. Im Moment dauert die gesamte Anfrage durchschnittlich 150ms. Ich sah dann, dass während einer Anfrage Teile der Berechnung nach dem Zufallsprinzip länger dauern. Unter der Annahme, dass dies der GarbageCollector sein könnte, habe ich die Anfrage in GC.disable und GC.enable verpackt, so dass die Anfrage mit dem Müllsammeln wartet, bis das Berechnen und Rendern beendet ist.
%Vor%Die durchschnittliche Anforderung dauert jetzt etwa 100 ms (50 ms weniger).
Aber ich bin mir nicht sicher, ob das eine gute / stabile Lösung ist, ich nehme an, dass es Nachteile haben muss. Hat jemand Erfahrung mit einem ähnlichen Problem oder sieht er Probleme mit dem obigen Code?
Wenn es Ihre App schneller macht, dann verwenden Sie es.
Ich würde eine ensure -Anweisung hinzufügen, so dass, wenn irgendeine Ausnahme ausgelöst wird, Sie nicht mit deaktivierter Garbage Collection enden.
Keine wirklichen Nachteile, außer dass die erneute Aktivierung des GC länger dauern wird.
Es gibt eine Reihe von Artikeln im Internet über den Ruby's GC. Sieh sie dir an und vielleicht kannst du diese Zeilen entfernen. =)
Sie können die Ergebnisse nicht zwischenspeichern und alle paar Minuten im Hintergrund wiederholen.
Es sieht vielleicht blöd aus, aber in diesem Fall werde ich versuchen, eine C-Funktion von Ihrer ROR aufzurufen. Diese Lösung ist ziemlich hardcore, aber es sollte erstaunliche Performance-Ergebnisse geben;)
Ihre Lösung mit Rubin ist keine lange thermische Lösung, sondern nur eine Lösung ...
Tags und Links ruby ruby-on-rails garbage-collection