Overloading del costruttore

1
2
3
4
5
6
7
8
public class OverloadResolver {
public OverloadResolver(Object param) {
System.out.println("Construttore con parametro Object");
}
public OverloadResolver(Object[] param) {
System.out.println("Costruttore con parametro Object[]");
}
}

Qualcuno sa cosa succede se faccio questa chiamata:

1
2
3
4
5
......
public static void main(String[] args) {
OverloadResolver or = new OverloadResolver(null);
}
......

Cioè se richiamo quel costruttore con parametro null, cosa viene richiamato nella classe di sopra ? Dai dai dai che lo sapete……e ditelo !!!!!! (magari qualcuno commenterà….chi lo sa!!!)

Ottimizzare le performance di un sito-web

75 milioni di richieste al giorno, ovvero quasi 900 richieste/secondo, credo sia una immensa soddisfazione per un programmatore web di alto livello, e cioè sviluppare un’applicazione web, fatta bene, che possa soddisfare quei numeri lì. E’ chiaro che un sito web pronto al decollo, non farà mai tutte quelle richieste al giorno, dovrà passare un pò di tempo, in cui dovrà essere pubblicizzato, finire al meglio sui motori di ricerca, e quant’altro. Ma è altrettanto chiaro che, se l’obiettivo, volente o nolente (vedi siti che sono diventati famosi dall’oggi al domani), è quello di cercare di sviluppare un’applicazione web che possa reggere ritmi del genere. Le cose più importanti da capire durante lo sviluppo , se si vogliono ottimizzare le prestazioni web, sono che bisogna gestire le differenti punte di traffico, discriminando tra le operazioni di lettura (READ) che sono molto economiche, e le operazioni si scrittura (WRITE) che sono molto costose, ovviamente in termini di performance. Per operazioni di READ, intendiamo l’accesso a parti statiche che sono state già memorizzate e sono disponibili all’uso immediato. Per operazioni di WRITE intendiamo le operazioni di aggiornamento di un record di un database, o l’inserimento di un record, più in generale consideriamo una qualunque operazioni che comporta un calcolo prima che l’output venga rediretto all’utente.

performance

Lo schema in figura mostra 2 cluster di database (supponendo di utilizzare MYSQL), uno per gestire le richieste di READ, ovvero ogni richiesta dell’utente di visualizzare le pagine. Tutte le pagine sono servite da memCached. Le richieste di WRITE invece, vengono gestire dall’altro cluster, e attraverso la replicazione di MYSQL gli aggiornamenti vengono trasmessi dal cluster di WRITE a quello di READ. Seguono alcuni trick per ottimizzare le prestazioni:

  • READ cluster, per velocizzare usa dei precompilati scritti in C, e non perl/php script.
  • READ cluster, usa UltraDNS per il load balancing.
  • WRITE cluster, minimizza il numero delle query ed il tempo di connessione per gestire le richieste.
  • WRITE cluster, usa il più possibile i processi offline.
  • Usa la replicazione per avere scalabilità e affidabilità del servizio.

WordPress Themes