Come posso migliorare le prestazioni di Moose nei processi CGI non persistenti?

Question

Moose è un fantastico framework di oggetti. Il problema è che, preso insieme alle sue dipendenze, è molto grande. La nostra profilazione indica che sulla nostra piattaforma, il semplice caricamento di Moose comporterà un sovraccarico di 5-6 secondi sugli script dell'applicazione CGI non persistenti. Questo non è accettabile per queste applicazioni una tantum.

Al contrario, quando stiamo usando un sistema di processo persistente (come FCGI), questo overhead di avvio viene eliminato (o meglio, sostenuto solo una volta), e tutto va bene. Il problema che abbiamo è che non possiamo garantire che tutto il nostro codice verrà sempre eseguito con un processo persistente.

Abbiamo esaminato usando Mouse come rimpiazzo con funzionalità limitate per Moose , ma come risulta (come menzionato in questa risposta ) non è un'opzione praticabile. Qualsiasi libreria che scriviamo per lavorare con Moose non funzionerà con Mouse in modi sottili ma importanti. E davvero non vogliamo fare il fork di tutti i nostri moduli in modo da poter supportare sia Moose in un ambiente persistente sia Mouse per " vanilla " CGI.

Detto questo, abbiamo le seguenti opzioni:

1. Fork i nostri moduli interni per lavorare con Moose o Mouse, a seconda dei casi. (Yuck!)
2. Sviluppa i nostri moduli solo per FCGI / Moose . Non supportare " vaniglia " CGI più. Se dobbiamo scrivere script che non sono persistenti, non saranno in grado di sfruttare i nostri moduli interni.
3. Non utilizzare Moose o Mouse , ma qualche altro framework di oggetti.

Quale opzione è la migliore? Ci stiamo avvicinando a 2 in questo momento, e lo faremo solo succhiare se dovessimo far funzionare qualcosa come un CGI alla vaniglia. Che ne dici di altri framework? C'è qualcosa di più leggero che dovremmo guardare?

Answer 1

La mia preferenza sarebbe quella di eliminare il supporto CGI alla vaniglia. L'hosting FCGI è davvero economico in questi giorni e non c'è motivo di assecondare il CGI (IMO) alla vaniglia perché rinforza semplicemente l'opinione che il Perl sia lento. Ma se non puoi evitarlo, puoi usare qualcosa come Object :: Tiny . Ma se hai bisogno di ruoli, vincoli, meta-programmazione e tutte le altre bellezze che offre Moose, sei sfortunato a meno che non lasci cadere CGI alla vaniglia.

Answer 2

È possibile scrivere un'applicazione server back-end utilizzando Moose e quindi scrivere script CGI molto piccoli e semplici che interrogano il back-end.

+-------+    +--------------+
| Small |===>|  Persistent  |
|  CGI  |<===| Moose Server |
+-------+  ^  +--------------+
           |
         Socket
       Connection

Questo è più o meno ciò che fa FCGI, quindi potrebbe avere più senso usare solo FCGI.

D'altra parte, potrebbero esserci dei reali vantaggi nell'avere un server back-end non cgi che può avere QUALSIASI interfaccia astratta avvitata secondo necessità.

Ad esempio, se si utilizzano socket TCP (o UDP), è possibile che un'applicazione desktop nativa colpisca lo stesso back-end del CGI.

Qual è la soluzione migliore nel tuo caso dipende davvero dalla tua situazione specifica. A seconda dei dettagli della situazione, posso vedere me stesso decidere di utilizzare questo approccio o uno qualsiasi degli approcci descritti sopra.

Answer 3

Il mio suggerimento è di andare con l'opzione # 2 e quindi aiutarci a refactoring Moose in modo che CGI diventi praticabile. fREW sta attualmente lavorando sulla suite di test Moose al fine di abilitare il progetto MooseX :: Antlers che dovrebbe ridurre la maggior parte delle spese generali, il che significa che Moose è inutilizzabile per un ambiente CGI.

Matt Trout (mst), l'uomo attualmente dietro MooseX :: Antlers, ha espresso il desiderio di poter eseguire app in un ambiente CGI se necessario. Suggerirei di restare con FCGI per ora e di assillarlo per quello che puoi fare per dare una mano!

Answer 4

Jonathan Rockway ha scritto di APP :: Peristent (che, stranamente , non è in CPAN) alcuni mesi fa. Non l'ho usato, ma in base al suo post sul blog sopra linkato, sembra fornire un'architettura server-client abbastanza trasparente in cui è possibile concludere l'elaborazione effettiva del CGI.

Answer 5

L'idea di base di App :: Persistent , pperl , SpeedyCGI e probabilmente alcuni altri è che il processo di compilazione del programma Perl in codice byte viene eseguito solo una volta e successivamente viene utilizzata una sorta di memorizzazione nella cache sulle invocazioni. Poiché si dice che Moose abbia una penalità in fase di compilazione, proverei prima questo approccio.

Ho usato con successo pperl per disegnare molti grafici MRTG su un sistema antico intorno al 2001. Il programma Perl è stato eseguito per ogni grafico che era piuttosto un overhead - questo probabilmente paragonabile al tuo scenario CGI.

Answer 6

Esiste anche un'altra opzione: PPerl .

Non l'ho mai usato, ma sembra decisamente interessante. E la persona che l'ha scritto (Matt Sergeant aka baud) - ti dà praticamente la garanzia di un codice di buona qualità.