Breve versione:Quali criteri dovrei usare per valutare un "server delle app" Perl (sostituzione mod_perl)?
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:
ri-Launcing interprete Perl una volta per ogni esecuzione
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).
Quale protocollo verrà utilizzato per comunicare tra loro le parti java e perl? – innaM
Ma non riesci a mantenere il "parallelismo" di uno start semplicemente continuando a eseguire i servizi in un ambiente '' 'apache mod_perl'' (o PSGI) e parlando con loro dal tuo nuovo thingie di Java Swing? È troppo lento? Almeno l'interprete '' 'perl''' è in esecuzione, in attesa e pronto. –
Mi spiace intendevo il mio commento precedente come ulteriore domanda/risposta riguardante la nota a margine. Hai testato questo approccio al contenitore di app '' 'mod_perl'''? Sembra che www.apache.org abbia eseguito o eseguito '' 'Qpsmtpd''' per aiutare a gestire la consegna della loro lista di distribuzione in questo modo (** cioè ** incorporato come servizio SMTP in un'istanza di' '' mod_perl'' apache). Quindi '' 'apache''' e' '' mod_perl''' ... "non sono solo per il web" :-) –