Heu­te wird es sehr tech­nisch – aber wofür sind Feri­en denn da… Ich hat­te ein­mal meh­re­re Mood­le­sys­te­me hin­ter einem Rever­se Pro­xy lau­fen – das wird den meis­ten nicht viel sagen, daher eine kur­ze Erklärung.

Das Pro­blem

Mood­le ist extremst resour­cen­hung­rig und kann unter hoher Last einen schlecht kon­fi­gu­rier­ten Web­ser­ver in die Knie zwin­gen, beson­ders auf schwach­brüs­ti­gen Maschi­nen (die man pri­vat so finan­zie­ren kann). Da liegt dar­an, das für Mood­le vom Web­ser­ver ein soge­nann­ter PHP-Inter­pre­ter auf­ge­ru­fen wer­den muss, der dann aus zahl­rei­chen Script­vor­ga­ben eine stink­nor­ma­le HTML-Sei­te baut und über den Web­ser­ver an den Brow­ser des Benut­zers aus­lie­fert. Erschwe­rend kommt hin­zu, dass die Scrip­ten von Mood­le zusätz­lich vie­le Daten­bank­ab­fra­gen erzeu­gen und so durch den erfor­der­li­chen Daten­bank­ser­ver (meist MyS­QL) Last erzeu­gen. Ein gut kon­fi­gu­rier­ter Mood­le­ser­ver wird also dafür sor­gen, dass mög­lichst wenig Last beim PHP-Inter­pre­ter und bei der MyS­QL-Daten­bank ankommt – man sagt: Das Backend (PHP&MySQL) muss „geschützt“ werden.

Rever­se Pro­xy als Lösung

Dafür führt kein Weg an einem Rever­se Pro­xy vor­bei. Was macht die­ser genau? Der PHP-Inter­pre­ter und die Daten­bank bau­en ja eine stink­nor­ma­le HTML-Sei­te zusam­men – das kann z.B. die Start­sei­te eines Mood­le­kur­ses sein. Immer wenn der glei­che Nut­zer die glei­che Sei­te auf­ruft, muss die­se wie­der und wie­der gebaut wer­den. Ein Rever­se Pro­xy spei­chert die­se Sei­te im HTML-Code zwi­schen und lie­fert sie bei zwei­ten Auf­ruf direkt an den Brow­ser ohne den Web­ser­ver, den PHP-Inter­pre­ter oder die MyS­QL-Daten­bank zu bemü­hen. Ein Rever­se Pro­xy ist sehr schlank und braucht nur weni­ge Resour­cen. Selbst wenn ein Opcode-Cache wie eac­ce­le­ra­tor oder xcache die PHP-Sei­te direkt bedie­nen kann, sind vor­her zwei Instan­zen mit viel höhe­rem RAM-Ver­brauch betei­ligt (bei Apa­che ein kom­plet­ter Thread, bei ligh­ty der Web­ser­ver­pro­zess und ein fast­C­GI-Thread) – das ist in Last­si­tua­tio­nen nach mei­ner Erfah­rung immer sub­op­ti­ma­ler als gleich per Pro­xy aus­zu­lie­fern. Der Opcode-Cache ist trotz­dem eine wich­ti­ge zusätz­li­che Vor­keh­rung.  Der Rever­se Pro­xy löst gera­de bei meh­re­ren Mood­lein­stan­zen auf dem glei­chen Ser­ver noch eini­ge  wei­te­re Pro­ble­me, aber dazu wei­ter unten mehr.

Wei­ter­le­sen