JSP Performance i forhold til ASP og PHP

JSP compiles og bør derfor teoretisk performe lidt bedre. Jeg mener ikke at
der er basis for at sige at det i praksis betyder noget.

Fordelen ved JSP er at det er en del af J2EE. Det er designet til store
komplekse systemer (tusinder af sider i clustered 4 eller 5 tier arkitektur) og har
en masse muligheder.

Ulempen ved JSP er at hvis man skal udnytte disse muligheder, så er der meget
at sætte sig ind i. ASP og PHP går man mere bare i gang med.

JSP bruger Java, ASP bruger VBScript (eller JScript) og PHP sit eget. Men
det er nok meget et spørgsmål om smag og behag.

Jeg mener faktisk at JSP er meget godt. Men det er kun for rigtige
programmører med en solid OOP baggrund. Og fordelene viser sig først
ved store løsninger.

En af fordelene ved at skrive det i JSP set fra mit eget synspunkt er jo så at jeg bliver bedre til både JAVA og JSP, hvilket jeg har det ganske fint med.

Ham som jeg skal lave commerce sitet for, har et ASP site nu som kører som det skal, men jeg ville jo gerne sikre mig at det ikke blev nævneværdigt langsommere hvis jeg smed det over på en linux boks og kørte det hele via JSP.

Har i nogle Pro's and Con's med JSP på en linux boks?

En anden pointe end lige performance for JSP er, at det er et fuldblods-programmeringssprog, idet du har adgang til hele J2SE API'et. I ASP og PHP har du ikke nær så mange programmeringsmæssige muligheder.

Om du skal vælge JSP i stedet for ASP eller PHP kommer kraftigt an på, hvor stor belastning du forventer dit site at få. JSP, ASP og PHP er alle scriptssprog, som skal oversættes inden det kan afvikles af serveren. For ASP og PHP bliver dette gjort HVER gang en side kaldes, og kaldes en side ofte, vil serveren blive kraftigt belastet af at skulle oversætte hele tiden. JSP har så den fordel, at oversættelsen kun foregår første gang siden kaldes, hvorefter den oversatte side caches. Selvfølgelig kan man risikere at siden bliver smidt ud af cachen ved f.eks. pladsproblemer, men så bliver den blot oversat påny, næste gang den kaldes. Jeg ved ikke lige hvordan det er med ASP, men PHP er det muligt at opnå samme effekt som JSP, ved at installere noget ekstra software på serveren.

PHP har så den ulempe, at det stadig lider af bugs. Om dette er relevant for dig, afhænger meget af, hvor kompliceret din kode er, og om du vælger af udvikle objekt-orienteret. PHP's garbage collector er ikke just effektiv, og peger to objekter på hinanden, uden at andre objekter peger på en af de to, bliver de hængende, selvom garbage collectoren burde smide begge to ud. De samme bugs er ikke noget du vil have problemer med, hvis du anvender JSP.

Jeg har erfaring med et PHP-site, hvor en side blev kaldt ca. 100 gange i sekundet. Dette betød MySQL-serveren der kørte på samme maskine stort set ikke fik tid på CPU'en, da tiden gik med at oversætte den kaldte side 100 gange i sekundet :) Løsningen var at installere noget software, så at de oversatte PHP-sider blev cached, som det er tilfældet med JSP.

Java er uafhængigt af styre systemet. Du kan køre den samme JSP/servlet
engine på både Windows og Linux.

Java er generelt en god sammenblanding med Linux, især hvis du vælger at køre med IBM's JVM.

Nu siger du at den er Cached, hvad sker der så hvis jeg nu kalder sådan her list.jsp?id=200 og lige bagefter kaldes den med list.jsp?id=250 er der noget kode som slår cachingen fra? eller kan man få den til kun at håndtere dele af cachingen eller hvorledes.

JSP sider skulle ikke ryge ud af cache.

.jsp compiles til .java med jspc
.java compiles til .class med javac
.class loades af classloaderen
en enkelt instans instantieres (medmindre man har erklæret den til at være singlethreaded)
den kaldes af flere tråde til at processe requests

Hvis objektet blev GC'et så ville det påvirke funktionaliteten, hvis man f.eks.
opbevarede state i siden.

list.jsp compiles til kode

