Quali criteri dovrei usare per valutare un "server delle app" Perl (sostituzione mod_perl)?

Question

Breve versione:

Quali criteri devo usare per valutare possibili candidati per un "application server" Perl (mod_perl sostituzione)?

Siamo alla ricerca di una sorta di quadro che permetterà l'esecuzione di vari programmi Perl più volte (come servizio) senza i costi di:

1. ri-Launcing interprete Perl una volta per ogni esecuzione

2. carico/compilazione moduli Perl volta per ogni esecuzione

(entrambi i quali sono i vantaggi che mod_ esecuzione perl fornisce)

Note:

• Non molta cura su eventuali benefici supplementari offerte dal mod_perl troppo, come l'integrazione profonda Apache.

• Questo sarà un server di app puro, il che significa che non è necessaria alcuna funzionalità specifica per il Web (non è un problema se il server dell'applicazione lo fornisce, semplicemente non sarà necessario).

• Considereremo ovviamente i criteri ovvi (velocità raw, stabilità pronta per la produzione, sviluppo attivo, capacità di funzionare su sistemi operativi a cui teniamo). Quello che mi interessa sono le cose meno banali e sottili che potremmo desiderare da un tale framework/server.

Background:

A $ lavoro, i poteri che essere deciso che vogliono sostituire una situazione attuale (semplici webapps in fase di sviluppo in Embperl e distribuito tramite Apache/mod_perl).

La decisione è stata presa per utilizzare un sistema MVC (di produzione locale) che avrà un front-end Java Spring per la vista; e il controllore analizzerà le richieste di servizi di back-end ai servizi per app che eseguono i doveri del modello (non rimanere impigliato nei dettagli di questo - non è molto pertinente alla domanda principale).

Una delle opzioni per i servizi di back-end è Perl, in modo da poter sfruttare tutto il nostro IP Perl esistente (librerie, codice back-end dell'app Web) andando avanti e non dover trasferire il 100% di esso su Java.

In sintesi:

| View | Model/app | Model loaded/executed by:       | 
================================================================================ 
OLD | Empberl | Model.pm | mod_perl has Model.pm loaded, called from view.epl | 
NEW | Java | Model.pm | perl generic_model.pl -model Model (does "require") | 
================================================================================ 

Ora, quelli di voi che ha fatto lo sviluppo Web Perl per un po ', si nota subito il problema più evidente con il nuovo design:

| Perl interpreter starts | Perl modules are loaded and compiled | 
======================================================================= 
OLD | Once per mod_perl thread | Once per mod_perl thread 
NEW | Once per EVERY! request | Once per EVERY! request    | 
======================================================================= 

In altre parole , nel nuovo modello, abbiamo non abbiamo più alcun vantaggio sulle prestazioni offerto da mod_perl come contenitore persistente dell'app lato server !!!

Pertanto, stiamo esaminando i possibili contenitori di app per offrire la stessa funzione.

(come nota a margine, sì, abbiamo pensato di eseguire semplicemente un'istanza di Apache con mod_perl come contenitore di un'app, come possibilità valida.Tuttavia, poiché la funzionalità web non è richiesta, mi piacerebbe vedere se qualsiasi altra opzione può essere adatta alla fattura).

Answer 1

Penso che tu abbia già identificato ciò che hai bisogno di sapere e cosa testare: tempo di esecuzione contro memoria. È inoltre necessario valutare la flessibilità e la facilità di implementazione che si ottiene con mod_perl e il grande vantaggio di preservare l'utilità del software che hai già sviluppato (e l'esperienza accumulata dal tuo staff). Ricorda che puoi separare facilmente i servizi da CPU e macchina se il tuo nuovo front-end parlerà con le tue applicazioni all'interno della tua rete. Molto dipende da come "web-ish" puoi rendere i tuoi servizi e se possono essere "demonizzati" in modo efficiente. Naturalmente ci sono molti modi per i web front-end per parlare con altri servizi e perl può gestire praticamente tutti ... TIMTOWTDI.

Dal momento che si parla di "tuits" (cioè "manodopera") come un vincolo, forse il miglior approccio a breve termine è quello di istituire un separato apache - mod_perl esempio come un "contenitore di applicazioni" ed eseguire le applicazioni in questo modo (visto che corrono bene in quel modo già, è corretto?). Dopotutto, lo apache (e lo mod_perl) sono ben noti, testati in battaglia, ed eminentemente modificabili e configurabili. Le opzioni di implementazione sono piuttosto flessibili (stessa macchina, diverse macchine, failover, bilanciamento del carico, cloud, locale, VM) e sono state ben testate.

Una volta avviato, è possibile iniziare a sperimentare vari approcci "a bassa manodopera" per demonizzare magicamente le applicazioni e i servizi senza apache. Plack e Starman sono stati menzionati, Mojolicious:: è un altro framework che è in grado di funzionare con JSON Websockets, ecc. (E Plack). Anche questi sono stati ben testati, ma forse sono meno familiari di mod_perl e Apache. Tuttavia, se sei un negozio perl non dovresti avere difficoltà a lavorare con questi strumenti "moderni". Un giorno, se finisci per avere più risorse, potresti costruire una sofisticata piattaforma di rete per tutti i tuoi servizi basati su Perl e utilizzare tutte le fantastiche cose "nuove" (o almeno più nuove di mod_perl) su CPAN come POE, Plack, ecc. Potresti divertirti un sacco a sviluppare cose interessanti mentre risolvi il tuo problema aziendale.

Per chiarire il mio precedente commento: Ubic (vedi Ubic su MetaCPAN) possono demonizzare (e quindi precompilare) vostri perl strumenti e offre alcuni mezzi di sorveglianza e di gestione che vengono gratuitamente con il quadro. È disponibile un modulo Ubic progettato per l'uso con Plack chiamato Ubic::Service::Plack. Di per sé Ubic non fornisce una soluzione facile per la tua nuova applicazione Java/Swing per comunicare con le tue applicazioni perl, ma potrebbe aiutare a gestire/monitorare qualsiasi soluzione tu possa inventare.

Buona fortuna e buon divertimento!

Answer 2

Starman è un server Web di prefrezione/PSI di prefissazione ad alte prestazioni che può essere utilizzato in tale contesto. È facile creare un'applicazione REST che serva oggetti JSON stateless (questo è un caso d'uso semplice).

Starman è un server pronto per la produzione ed è veramente facile da installare una serie di istanze Starman dietro uno scopi reverse proxy (this SO question may helps you), per il ridimensionamento

Answer 3

È possibile creare un demone semplice utilizzando HTTP::Daemon, e hanno tutti i vantaggi di compilare in seguito le parti necessarie del codice (require) o in anticipo, prima dell'avvio del daemon.