Italian:

Da oggi è disponibile su sourceforge all’indirizzo https://sourceforge.net/projects/ftpsitedeployer/ il nuovo plugin FTP per NetBeans “FtpSiteDeployer”.

Permette agli sviluppatori che si occupano di applicazioni web scritte in Java di inviare agevolmente le modifiche direttamente da NetBeans usando un semplice menu contestuale,

direttamente sul file interessato. La versione corrente è in beta, distribuita con licenza GNU GPL, quindi completamente free, i contributi sono ben accetti.

Aggiornamento

• Nuova core library per il client FTP
• Nuovi mesasggi durante l’upload dei files.

 

English:

FtpSiteDeployer is a Netbeans plugin. Allows you to upload a single file to an ftp server. Was designed and is particularly usefull for upload  changes to a web site developed in Java. The connection data are stored in the root of the project. This plugin allows to transfer a single file or a folder from the project view inside the Netbeans IDE.  The plugin add a voice to the contextual menu called “upload file”.

Update

• New core library for FTP Client
• New messages during upload

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Il plugin è ancora in fase di sviluppo, le funzionalità di base sono già disponibili.

 

 

Oggi ho voluto fare un test di performance molto semplice con java per cercare di migliore al massimo le performance nella esecuzione di contenuti dinamici di un sito web, senza tralasciare il discorso garbage collector. Per fare ciò ho realizzato una semplicissima classe che “spreca” un po’ di tempo nel fare operazioni inutili e l’ho fatta girare con vari settaggi. Riporto il codice sorgente della pagina di seguito è una classe semplicissima.

/*
* Testperformace.java
*
* @author l.ciocci
* Created on 5 febbraio 2010, 10.09
*
* Questa è una classe di esempio per verificare le performance della JVM.
* L'idea è quella di verificare le differenze tra la jvm in configurazione
* server e quella in versione standar
*
* Provare ad eseguire con
* java -server Testperformace
*
* oppure
*
* java -client Testperformance
*/

import java.util.LinkedList;
import java.lang.StringBuffer;

public class Testperformace {

public static void main(String[] args) {
long start=System.currentTimeMillis();
LinkedList list=new LinkedList();
StringBuffer sb=new StringBuffer();
System.out.println("Inizio l'esecuzione di Testperformance\n");

//Perdo un po' di tempo
for (int i=0;i<10000;i++) {
//Genero un numero casuale e lo memorizzo nella linked list
String str=new String();
sb.append(i);
str=sb.toString();
list.add(str);
//if (i%1000==0) System.out.print(".." + i);
}

long stop=System.currentTimeMillis();
long time=stop-start;
System.out.println("\nL'esecuzione ha impiegato: " + time + " millisecondi");
}

}

La classe usa un banale conteggio dei millisecondi passati dall’inizializzazione fino al termine dell’esecuzione.
La versione di java che utilizzo è la OpenJDK Runtime Environment (build 1.6.0_0-b11).

Ho fatto varie prove di esecuzione lanciando la classe con il comando:
java -server Testperformace

L’esecuzione ha impiegato: 895 millisecondi (Ovviamente le performance dipendono dalla configurazione hardware e software della vostra Workstation). Le successive esecuzioni hanno dato tempi comparabili.
Utilizzado lo switch:

java -client Testperformace

L’esecuzione ha impiegato: 760 millisecondi. E gli altri test hanno dato tempi comparabili.

Ma la cosa che mi ha sorpreso più di tutte è questo swith passato alla JVM, un po’ “segreto”:

java -XX:+AggressiveHeap Testperformace

In questo caso il tempo medio per eseguire l’applicazione è stato di soli: 391 millisecondi!!!

Ho poi fatto qualche altro test su pagine JSP ottendo ottimi benefici in termini di velocità. Lo switch in questione però impedisce di fare un corretto profiling della memoria con Netbeans (almeno nella mia Linux Box) e di non sembra funzionare bene in debug. Lo switch -XX:+AggressiveHeap sembra destinato all’uso di applicazioni che devono girare per lunghi periodi senza dovere essere riavviate. Molto Interessante!!!

Chi ha visitato di recente la pagina webmaster tools di Google avrà notato che è da un po’ di tempo che WT propone la sezione “velocità del sito” ed in questa sezione si fa riferimento ad un plugin per Firefox (e che si appoggia a Firebug) dal nome Pagespeed. Nota: è da ieri che è uscita la versione 1.6 beta per Firefox 3.6.

Quando Google consiglia una cosa in genere è perchè la ritiene molto utile e quindi vale la pena studiarla. Pagespeed non è difficile da installare ma per il corretto funzionamento richiede come già detto l’installazione di un altro comodissimo plugin Firebug davvero utile agli sviluppatori.

Per attivare Pagespeed è sufficiente fare clic sulla icona di Firebug (in genere posta in basso a destra) nella status bar del browser Firefox, selezionare l’opportuna scheda e premere il pulsante Analize Perfomance.Lo scopo principale di Pagespeed oltre ad aiutarvi a rilevare qualche errore è quello di ottimizzare in termini di velocità il vostro sito web.