list.jsp?id=200 og list.jsp?id?250 kalder samme kode - den kode henter
så id parameteren og gør noget forskelligt alt efter havd den er

Perfekt, så det er koden der er cached og ikke den resulterende html der er cached, det er jo perfekt.

Min tanke var at bruge flade XML filer som data storage istedet for min MYSQL idet at den stakkels MSSQL på hans nuværende server er ved at bukke under konstant.

Efter at have nærlæst servlet specs må jeg nok give dsj ret. Containeren
har lov til at smide instansen ud og initialisere en ny. Og staten bør så
opbevares andet steds.

Hvis du vælger at gemme dine data i XML-filer, skal du som minimum have god erfaring med strukturering af data, hvis det skal komme til at fungere nogenlunde effektivt. Genrelt plejer der ikke at være problemer med MySQL og hjemmesider, men skal det være stort og må data ikke gå tabt, vil jeg anbefale PostgreSQL. Hvis databasen er ved at bukke under, må det enten være pga. for ringe hardware eller dårlig strukturerede tabel-strukturer.

Normalt er database performance et spørgsmål om at få passende med CPU, RAM og disk
kapacitet stillet til rådighed.

Hvis man har penge nok kan man få næsten den kapacitet man vil have. TPC rekorderne
er over 1 million TPM idag.

Som generel hovedregel:
  - write performance (INSERT/UPDATE/DELETE) => mange diske
  - read performance (SELECT) => meget memory
  - read performance med komplekse queries => meget CPU

XML filer en en glimrende løsning til readonly data i en lille løsning
(single server).

XML filer er en meget dårligt løsning hvis der skal rettes i data.

XML filer en meget dårlig løsning til en stor løsning (multi server).

Den kommer til at køre single server, men multi processor server.

Nu er problemet bare at jeg ikke har uanede mængder af resourcer stillet til rådighed.

Jeg havde faktisk tænkt mig en lidt kombi løsning af XML og MYSQL basen.

Alle de ting der skulle skrives, ville jeg hive ind i databasen, således at de blev skrevet direkte ned i Databasen, hvorimod at alle de områder som der ville hentes igen og igen uden at blive ændret særligt tit, ville jeg skrive ned i XML filer.

Disse XML filer, kunne indeholde sådanne informationer omkring pris og vægt, farve beskrivelse samt associerede produkter, og url på billede, ting som der ikke ændrer sig konstant i løbet af dagen, men noget som ville skulle kunne ændres i løbet af nogle dage.

Jeg ville derfor køre et cron job, som tog de her ting fra databasen, hvor at det også ville ligge i, og eksportere det til XML filerne, således at pushe dem ud til XML filer, hvor at de så kunne ligge og blive brugt fra XML filer i stedet for fra database storage.

Hvorfor i alverden vil jeg så gøre det. det er fordi at jeg har en multi processor pentium 3 800 mhz maskine, som kører red hat, med en Mysql base på som jeg vil havde til at køre showet, og jeg er pinlig bange for at databasen skal gå ned hvis jeg smider alt read content ind i basen.

Det er ihvertifald det der sker nu.

multi processor er ikke noget problem (diske er stadig lokale)

teknikken er set før med at cache statisk data som disk filer

efter min mening giver det mest mening hvis de statiske filer serves
af en simpel web server som Apache og slet ikke skal gennem PHP/ASP/JSP

hvis størrelsen af de statiske web sider ikke er for stor i forhold
til den RAM der er til rådighed for database serveren, så bør det ikke
være noget problem at lade den serve

Så du ville ikke anbefale at jeg lavede en XML side, men derimod at jeg pushede statisk data ned i lige så mange HTML sider som der er varer eller hvorledes?

Vi diskuterer mulighederne:

1)  database--(natligt job)--HTML filer--(Apache)-->

2)  database--(natligt job)--XML filer--(Tomcat)-->

3)  database--(Tomcat)-->

Jeg er ikke overbevist om at forskellen på #2 og #3 er specielt stor.

Hvorimod #1 vil være markant hurtigere.

Men altså det afhænger af mange ting. Overvej at lave nogle eksperimenter.

Jeg tror du har ret i din antagelse af at mulighed 2 nok ikke er så voldsomt meget hurtigere, men det vil jo per definition betyde et væsentligt mindre load på databasen, men alt skulle jo stadig ædes igennem en fortolker.

