Newsgroup: it.comp.java
Titolo: Caricamenti sentissimi

Ciao ragazzi... ho un problemino e spero possiate aiutarmi.
Ho scritto alcune applet per una intranet. Il loro caricamento è veramente
lento. In parte il problema è imputabile a anomalie nella connessione ad
Oracle, ma i dba ci stanno lavorando. Al di là di questo, però, esistono
effettivi ritardi nel caricamento che vorrei risolvere....
Cosa mi potete dire? Esistono trucchi per ovviare a tale situazione?
Ho provato ad usare i JAR, ma il guadagno è relativo... Cos'altro potrei
fare? Esistono accorgimenti dal punto di vista programmativo, tipo cose da
evitare?
Vi ringrazio in anticipo
Marco Leto
xar...@tin.it

Marco Leto wrote:

L'unica soluzione che vedo, fino ad ora, viste le poche indicazioni che dai,
e' quella di cercare di caricare in anticipo, ovvero prima che servano
effettivamente, le Applet in questione!
Ad esempio una pagina di presentazione, ad esempio con notizie di copyright
in genere lungo da leggere tutto, o con brevi istruzioni,  o anche inutile,
con un frame nascosto, in cui carichi i file class piu' pesanti (non so se si
possa fare il caricamento specifico di singoli file .class) altrimenti nel
frame nascosto ti carichi direttamente le applet piu' pesanti! In questo modo
memorizzi la applet nel cache del browser, e quando la andrai a ricaricare
per l'efgfettivo utilizzo, cela avrai bella e pronta... sempre che l'utente
abbia perso abbastanza tempo con la pagina introduttiva... Magari fanne una
con diversi links, a piu' pagine...
tentar non nuoce... a chi non fuma!

so che la cosa ti potra' sembrare strana ma e' tutto vero, frutto
dell'esperienza e della ricerca sui siti MS e Netscape:
Innanzitutto i files .jar o .zip degli applet non vengono memorizzati in cache
se superano una certa dimensione, che si aggira intorno ai 64k, e non ricordo
quale dei due browser ha un parametro per dirgli setenere in cache piu' di un
certo numero di .jar/.zip.
La cosa e' una gran rottura perche' se usi librerie di terze parti o anche
solo le SWING -che ti devi scaricare con l'applet- vai sicuramente sopra i
64K.
le applicazioni che ho sviluppato usando il JBuilder C/S 1.0 usavano solo le
AWT e le JBCL di borland e si portavano appresso un buon Mb di vari Jar, ma
adesso le applet sono state portate al JBuilder 2, dove le jbcl sono basate su
SWING anziche' su AWT, e quindi mi porto appresso il swingall.jar (forse avrai
notato che, salvo specificato il contrario in fase di deploy, i files.jar
hanno compressione 0%)
La prima cosa che ho fatto e' stato pasare ai .zip in modo da poter avere
sempre della compressione.
Ma la piu' grande rottura di coglioni, e chiedo scusa per aver usato il
termine 'rottura', e' il fatto che sia su Netscape che su M$IE la velocita' di
istanziazione delle classi dipende dall'ordine in cui compaiono i files .jar o
.zip nella voce ARCHIVE del tag APPLET.
Se hai diverse pagine che si portano appresso gli stessi .jar/.zip mettili
nello stesso ordine in tutte le pagine. se usi diversi applet non metterli in
diversi jar ma in un unico jar. Stai attento anche alla condivisione della
connessione.
Noi abbiamo avuto dei grossi problemi perche' ogni aplet che arrivava sul
browser doveva istanziare una nova connessione, e a causa di alcuni routers
sulla rete (e' una intranet con alcune migliaia di macchine), il tutto portava
via un bel po' di tempo macchina.
Usa una connessione statica e condividila fra tutti gli applet, cosi' verra'
aperta solo dal primo applet e tutti gli altri la troveranno subito
disponibile senza dover aprire la loro connessioner. risparmierai un bel po'
di tempo
Sempre a disposizione per charimenti
Carlo Emanuele Demontis
PUTTANO del newsgroup it.comp.java, GEKOTAG permettendo



Sempre a disposizione per charimenti
Grazie veramente!



 vero?! Esistono?!
E' quasi impossibile venire a capo di questa situazione. E' per questo che non
si fanno applicazioni a 2 livelli basate su un browser come client. Ti basti
pensa che NS č lentissimo a gestire grossi jar, mentre Explorer č molto piů
veloce, e ci sono infiniti altri problemi.
Soluzioni:
1 - Non usare Applet Java come client: solo HTML o applicazioni Java
2 - Usa un architettura n-tier, per esempio con delle servlet, e mantieni le
applet entro i 50Kb.
Noi abbiamo sviluppato un framework basato sulle servlet che gestisce connection
pooling (ma non una sola statica per tutti!!! un bel collo di bottiglia),
logging, e altre cosette. Siamo riusciti a sviluppare degli AWT data-aware come
quelli della Borland (be... piů o meno) come DBChoice, DBList, LookupTextField
che funzionano ad n-livelli e le Applet stanno tutte entro i 50Kb.
Ugo
www.ugolandini.net

 
xar...@tin.it
--
Marco Tonoli
ma...@mail.shopware.it
http://www.shopware.it/