Prendiamo come esempio il sito web http://www.clicfoto.it. Porto questo sito come esempio in quanto ha una struttura un po’ complessa e questo porta sicuramente ad una maggiore necessità di ottimizzazione. Inoltre è realizzato con un uso di CSS e table e non solamente con l’uso di tag div.
Effettuando l’analisi con pagespeed ottengo i seguenti risultati:

L’indice di velocità complessivo è di 77/100 ed il messaggio è “Significant performance improvement are possible”
In primo luogo possiamo vedere qualche segnalazione “grave” mostrata in rosso e altre segnalazioni di media entità segnalate in giallo.
Ad esempio segnalate come “grave”:
- Leverage browser caching
- Combine external JavaScript
- Specify image dimensions
- Parallelize downloads across hostnames

Segnalate come “warning”:

- Combine external CSS
- Leverage proxy caching
- Serve static content from a cookieless domain
- Use efficient CSS selectors

In linea teorica possiamo intervenire su tutte le segnalazioni, ma nella pratica dei fatti può essere molto impegnativo risolvere tutti i problemi.
I problemi evidenziati possono (o devono) essere risolti su due livelli:
- Livello di configurazione del server
- Livello di ottimizzazione delle pagine web.

Correzione dell’errore Leverage browser caching
L’errore Leverage browser caching può essere risolto a livello di configurazione di Apache attraverso l’uso del modulo mod_expires.
Verificate di avere nel vostro httpd.conf la linea:

LoadModule expires_module modules/mod_expires.so

Che consente ad apache di utilizzare alcuni meccanismi di caching. Dopodichè nella configurazione del vostro VirtualHost dovete andare ad aggiungere qualche informazione del tipo:

<Directory /home/percorsodelmiosito/images >
ExpiresActive On
ExpiresDefault "access plus 1 month"
</Directory>

<Directory /home/percorsodelmiosito/css >
ExpiresActive On
ExpiresDefault "access plus 1 month"
</Directory>

In questo modo specificate al browser che i file contenuti nelle directory “css” ed “images” non sono soggetti a cambiamenti e Firefox eviterà di ricaricarli.
Ovviamente questo tipo di ottimizzazione è possibile farla solamente se disponete di un hosting che vi consente di lavorare a livello professionale. In genere queste configurazioni non sono disponibile per gli hosting di tipo “economico”

Correzione dell’errore Parallelize downloads across hostnames

Anche questa correzione è possibile effettuarla solamente a livello di server. In pratica sono necessari almeno due “hosting” uno che fornisce il contenuto statico e l’altro quello dinamico. Tutte le immagini statiche dovrebbero essere spostate su un hosting statico del tipo static.clicfoto.it e tutti i percorsi alle immagini saranno del tipo src=”http://static.clicfoto.it/images/mia-immagine” (il link indicato non funziona è solo un esempio).

Correzione Serve static content from a cookieless domain

Questo errore si collega al precedente e può essere risolto nello stesso modo. Nel caso di un sito dinamico come ad esempio http://www.clicfoto.it viene settato un cookie per gestire la sessione. Il consiglio riportato è di fornire tutti i contenuti statici da un hosting parallelo che non setta cookie.

Correzione dell’errore Combine external JavaScript

La correzione di questo errore avviene a livello di programmazione della pagina web. E’ buona norma unire tutti i file javascript in un’unico file: in tal modo il parsing degli script è molto più veloce. Sebbene questa pratica non sia difficile da implementare risulta molto scomoda per i programmatori in quanto dividere gli script in varie parti facilita in genere il debug e l’aggiornamento a nuove versione.

Correzione dell’errore Combine external CSS

Analogamente a quanto specificato per i javascript la stessa operazione può essere fatta sui fogli di stile.

Correzione dell’errore Specify image dimensions

Questo è facilissimo da risolvere in tutti i tags img bisognerebbe sempre specificare l’altezza e la larghezza. In questo modo il broser limita i calcoli da fare per il ridimensionamento dell’immagine in quanto si trova già le dimensioni in termini di altezza e larghezza da raggiungere.

Correzione dell’errore Use efficient CSS selectors

Il consiglio in questo caso è di evitare di utilizzare selettori css troppo innestati ad esempio evitare #primostile #secondostile #terzostile. Lo strumento Pagespeed fornisce informazioni su quali selettori sono inefficienti nella pagina.

Personalmente cerco di limitare a due selettori la maggiorparte dei DIV anche se questo non è sempre possibile.

Analisi post ottimizzazione

Dopo aver fatto qualche ottimizzazione al sito http://www.clicfoto.it il risultato è questo:

Il punteggio in termini di velocità è: 82/100 è il messaggio di Pagespeed è: “Moderate performance improvements are possibile”. Questo risultato è stato ottenuto utilizzando solamente le correzioni di “Leverage browser caching” e di “Leverage proxy caching” ovviamente è possibile migliorare ancora, ma il risultato è già abbastanza soddisfacente!