GetRequest() er langsom, hjælp mig med at optimere.

Den venter vel paa at faa svar fra serveren. Jeg kan ikke se de helt store optimerings muligheder.

Performance opnaaes vel ved at lave crawleren multithreaded og hente flere sider paralllelt.

Kan kun give Arne_v ret :)

Altså selve tanken om at det er serveren der tager lang tid om at svare, er jeg med på. Og det giver da også god mening, lige indtil at denne Java kode, i gennemsnit tager 50-300 ms om at opnå samme funktionalitet..

final URL url = new URL(urlName);
final HttpURLConnection urlcon = (HttpURLConnection)url.openConnection();
urlcon.setReadTimeout(4500);
int response = urlcon.getResponseCode();

Lige for at notere det, så kører det hele trådet, og jeg benytter "det-der-savtakkede-mønster-algoritme" fra TCP's congestion control, for at sikre en fornuftig ydelse..

Meget mystisk.

Er der forskel for alle slags URL'er ?

Lidt uddybende information :)

En tråd startes op, den kontakter siden og får HTML koden ind. Denne analyseres, og splittes op af nogle hjemmelavede algoritmer, som til sidst sætter alle nye links ind i en liste.

Hvis der er flere links i køen end der er tråde der arbejder, tilføjes der flere tråde, indtil den første fejler. Efterfølgende halveres det antal tilladte tråde, dog begynder dette tal at stige, indtil der kommer en fejl igen.

Dette virker fint, især fordi at min internet forbindelse varierer efter placering, og det er fornuftigt skalérbart.

Nuvel, den største tidsrøver, er blot den ene linje ovenfor, som tager alt tiden på at oprætte forbindelsen til serveren for den 600. gang. :)

Alle URL'er er til den samme side, der er som sådan ikke noget der varierer...

Og "den-der-savtakkede-mønster-algoritme" fra TCP's congestion control er kendt som AIMP / Additive Increase Multiple Decrease, fandt jeg lige ud af.. :)

Jeg har lige lavet lidt flere undersøgelser, og det viser sig at klassen WebClient er marginalt hurtigere, men jeg finder stadig ikke de samme tider som ved Java..

Her har jeg forsøgt med disse implementeringer.
WebClient wc = new WebClient();
byte[] b = wc.DownloadData(site);

Den var en anelse hurtigere, jeg tænker at det er fordi den ikke skal bygge en string.

WebClient wc = new WebClient();
string s = wc.DownloadString(site);

Generelt set, er de ikke hurtigere, men de er pænere programmeringsmessigt, bortset fra at de ikke umiddelbart har en fornuftig timeout..

Flere idéer?

Jeg forestiller mig at det måske er hurtigere at åbne en socket til adressen. Men jeg kan ikke rigtig finde noget omkring dette.

Jeg forestiller mig at det må være noget med at man skal lave sin egen header, hvilket jeg ikke lige kender til.. Er der nogen der har forsøgt på det før?

Jeg har forsøgt med nedenstående tcpClient, men uden held.. Efter et par hundrede itterationer, begynder den at kaste exceptions om at porten og adressen kun må benyttes en gang.

using (TcpClient tcp = new TcpClient(ip.ToString(), 80)) {
tcp.LingerState.Enabled = false;
tcp.NoDelay = false;
tcp.ReceiveBufferSize = 100000;

using (NetworkStream stream = tcp.GetStream()) {
stream.WriteTimeout = 4500;

string head = "GET " + site.Link + " HTTP/1.1\n";
head += "Host: " + site.ToHostname() + "\n";
head += "Content-type: text/html; charset=iso-8859-1\n";
head += "Expect: 100-continue\n";
head += "Max-Forwards: 10\n";
head += "\n\n";

byte[] header = Encoding.ASCII.GetBytes(head);
stream.Write(header, 0, header.Length);
                       
using (StreamReader sr = new StreamReader(stream, true)) {
StringBuilder content = new StringBuilder(10000);

while (sr.Peek() >= 0) {//Indhold insættes linjevis
content.Append(FilterLine(sr.ReadLine()));
}

result = CleanHtml(content);
}

}

tcp.Close(); //Forsøg på at afhjælpe tidligere nævnte exception
}

Ligeledes syntes jeg heller ikke at jeg opnår de hastigheder jeg havde forestillet mig, men det er svært at få et samlet billede, når det ikke kan gennemføre en omgang på den side jeg tester med.

Lukket, ingen løsning fundet.
Min tanke er at .NET er langsommere til IO end Java, men har ikke fundet frem til den dybere årsag.