L'utilizzo di AJAX potrebbe migliorare notevolmente le prestazioni del server?

Dipende da cosa stai facendo e da come lo stai facendo.

• Se stai sostituendo carichi di pagine complete con richieste AJAX (ad es fare chiamate AJAX quando un utente fa clic su quello che sarebbe stato un pieno caricamento della pagina), quindi AJAX diminuirà il carico del server perché lo sei (presumibilmente) facendo meno elaborazione e restituendo meno dati.

• D'altra parte, se aggiungi il tipo di aggiornamento automatico AJAX che esegue il polling il server ogni pochi secondi che potrebbe aumentare il carico a seconda dell'utente (potrebbe non aumentare il carico del server se il l'utente continua a premere F5 per aggiornare manualmente comunque, ma la maggior parte delle persone generalmente non farlo per ore)

• Un'altra ottimizzazione AJAX è caricare solo più dati mentre scorri. In tal caso, se l'utente non scorre fino in fondo, è così elaborazione sprecata.

Naturalmente l'implementazione può in ogni caso alterare i risultati in entrambi i casi, si tratta di risultati tipici che presuppongono implementazioni ragionevolmente buone.

Ovviamente serve a ridurre il carico del server. Guarda questa presentazione @ jsconf'09 - per come Facebook ha usato ajax per farlo.

Ajax è asincrono. comunicazione server - e puoi utilizzarla in una miriade di modi. Le persone lo usano per caricare semplici JSON su Web in tempo reale e tutto il resto.

Ricorda: la vera sfida è il equilibrio tra client e server. Sforzati di far sì che ciascuna parte svolga il proprio lavoro in modo tale che il sistema sia ottimizzato e ottieni evidenti vantaggi della percezione percepita e della velocità reale.

Ci sono altri fattori che non stai considerando - nella maggior parte dei casi, AJAX aumenterà il carico del server. In uno scenario tipico, non ajax, un utente carica una pagina grande ogni pochi secondi o pochi minuti. Sì, quella singola pagina ha un po 'più di lavoro per il server, ma ha un sacco di tempo tra le richieste di recupero e altre richieste. In uno scenario AJAXified, quel caricamento su singola pagina è ora dozzine di piccoli colpi, martellando costantemente il server e aspettando le risposte.

È un po 'come la morte da 1000 tagli - nessuna delle richieste è così grande in sé e per sé, ma il peso totale è un killer. Soprattutto quando inizi a considerare che queste piccole richieste sono tanto costose da servire come una richiesta a piena pagina. In entrambi i casi, probabilmente stai attraversando un'intera pipeline di applicazioni web, colpendo un database e aspettando una risposta stando seduti su una preziosa connessione HTTP.

Ecco un esempio di come ajax può diventare brutto sul server molto velocemente. Prendiamo un tipico "executive dashboard" che presenta 4 slot per i widget. Diciamo che all'amministratore delegato piace un rapporto completo sulle vendite nella parte destra, una lista dei 10 migliori guadagni nel mezzo e un rapporto sui prezzi delle azioni della società sulla destra. E diciamo che lo faremo tramite semplici richieste remote ajax. Senza prendere in considerazione fogli di stile, immagini e altre risorse, la tua pagina ora richiede 4 round round HTTP (pagina principale, ciascuno dei report del dashboard) contro il server. Ognuno di questi richiede uno stack Web completo da eseguire: si stanno andando a colpire database e si esegue il rendering HTML usando il proprio framework web, giusto? Ora moltiplicare il singolo CEO di 2000 utenti remoti, alcuni dei quali hanno connessioni spotty.

Al contrario, è possibile avere una singola pagina sul lato server che esegue e restituisce uno scheletro HTML nonché i dati (inclusi in JSON in-page) per il rendering dei report. Connessione singola, più grande ma meno battente sul server Web in totale perché non si gestiscono 4 richieste e si girano 4 pipeline, ecc.

Se stai usando AJAX per sostituire il lavoro che altrimenti farebbe il server allora sì che migliorerà l'esecuzione del server. Tuttavia, potresti aver progettato cose in modo che il server stia ancora facendo altrettanto e ora qualsiasi cosa stia succedendo con AJAX è in cima a quello che il server stava già facendo.

Per lo più si tratta di cose dell'interfaccia utente, dal momento che non dovresti fare nient'altro sul lato client. In pratica, tutto ciò che il server stava facendo per supportare l'interfaccia utente (ad esempio, ricaricare la pagina con un layout diverso in risposta all'input dell'utente), fare invece con JavaScript.

Se il rendering HTML è una parte enorme del profilo delle prestazioni del tuo server delle applicazioni, lo spostamento del rendering HTML sul client può essere una performance vincente sul server delle applicazioni.

Tuttavia, se il rendering HTML è una piccola parte del profilo delle prestazioni del server delle applicazioni, più richieste in genere implicano più viaggi nello stack, più query, più di tutto sul server delle applicazioni, una perdita di prestazioni.

Ovviamente, l'unico modo per sapere nel tuo caso particolare è provarlo.

Devi considerare il modo migliore per implementare la tua soluzione. Una semplice forma non dinamica non ha bisogno di Ajax e aggiungerla potrebbe effettivamente danneggiare la perfomance. Se il tuo problema è una cattiva domanda, l'ottimizzazione dell'ajax nel mondo non ti porterà un aumento delle prestazioni che sarà accettabile.

Se il tuo server è oberato di lavoro, devi capire perché.

Se stai ottenendo un sacco di hit allora ajax non ha intenzione di risolvere quel problema hai bisogno di più capacità. L'aggiunta di ajax aumenterà il numero di richieste che il tuo server deve gestire.

Se hai una pagina complicata dovresti vedere se c'è qualcosa che puoi fare dal lato client per ridurre il carico sul tuo server. Se la tua pagina è dinamica ma ha un pacchetto dati limitato nella cache che per l'aggiustamento del lato client può dare i migliori risultati.

E a volte Ajax ti aiuterà. Quando hai forme complesse con dati dinamici, ajax vince il giorno. Ma se le domande sono complicate e richiede molto tempo per essere eseguito, ajax continua a non risolvere il problema.