Performance dell’application server. L’Application Server deve poter eseguire un numero maggiore di 1 di Java Virtual Machines all’interno di una sua singola istanza, spalmando il costo del meccanismo di Garbage Collection su più processi. Deve fornire: ❑ supporto al multi-threading usando threads del sistema operativo sottostante (Native Threads), consentendo al server di operare internamente in modo asincrono minimizzando la probabilità di un’applicazione in attesa di risposta. Inoltre l’amministratore del sistema deve poter impostare il numero di threads in grado di gestire le richieste (sia dei client sia sul database) ❑ supporto di architetture multi processore ❑ Multithreading ❑ Dynamic Load Balancing ❑ Database Connection Pooling ❑ Result Caching ❑ Data Streaming: intendendo la capacità dell’application server di restituire i risultati di una transazione al cliente man mano che essi vengono generati, senza dover aspettare il completamento di tutti i processi del server ❑ EJB Stateless and Stateful Session pooling ❑ Stateful session bean non devono essere attivati/passivati via database ❑ comunicazioni ottimizzate con i Web servers NSAPI, ISAPI, APACHE (variante di NSAPI ) e CGI ❑ le lookup JNDI per un componente registrato non devono effettuare chiamate ad un DB Server Deve essere possibile: ❑ impostare il numero minimo e massimo di server Java ❑ incrementare il numero di connessioni ridirigibili dal plug-in al server esecutivo. La gestione della persistenza della sessione in un cluster deve essere realizzata tramite meccanismi di in-memory replication e non via JDBC. Il directory server integrato non deve svolgere funzioni di gateway verso un database relazionale, mostrando un decadimento delle performance nel mapping di chiamate LDAP verso chiamate SQL.