Jeg forsøger mig lidt frem

Så er jeg tilbage.

Jeg kan godt lide din ide med at smide en html fil til hver, men der er dog et lille mindre issue.

Der er ca 80 affiliates af dette site, fordelt på en 7 forskellige sprog. og han har ca 3000 varer.

dette betyder at der skal ligge 3000*80 html filer i direktoriet, det er vidst en smule voldsomt. 240000 små html stumper, er der ikke lidt bombastisk? Men selvfølgelig er det muligt, jeg kan bare godt se hvor lang tid det monstro tager om natten at pushe alle de filer ud på harddrevet.

Hvad syntes i ?

Det antal får jo en database løsning til at lyde tiltalende.

Specielt hvis f.eks. antal der skal vises i døgnet er mindre end 240000.

3 løsninger.

1. database løsning alle ting bliver hentet direkte fra databasen via en jsp fil
2. XML løsning alle varer bliver postet ud i en vare.xml og en sprog.xml fil og så bygger en JSP engine de to sammen, ( fy for s....n hvis den skal traversere begge filer igennem for at fylde en side ud) thats a no go.
3. HMTL løsningen 240000 filer som ligger og knokler i et dir. også en no go.

Det ville virke smartest med en Database nær løsning der.

Jamen så tror jeg det bliver sådan her, hang on tight :)

Der kommer til at være 3 forskellige typer sider.

fuldkommen statiske sider dette kunne være sprogversionerede sider af foreksempel index siden. disse bliver pushet om natten til HTML

Delvist statiske sider, disse sider genereres dynamisk, men ud fra samme stamdata, som kan ændres via en push Metode samt en batch kørsel ( cron job) en gang om natten. disse bliver pushed ud som XML og trukket ud via JSP.

fuldkommen dynamiske sider, som trækkes direkte fra databasen ( indkøbskurv og så videre ) Disse hiver direkte via en browserbean ud i JSP siderne.

Med hensyn til de delvist statiske sider som jeg har planer om at hive ud i XML filer, så er det hovedsageligt en products.xml fil og en category.xml fil

category.xml vil havde en categoryid, og et category_sprog_navn og under hver categoryid vil der være en lang liste af product ids som vil relatere til felter i products.xml

products.xml vil havde en product id, en products_sprog_klassificering_navn, en products_sprog_klassificering_description, en products_base_pris.

der vil nok komme nogle ekstra ting med på xml listen over products, farver og størrelser af de forskellige varer, og den slags, men et par flere

Well nu har han jo 3000 varer. og med det her system vil der komme til at ligge ca en 300.000 linier data i XML filen. Vil det ikke betyde at man skal plastre igennem en frygtelig stor fil, hver evig eneste gang man skal bygge en liste af produkter, og hvor meget betyder det for performance?

Ville det kløgtige måske være at lave små xml filer, for hver kategori?

Du vil vel læse den XML fil ind en enkelt gang og gemme den fra request
til request ?

Så er det mest et spørgsmål om memory. Regn med 3-5 gange så meget memory til
DOM træet som XML filen fylder på disk.

hmmm den skal jeg lige havde grejet, det vil sige at jeg koder en applikation som starter min tomcat/resin, og i den applikation opretter jeg et objekt hvor at min information fra XML filen ligger i?

Det ved jeg skutte lige hvordan man gør, men hvad det er vel noget man kan finde ud af.

Du kan ikke læse den kæmpe fil ind for hver request, så enten gemmer og genbruger
du den eller så skal den splittes op.

Rent praktisk kan du gemme den i en singleton.

Måske jeg spørger dumt, men hvorfor overhovedet bruge xml-filer?

Den letteste løsning er at have data i databasen, men kun indlæse dem i serverens ram en sjælden gang imellem.

Hvis datamængderne er så store, at du ikke kan have dem i ram, bør du meget kraftigt overveje bare at bruge en standard database. Hvis du har en stak filer du skal åbne for hvert request, vil den "hjemmestrikkede database" garanteret dø ved meget lavere belastining end MySql kan klare.

Det var hovedsageligt for at sikre at databasen ikke blev trukket ned gang på gang, som der sker med hans nuværende system, således at jeg kørte direkte på databasen med nogle ting, og at jeg kørte i XML filer med nogle lidt mere statiske ting.