Impatto sulle prestazioni dell'utilizzo di aop

Question

Abbiamo iniziato a utilizzare Spring Aop per gli aspetti trasversali della nostra applicazione (sicurezza e cache al momento).

Il mio manager è preoccupato per l'impatto delle prestazioni di questa tecnologia, sebbene comprenda appieno i vantaggi.

La mia domanda, hai riscontrato problemi di prestazioni introdotti dall'uso di aop (in particolare spring aop)?

Answer 1

Finché hai il controllo del tuo AOP penso che sia efficiente. Avevamo comunque problemi di prestazioni, quindi per il nostro stesso ragionamento non eravamo completamente in controllo;) Questo era principalmente perché è importante che chiunque scriva aspetti abbia piena comprensione di tutto altro aspetti del sistema e modalità di correlazione. Se inizi a fare " smart " cose che puoi superare in astuzia in un batter d'occhio. Fare cose intelligenti in un grande progetto con molte persone che vedono solo piccole parti del sistema può essere molto pericoloso dal punto di vista delle prestazioni. Questo consiglio probabilmente si applica anche senza AOP, ma AOP ti consente di spararti ai piedi in modi davvero eleganti.

Spring utilizza anche il proxy per manipolazioni dell'ambito e ecco un'area in cui è facile ottenere perdite di prestazioni indesiderate.

Ma dato che hai il controllo, l'unico vero punto debole con AOP è l'effetto sul debugging.

Answer 2

Se le prestazioni saranno un problema, abbiamo usato AspectJ con grande efficacia.

Poiché utilizza la tessitura bytecode (tempo di compilazione vs. runtime fa la differenza) è uno dei framework AOP più veloci in circolazione. Vedi: Benchmark AOP

Answer 3

Quando l'ho usato, non l'ho fatto, ma la mia applicazione non è la tua applicazione.

Se lo usi per le chiamate che vengono utilizzate in un ciclo molto stretto, c'è la opportunità per un notevole successo di prestazioni. Se viene utilizzato solo per verificare la sicurezza una volta per richiesta e memorizzare nella cache varie cose, non riesco a vedere come sia probabile che sia significativo, ma è per questo che dovresti profilare e confrontare la tua app

.

Mi rendo conto che " misura con la tua app " probabilmente non è la risposta che stavi cercando, ma potrebbe anche essere quella che hai indovinato che otterrai :)

Answer 4

Se si utilizza AOP basato su proxy, si sta parlando di 1 ulteriore chiamata al metodo Java per aspetto applicato. L'impatto sulle prestazioni è piuttosto trascurabile. L'unica vera preoccupazione è la creazione dei proxy, ma di solito ciò accade una sola volta all'avvio dell'applicazione. Il blog SpringSource ha un ottimo post su questo:

http://blog.springsource.com / 2007/07/19 / sfatare-miti-proxy-impatto-prestazioni /

Answer 5

In teoria, se usi AOP per quello che potresti fare con l'accoppiamento duro, non ci sono problemi di prestazioni, costi generali e chiamate di metodi extra a meno che tu non torni per niente. AOP Framework ti offre un modo per rimuovere il duro accoppiamento e fattorizzare la tua preoccupazione trasversale.

In pratica, AOP Framework può introdurre 3 tipi di overhead:

• fire-tempo
• meccanico di intercettazione
• integrazione dei consumatori (modo per sviluppare un consiglio)

Per maggiori dettagli puoi fare riferimento a when-is-aop-code- eseguito .

Fai solo attenzione a come implementare un consiglio perché il codice trasversale è una tentazione per il pugilato / unboxing e la riflessione (costoso in termini di prestazioni).

Senza un framework AOP (duro abbinamento delle preoccupazioni trasversali) è possibile sviluppare più facilmente i consigli presunti (dedicati a ciascun trattamento) senza boxe / unboxing e riflessione.

Devi sapere che la maggior parte dei framework AOP non offre la possibilità di evitare totalmente boxe / unboxing e riflessione.

Ne ho sviluppato uno per rispondere alla maggior parte dei bisogni mancanti, concentrato su 3 cose:

• facile da usare (leggero, facile da imparare)
• trasparente (nessun codice di rottura da includere)
• efficiente (niente boxe / unboxing, nessuna riflessione nel codice utente nominale e buona meccanica di intercettazione)

Puoi trovare il mio progetto open source qui: API Puresharp .net 4.5.2+ precedentemente < a href = "https://github.com/Virtuoze/NConcern" rel = "nofollow noreferrer"> NConcern .NET AOP Framework

Answer 6

Hai mai pensato agli strumenti AOP che aggiungono aspetti all'oggetto in fase di esecuzione quando ne hai bisogno? Ce n'è uno per .net " Aggiungi aspetti all'oggetto usando Dynamic Decorator " (Http://www.codeproject.com/KB/architecture/aspectddecorator.aspx). Credo che tu possa scriverne uno simile per Java.

Answer 7

Se si utilizza un framework per aspetti, possono esserci problemi di prestazioni. In seguito, se si crea astrazione sopra un framework e la gestione degli aspetti viene eseguita da framework, è molto difficile scoprire la causa del problema relativo a problemi di prestazione . Se sei davvero preoccupato per le prestazioni e la piccola fetta di tempo ti preoccupa di più, suggerisco di scrivere i propri aspetti. Nessuno vuole reinventare la ruota, ma a volte può essere meglio. Puoi scrivere la propria implementazione dell'astrazione dell'alleanza AOP.

Answer 8

Ho usato Spring AOP in un processo batch nel mio progetto corrente per gestire una banca dati.

Inizialmente, si pensava che non ci sarebbe stato un problema di prestazioni, ma non abbiamo capito l'equazione che abbiamo chiamato il database migliaia di volte. un aspetto chiamata in aop non influisce molto sulle prestazioni, ma moltiplicalo per migliaia e risulta che il nuovo sistema era peggiore di quello precedente, a causa di queste chiamate di metodo extra.

Direi che aop è un ottimo sistema da usare, ma prova a prendere nota di quanti metodi le chiamate vengono aggiunte alla tua applicazione