De Devschuur Coffee Corner - Iteratie ⓬

[Hydra]

Lethalis schreef op maandag 8 oktober 2018 @ 15:18:
Maar het is wel ruim 3 keer zoveel. Heb je dus veel applicaties draaien, dan heb je 3 keer zoveel hardware (of cloud computing power ) nodig.

Wat klopt er van het verhaal dat het trager is dan Go dan? Want dat verbaast me nogal. Go zit ongeveer op 't niveau van Java code tegenwoordig (blijft een managed taal in wezen), en ik dacht altijd dat C# vrijwel net zo 'snel' was. Dat 'iets' drie keer zo traag is, lijkt me eerder een implementatiekwestie te zijn. Maar ik heb geen ervaring met .Net core.

Go vs Java: https://benchmarksgame-te...hmarksgame/faster/go.html

(niet dat die benchmarks iets zeggen, maargoed)

[Gropah]

Hydra schreef op maandag 8 oktober 2018 @ 14:26:
Laat ik voorop stellen dan m'n 'enthusiasme' tegen Go niks met jou persoonlijk te maken heeft!


[...]

I know

En zoals ik al zei, Go is echt niet de silver bullet. Het heeft zijn beperkingen en die weet je aan te stippen. Maar met elke versie word het weer beter en een flink aantal van de punten die je noemt worden bij versie 2 van Go aangepakt. Ik ben er op dit moment wel enthousiast over en ben dan ook benieuwd hoe het er allemaal mee verder gaat.

Hydra schreef op maandag 8 oktober 2018 @ 16:58:
[...]


Wat klopt er van het verhaal dat het trager is dan Go dan? Want dat verbaast me nogal. Go zit ongeveer op 't niveau van Java code tegenwoordig (blijft een managed taal in wezen), en ik dacht altijd dat C# vrijwel net zo 'snel' was. Dat 'iets' drie keer zo traag is, lijkt me eerder een implementatiekwestie te zijn. Maar ik heb geen ervaring met .Net core.

Go vs Java: https://benchmarksgame-te...hmarksgame/faster/go.html

(niet dat die benchmarks iets zeggen, maargoed)

AFAIK kan Java heel snel zijn, het heeft alleen een spinup time en een memory overhead. En wat me ook opvalt aan die benchmarks is dat er geen netwerk spul in lijkt te zitten. Als je naar deze willekeurig gevonden benchmark kijkt dan blijkt wel daar wel punten scoort.

Overigens is hier een benchmark van Go VS .NET core waarin Go het ook wint in de gemeette metrics.

[Mugwump]

Gropah schreef op maandag 8 oktober 2018 @ 17:19:


AFAIK kan Java heel snel zijn, het heeft alleen een spinup time en een memory overhead. En wat me ook opvalt aan die benchmarks is dat er geen netwerk spul in lijkt te zitten. Als je naar deze willekeurig gevonden benchmark kijkt dan blijkt wel daar wel punten scoort.

Overigens is hier een benchmark van Go VS .NET core waarin Go het ook wint in de gemeette metrics.

Mja, dat soort benchmarks zijn altijd wat dubieus. PHP 5.4 op Apache is nou niet bepaald de snelste keuze zoals iemand in de comments al aangaf en Tomcat + JSP is voor Java nou ook niet direct de optimale keuze als het om pure snelheid gaat.

[Gropah]

Mugwump schreef op maandag 8 oktober 2018 @ 17:39:
[...]


Mja, dat soort benchmarks zijn altijd wat dubieus. PHP 5.4 op Apache is nou niet bepaald de snelste keuze zoals iemand in de comments al aangaf en Tomcat + JSP is voor Java nou ook niet direct de optimale keuze als het om pure snelheid gaat.

Zoals ik zeg, random gevonden

[Mugwump]

Gropah schreef op maandag 8 oktober 2018 @ 17:42:
[...]


Zoals ik zeg, random gevonden

Dat betwijfel ik. Neem aan dat je specifiek naar een dergelijke benchmark hebt gezocht dus zo willekeurig is het niet.

Het is ook meer een breder punt. Methodologie is bij benchmarks nogal belangrijk. Niet zelden kiest de benchmarker ook juist die zaken die zijn favoriet (of gewoon de eigen taal / database / applicatieserver / whatever) goed liggen maar verder niet direct relevant zijn voor real-life scenarios.

[Lethalis]

Hydra schreef op maandag 8 oktober 2018 @ 16:58:
[...]
Wat klopt er van het verhaal dat het trager is dan Go dan? Want dat verbaast me nogal.

Tsja, ik heb het vooral over het geheugenverbruik.

Qua processorbelasting wordt het een lastig verhaal, omdat een typische webapplicatie in Java, C# of Go meestal langer op I/O resources aan het wachten is dan zelf echt de processor te belasten.

Gezien ze allemaal goede async ondersteuning hebben, zullen ze in dat opzicht inderdaad gelijk opgaan.

Mijn vermoeden is dan ook dat het "custom framework" dat ze hebben gebruikt, erg slecht is geprogrammeerd

Een self hosted NancyFX app op Mono zou het wel prima hebben gedaan vermoed ik zo...

[ Voor 6% gewijzigd door Lethalis op 08-10-2018 18:37 ]

[Hydra]

Lethalis schreef op maandag 8 oktober 2018 @ 18:33:
Tsja, ik heb het vooral over het geheugenverbruik.

Geheugengebruik van .Net of geheugengebruik van het web framework. Want dat halen veel mensen ook nog eens door elkaar. Opsers klagen vaak over het geheugengebruik van "Java" maar wat er vooral veel geheugen gebruikt is het Spring framework. En ja, da's gewoon een afweging. Alles zelfbouwen (zoals in Go) kan, maar developers zijn een heel stuk duurder dan wat extra geheugen.

[Gropah]

Mugwump schreef op maandag 8 oktober 2018 @ 18:01:
[...]


Dat betwijfel ik. Neem aan dat je specifiek naar een dergelijke benchmark hebt gezocht dus zo willekeurig is het niet.

Het is ook meer een breder punt. Methodologie is bij benchmarks nogal belangrijk. Niet zelden kiest de benchmarker ook juist die zaken die zijn favoriet (of gewoon de eigen taal / database / applicatieserver / whatever) goed liggen maar verder niet direct relevant zijn voor real-life scenarios.

Of ze proberen een zwaar algoritme, krijgen dat niet draaiend voor 1 taal omdat het te traag is, dus gaan ze het optimaliseren, maar brengen die optimalisatie's niet terug naar de eerdere geschreven programma's.

Of ze schrijven wel idiomatic (en dus vaak snelle) code in de eerste taal en proberen dat vervolgens 1:1 te kopieren naar andere talen.

Er is altijd wel wat tegen te vinden en dat is inderdaad het moeilijke aan benchmarken tussen verschillende talen.

[Sandor_Clegane]

Lethalis schreef op maandag 8 oktober 2018 @ 18:33:
[...]

Tsja, ik heb het vooral over het geheugenverbruik.

Qua processorbelasting wordt het een lastig verhaal, omdat een typische webapplicatie in Java, C# of Go meestal langer op I/O resources aan het wachten is dan zelf echt de processor te belasten.

Gezien ze allemaal goede async ondersteuning hebben, zullen ze in dat opzicht inderdaad gelijk opgaan.

Mijn vermoeden is dan ook dat het "custom framework" dat ze hebben gebruikt, erg slecht is geprogrammeerd

Een self hosted NancyFX app op Mono zou het wel prima hebben gedaan vermoed ik zo...

Als je snel wilt moet je denk ik Suave of Giraffe eens proberen op .Net core. Is vele malen sneller dan Mono.

Hydra schreef op maandag 8 oktober 2018 @ 19:01:
[...]


Geheugengebruik van .Net of geheugengebruik van het web framework. Want dat halen veel mensen ook nog eens door elkaar. Opsers klagen vaak over het geheugengebruik van "Java" maar wat er vooral veel geheugen gebruikt is het Spring framework. En ja, da's gewoon een afweging. Alles zelfbouwen (zoals in Go) kan, maar developers zijn een heel stuk duurder dan wat extra geheugen.

Dit ook, mijn kleine webserver benchmarken met Apachebench komt niet over de 20MB volgens mij, dat is met een paar 1000 connecties. En dat is niet gewoon 200 OK, maar daadwerkelijk een pagina serveren.

[ Voor 30% gewijzigd door Sandor_Clegane op 08-10-2018 20:19 ]

[gekkie]

Ah fijn whoopsje van Google door een datalekje in Google+ niet te melden, nu gooien ze het hele platform maar plat. Achja komt er ook eindelijk eens een einde aan dat zieltogende platform.

[Mugwump]

Gropah schreef op maandag 8 oktober 2018 @ 19:40:
[...]

Of ze proberen een zwaar algoritme, krijgen dat niet draaiend voor 1 taal omdat het te traag is, dus gaan ze het optimaliseren, maar brengen die optimalisatie's niet terug naar de eerdere geschreven programma's.

Of ze schrijven wel idiomatic (en dus vaak snelle) code in de eerste taal en proberen dat vervolgens 1:1 te kopieren naar andere talen.

Er is altijd wel wat tegen te vinden en dat is inderdaad het moeilijke aan benchmarken tussen verschillende talen.

Nee daarom. Op zich worden er bijvoorbeeld in de aangehaalde benchmark best aardige kwalitatieve punten aangehaald met betrekking tot PHP.
Doorgaans komt die taal ook wel een beetje aan de onderkant uit de meeste benchmarks.

[Sandor_Clegane]

Voor de gein eens een benchmark gedraaid:

code:

user@hephaestus:~/development/projects/server$ ab -n 100000 -c 50 http://server.domain.org:8181/static/login.html
This is ApacheBench, Version 2.3 <$Revision: 1807734 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking server.domain.org (be patient)
Completed 10000 requests
Completed 20000 requests
Completed 30000 requests
Completed 40000 requests
Completed 50000 requests
Completed 60000 requests
Completed 70000 requests
Completed 80000 requests
Completed 90000 requests
Completed 100000 requests
Finished 100000 requests


Server Software:        Microsoft-NetCore/2.0
Server Hostname:        server.domain.org
Server Port:            8181

Document Path:          /static/login.html
Document Length:        4089 bytes

Concurrency Level:      50
Time taken for tests:   16.056 seconds
Complete requests:      100000
Failed requests:        0
Total transferred:      422000000 bytes
HTML transferred:       408900000 bytes
Requests per second:    6228.03 [#/sec] (mean)
Time per request:       8.028 [ms] (mean)
Time per request:       0.161 [ms] (mean, across all concurrent requests)
Transfer rate:          25666.31 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.2      0       2
Processing:     1    8   4.1      7      41
Waiting:        1    8   4.1      7      41
Total:          1    8   4.1      7      41

Percentage of the requests served within a certain time (ms)
  50%      7
  66%      9
  75%      9
  80%     10
  90%     13
  95%     17
  98%     20
  99%     22
 100%     41 (longest request)

Is mijn eigen webservertje dat draait op .Net Core via de HTTP listener, nog niet zo efficiënt als zou kunnen daar hij nogal wat logged naar het console.

Load op de machine:



Niet heel erg gek dacht ik. Is met een daadwerkelijke pagina en niet even een 200OK.
Draait op KUbuntu 18 nog wat.

[gold_dust]

Mugwump schreef op maandag 8 oktober 2018 @ 12:18:
Enkel kijken naar je eigen use case en constateren dat cloud 'iets is voor managers' is wel erg kortzichtig. Je kijkt hier specifiek naar 'even wat rekenkracht' aanschaffen. Ja een GPU machine fulltime aanzetten is al snel duurder dan de pure aanschaf van een machine en ja voor de prijzen die Azure vraagt kun je ook nog wel een paar uurtjes installatie doen. Maar je moet bij een beetje serieuze toepassing ook rekening houden met backups, monitoring en ga zo maar door. Vaak

...

Niet alleen gpu servers zijn te duur, dat geldt voor vrijwel elk type server. Er lijkt ook geen upselling te zijn, een basis vps met 1vCore, 1GB RAM en 20GB storage kost overal heel weinig maar als je een beetje een serieuze server gaat samenstellen is het niet meer interessant tenzij je nu meteen extra hardware nodig hebt.

[Sebazzz]

Misschien is het al genoemd maar wat ik vooral afvraag is of de virtuele machines in de cloud niet geknepen worden qua kloksnelheid.

[Mugwump]

gold_dust schreef op maandag 8 oktober 2018 @ 22:46:
[...]

Niet alleen gpu servers zijn te duur, dat geldt voor vrijwel elk type server. Er lijkt ook geen upselling te zijn, een basis vps met 1vCore, 1GB RAM en 20GB storage kost overal heel weinig maar als je een beetje een serieuze server gaat samenstellen is het niet meer interessant tenzij je nu meteen extra hardware nodig hebt.

Dat zei ik ook nergens. Sterker nog, die post ging nou juist over het feit dat je bij het fulltime draaien van IaaS nooit direct voordeliger uit gaat zijn.

[Lethalis]

Hydra schreef op maandag 8 oktober 2018 @ 19:01:
[...]
Geheugengebruik van .Net of geheugengebruik van het web framework. Want dat halen veel mensen ook nog eens door elkaar. Opsers klagen vaak over het geheugengebruik van "Java" maar wat er vooral veel geheugen gebruikt is het Spring framework. En ja, da's gewoon een afweging. Alles zelfbouwen (zoals in Go) kan, maar developers zijn een heel stuk duurder dan wat extra geheugen.

Golang is efficienter dan .NET. De web frameworks erboven verschillen erg van elkaar. Op Java kun je natuurlijk ook tig andere dingen kiezen ipv Spring.

Dat gezegd hebbende...

Sandor_Clegane schreef op maandag 8 oktober 2018 @ 21:03:
Voor de gein eens een benchmark gedraaid...

Niet heel erg gek dacht ik. Is met een daadwerkelijke pagina en niet even een 200OK.
Draait op KUbuntu 18 nog wat.

Dit zijn echt prima scores. .NET Core heeft serieuze stappen gezet. Tel daarbij op dat ik totaal geen zin heb om een Golang test app te bouwen voor deze test en je wint de discussie al bij voorbaat

Edit: @Gropah did it for me

Anyways, ik heb laatst op mijn laptop de ionide plugin voor vscode geinstalleerd. Echt fijn dat deze netjes de F# function signatures toont.

[Gropah]

Sandor_Clegane schreef op maandag 8 oktober 2018 @ 21:03:
Voor de gein eens een benchmark gedraaid:

code:

user@hephaestus:~/development/projects/server$ ab -n 100000 -c 50 http://server.domain.org:8181/static/login.html
This is ApacheBench, Version 2.3 <$Revision: 1807734 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking server.domain.org (be patient)
Completed 10000 requests
Completed 20000 requests
Completed 30000 requests
Completed 40000 requests
Completed 50000 requests
Completed 60000 requests
Completed 70000 requests
Completed 80000 requests
Completed 90000 requests
Completed 100000 requests
Finished 100000 requests


Server Software:        Microsoft-NetCore/2.0
Server Hostname:        server.domain.org
Server Port:            8181

Document Path:          /static/login.html
Document Length:        4089 bytes

Concurrency Level:      50
Time taken for tests:   16.056 seconds
Complete requests:      100000
Failed requests:        0
Total transferred:      422000000 bytes
HTML transferred:       408900000 bytes
Requests per second:    6228.03 [#/sec] (mean)
Time per request:       8.028 ~~~[ms] (mean)
Time per request:       0.161 ~~~[ms] (mean, across all concurrent requests)
Transfer rate:          25666.31 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.2      0       2
Processing:     1    8   4.1      7      41
Waiting:        1    8   4.1      7      41
Total:          1    8   4.1      7      41

Percentage of the requests served within a certain time (ms)
  50%      7
  66%      9
  75%      9
  80%     10
  90%     13
  95%     17
  98%     20
  99%     22
 100%     41 (longest request)

Is mijn eigen webservertje dat draait op .Net Core via de HTTP listener, nog niet zo efficiënt als zou kunnen daar hij nogal wat logged naar het console.

Load op de machine:

[Afbeelding: Apache]

Niet heel erg gek dacht ik. Is met een daadwerkelijke pagina en niet even een 200OK.
Draait op KUbuntu 18 nog wat.

Kon het niet laten en heb een soortgelijke gedaan maar dan voor Go:

code:

ab -n 100000 -c 50 http://localhost:8085/
This is ApacheBench, Version 2.3 <$Revision: 1706008 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking localhost (be patient)
Completed 10000 requests
Completed 20000 requests
Completed 30000 requests
Completed 40000 requests
Completed 50000 requests
Completed 60000 requests
Completed 70000 requests
Completed 80000 requests
Completed 90000 requests
Completed 100000 requests
Finished 100000 requests


Server Software:        
Server Hostname:        localhost
Server Port:            8085

Document Path:          /
Document Length:        103 bytes

Concurrency Level:      50
Time taken for tests:   4.576 seconds
Complete requests:      100000
Failed requests:        0
Total transferred:      22000000 bytes
HTML transferred:       10300000 bytes
Requests per second:    21851.17 [#/sec] (mean)
Time per request:       2.288 [ms] (mean)
Time per request:       0.046 [ms] (mean, across all concurrent requests)
Transfer rate:          4694.59 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    1   0.2      1       2
Processing:     0    1   0.3      1       7
Waiting:        0    1   0.4      1       5
Total:          0    2   0.3      2       8

Percentage of the requests served within a certain time (ms)
  50%      2
  66%      2
  75%      2
  80%      2
  90%      3
  95%      3
  98%      3
  99%      3
 100%      8 (longest request)

Jou pagina is iets groter, en weet niet of template of wat dan ook. Hier in ieder geval de code die ik heb gerund:

code:

package main

import (
    "net/http"
    "fmt"
    "log"
)

var page = `<!DOCTYPE html>
<html>
<head>
<title>Basic Web Page</title>
</head>
<body>
Hello World!
</body>
</html>`

func handler(w http.ResponseWriter, r *http.Request) {
    fmt.Fprintf(w, page)
    w.WriteHeader(200)
}

func main() {
    http.HandleFunc("/", handler)
    log.Fatal(http.ListenAndServe(":8085", nil))
}

Voor load


op een i7-7700HQ (4 cores, 8 thread) met 16GB geheugen, ubuntu 16.04

edit: als je wat meer info geeft kunnen we wellicht meer apples to apples comparison doen?

[Lethalis]

Gropah schreef op maandag 8 oktober 2018 @ 23:52:
[...]
Kon het niet laten en heb een soortgelijke gedaan maar dan voor Go:

Omdat ik het geheugengebruik niet duidelijk vond, hier jouw programma op Windows 10:



Amper 2MB.

Daarnaast even voor @Hydra en @Sandor_Clegane : dit komt voor een groot deel door de static compilation en linking in Golang. In .NET worden assemblies echter in hun geheel geladen momenteel, dus als jij functie X uit assembly Y nodig hebt, wordt de hele assembly geladen.

Microsoft is voor .NET Core 3 met een IL linker bezig:

https://github.com/dotnet/core/issues/915

Dus in de toekomst zal .NET hierdoor een stuk efficiënter worden.

[ Voor 42% gewijzigd door Lethalis op 09-10-2018 08:21 ]

[Hydra]

Lethalis schreef op dinsdag 9 oktober 2018 @ 08:12:
Daarnaast even voor @Hydra en @Sandor_Clegane : dit komt voor een groot deel door de static compilation en linking in Golang. In .NET worden assemblies echter in hun geheel geladen momenteel, dus als jij functie X uit assembly Y nodig hebt, wordt de hele assembly geladen.

Dat is wel apart. Weet je dat zeker? Java laadt alleen de classes die nodig zijn uit een Jar. Als je dan bijvoorbeeld Spring gebruikt heb je alsnog ongeveer de hele Jar omdat al die classes naar elkaar verwijzen, maar als je uit Guava een enkele collection gebruikt wordt alleen die geladen.

[ThomasG]

Ik vind het toch wel intressant dat er zoveel Tweakers zijn die Go gebruiken. In mijn industrie/sector staat Go bekent als "de programmeertaal voor net afgestudeerde Google medewerkers die niet kunnen programmeren". No offense

Je kunt relatief snel leuke applicaties bouwen met Go. Er zitten - in ieder geval voor mijn sector - te veel nadelen (als in: features die missen, waardoor programmeerfouten [geen syntax fouten] er makkelijker insluipen) aan om het überhaupt te overwegen. Het kan zijn dat dát inmiddels deels achterhaalt is natuurlijk.

[Lethalis]

Hydra schreef op dinsdag 9 oktober 2018 @ 08:34:
[...]
Dat is wel apart. Weet je dat zeker? Java laadt alleen de classes die nodig zijn uit een Jar. Als je dan bijvoorbeeld Spring gebruikt heb je alsnog ongeveer de hele Jar omdat al die classes naar elkaar verwijzen, maar als je uit Guava een enkele collection gebruikt wordt alleen die geladen.

Voor zover ik kan vinden gebeuren er 2 dingen:
- Het laden van het bestand / assembly
- Het laden van types

Het laden van de types gaat on demand, maar hij moet wel het bestand eerst laden om een type te laden. Hiervoor zul je minimaal een soort register moeten laden met alle types er in en waar je ze kunt vinden.

Gebruik je die IL linker, dan hoeft hij minder te laden, omdat je alleen de dingen aan boord hebt die nodig zijn.

Maar goed, Microsoft heeft met .NET Core ook andere stappen gezet, door sowieso de assemblies verder op te splitsen. Het hele framework is veel meer in kleinere modules opgezet.

ThomasG schreef op dinsdag 9 oktober 2018 @ 09:16:
Ik vind het toch wel intressant dat er zoveel Tweakers zijn die Go gebruiken. In mijn industrie/sector staat Go bekent als "de programmeertaal voor net afgestudeerde Google medewerkers die niet kunnen programmeren". No offense

Ja, en PHP staat bekend als <vul hier maar een denigrerend stukje in>.

Toch gebruiken ontelbaar veel mensen PHP.

En ik geef het niet graag toe, maar een groot project waar ik aan werk bestaat voor een deel uit *trom geroffel* Visual Basic .NET.

Daarom moet ik 's avonds ook soms even iets in F# of in Kotlin bouwen, om die roestige bitjes in mijn hoofd weer te sorteren die allemaal van een brug proberen te springen.

Gelukkig doe ik ook een hoop C#. Het zou nog veel meer C# - en misschien zelfs wel F# - zijn als mijn directe collega niet zo'n VB fan zou zijn

Golang heb ik vooral onderzocht vanwege zijn efficiency, maar uiteindelijk niet toegepast op mijn werk.

[ Voor 33% gewijzigd door Lethalis op 09-10-2018 09:34 ]

[TheNephilim]

Mooie discussies hier! Had ook niet gedacht dat er zoveel developers hier zitten die iets met Go doen. Iemand ervaringen met Rust?

[Sandor_Clegane]

Gropah schreef op maandag 8 oktober 2018 @ 23:52:
[...]


Kon het niet laten en heb een soortgelijke gedaan maar dan voor Go:

code:

ab -n 100000 -c 50 http://localhost:8085/
This is ApacheBench, Version 2.3 <$Revision: 1706008 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking localhost (be patient)
Completed 10000 requests
Completed 20000 requests
Completed 30000 requests
Completed 40000 requests
Completed 50000 requests
Completed 60000 requests
Completed 70000 requests
Completed 80000 requests
Completed 90000 requests
Completed 100000 requests
Finished 100000 requests


Server Software:        
Server Hostname:        localhost
Server Port:            8085

Document Path:          /
Document Length:        103 bytes

Concurrency Level:      50
Time taken for tests:   4.576 seconds
Complete requests:      100000
Failed requests:        0
Total transferred:      22000000 bytes
HTML transferred:       10300000 bytes
Requests per second:    21851.17 [#/sec] (mean)
Time per request:       2.288 ~~~[ms] (mean)
Time per request:       0.046 ~~~[ms] (mean, across all concurrent requests)
Transfer rate:          4694.59 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    1   0.2      1       2
Processing:     0    1   0.3      1       7
Waiting:        0    1   0.4      1       5
Total:          0    2   0.3      2       8

Percentage of the requests served within a certain time (ms)
  50%      2
  66%      2
  75%      2
  80%      2
  90%      3
  95%      3
  98%      3
  99%      3
 100%      8 (longest request)

Jou pagina is iets groter, en weet niet of template of wat dan ook. Hier in ieder geval de code die ik heb gerund:

code:

package main

import (
    "net/http"
    "fmt"
    "log"
)

var page = `<!DOCTYPE html>
<html>
<head>
<title>Basic Web Page</title>
</head>
<body>
Hello World!
</body>
</html>`

func handler(w http.ResponseWriter, r *http.Request) {
    fmt.Fprintf(w, page)
    w.WriteHeader(200)
}

func main() {
    http.HandleFunc("/", handler)
    log.Fatal(http.ListenAndServe(":8085", nil))
}

Voor load
[Afbeelding]

op een i7-7700HQ (4 cores, 8 thread) met 16GB geheugen, ubuntu 16.04

edit: als je wat meer info geeft kunnen we wellicht meer apples to apples comparison doen?

Die van mij doet toch echt wel meer gok ik, het is wel mijn eigen maar is toch een redelijk full featured webserver. De pagina staat op disk en wordt dus niet mee ge-compileert, deze moet dus ook ingelezen worden etc. etc.

Ik zal eens kijken wat ik kan strippen.

Kom bij dat het nog in de debugger runt.

[Hydra]

Gropah schreef op maandag 8 oktober 2018 @ 23:52:
Requests per second: 21851.17 [#/sec] (mean)

Wel interessant. Ik heb jouw test tegen jouw Go code gerund op mijn machine:

code:

ab -n 100000 -c50 http://localhost:8085/

Go:                Requests per second:    6922.55 
Java/Netty:    Requests per second:    4332.12
Java/Jetty:     Requests per second:    6048.01

Dat Netty trager is verbaast me wel, da's een asyn io generieke server component die nogal snel zou moeten zijn. Jetty is een semi-servlet engine. M'n vermoeden is dat Netty trager is omdat 'ie sowieso van die in-memory HTML die ik serveer iedere keer een kopie van de buffer doet.

Misschien eens 'vals' spelen en zelf een doodsimpele HTTP server te maken die domweg altijd dezelfde HTML serveert. Kijken wat dat doet.

[Sandor_Clegane]

Na wat gestript te hebben, de complete server eigenlijk, kom ik tot deze:

code:

// Learn more about F# at http://fsharp.org

open System
open System.Net
open System.Threading
open System.IO
open System.Text

let cts = new CancellationTokenSource()

let html = 
    """
    <!doctype html>
    <html lang="en">
        <head>
            <meta charset="utf-8">
            <title>Hello World</title>
            <meta name="description" content="Setup">
            <meta name="author" content="Author"
        </head>

        <body>
            <h1>Hello World!</h1>
        </body>
    </html>
    """


let stream = new MemoryStream(Encoding.UTF8.GetBytes(html))

let processRequest (context:HttpListenerContext)=
    async{
            context.Response.StatusCode <- 200     
            stream.Position <- 0L       
            stream.CopyTo(context.Response.OutputStream)
            stream.Flush()
            context.Response.Close()
        }

let startUpServer token =

    let srv = new HttpListener()
    srv.Prefixes.Add("http://*:8080/")
    srv.Start()
    
    let rec listen(srv:HttpListener, token) =
       async {
           let! ctx = Async.FromBeginEnd(srv.BeginGetContext,srv.EndGetContext)
           Async.Start(processRequest ctx)
           return! listen(srv, token)
    }
    Async.Start(listen(srv, token))


[<EntryPoint>]
let main argv =
    printfn "Running....."
    startUpServer cts.Token
    Console.ReadLine() |> ignore
    0 // return an integer exit code

Deze doet het volgende:

code:

user@hephaestus:~/development/projects/server$ ab -n 100000 -c 50 http://localhost:8080/
This is ApacheBench, Version 2.3 <$Revision: 1807734 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking localhost (be patient)
Completed 10000 requests
Completed 20000 requests
Completed 30000 requests
Completed 40000 requests
Completed 50000 requests
Completed 60000 requests
Completed 70000 requests
Completed 80000 requests
Completed 90000 requests
Completed 100000 requests
Finished 100000 requests


Server Software:        Microsoft-NetCore/2.0
Server Hostname:        localhost
Server Port:            8080

Document Path:          /
Document Length:        346 bytes

Concurrency Level:      50
Time taken for tests:   7.561 seconds
Complete requests:      100000
Failed requests:        202
   (Connect: 0, Receive: 0, Length: 202, Exceptions: 0)
Total transferred:      45130108 bytes
HTML transferred:       34530108 bytes
Requests per second:    13225.42 [#/sec] (mean)
Time per request:       3.781 [ms] (mean)
Time per request:       0.076 [ms] (mean, across all concurrent requests)
Transfer rate:          5828.75 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    1   0.4      1       4
Processing:     0    3   2.0      2      16
Waiting:        0    2   2.0      1      15
Total:          0    4   1.9      3      17

Percentage of the requests served within a certain time (ms)
  50%      3
  66%      4
  75%      4
  80%      5
  90%      7
  95%      8
  98%     10
  99%     10

Hij gaat van 20MB naar 14MB. Het lijkt erop dat .Net een deel reserveert en dit dan weer teruggeeft.
Misschien kan het nog wat efficiënter, maar het is nu al zo barebones dat je er eigen weinig mee kunt.

Dit is op een ThreadRipper 1950X met 32GB RAM en KUbuntu.

Edit: Het viel me op dat er verbindingen werden gedropped, dus na wat aanpassingen in de main loop kom ik tot de volgende:

code:

let startUpServer token =

    let srv = new HttpListener()
    srv.Prefixes.Add("http://*:8080/")
    srv.Start()
    
    let rec listen(srv:HttpListener, token) =
       async {
           let! ctx = Async.FromBeginEnd(srv.BeginGetContext,srv.EndGetContext)
           do! processRequest ctx
           return! listen(srv, token)
    }
    Async.Start(listen(srv, token))

Deze doet:

code:

user@hephaestus:~/development/projects/server$ ab -n 100000 -c 50 http://localhost:8080/
This is ApacheBench, Version 2.3 <$Revision: 1807734 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking localhost (be patient)
Completed 10000 requests
Completed 20000 requests
Completed 30000 requests
Completed 40000 requests
Completed 50000 requests
Completed 60000 requests
Completed 70000 requests
Completed 80000 requests
Completed 90000 requests
Completed 100000 requests
Finished 100000 requests


Server Software:        Microsoft-NetCore/2.0
Server Hostname:        localhost
Server Port:            8080

Document Path:          /
Document Length:        346 bytes

Concurrency Level:      50
Time taken for tests:   10.065 seconds
Complete requests:      100000
Failed requests:        0
Total transferred:      45200000 bytes
HTML transferred:       34600000 bytes
Requests per second:    9935.55 [#/sec] (mean)
Time per request:       5.032 [ms] (mean)
Time per request:       0.101 [ms] (mean, across all concurrent requests)
Transfer rate:          4385.61 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.1      0       2
Processing:     1    5   2.5      4      20
Waiting:        1    5   2.5      4      20
Total:          2    5   2.5      4      20

Percentage of the requests served within a certain time (ms)
  50%      4
  66%      4
  75%      5
  80%      6
  90%      8
  95%     12
  98%     14
  99%     15
 100%     20 (longest request)

Deze dropt geen enkele request, maar is wel 3000 verbindingen trager. Denk dat het komt door ThreadPool exhaustion aangezien do! net iets anders werkt dan Async.Start onder de motorkap. Kan het niet echt onderbouwen, maar dat is het enige dat ik zo kan bedenken aangezien do! blocked en Async.Start fire en forget is.

[ Voor 26% gewijzigd door Sandor_Clegane op 09-10-2018 11:32 ]

[DeluxZ]

Om jullie wat tijd te besparen https://www.techempower.c...-r16&hw=ph&test=plaintext

aspcore doet 6,970,937 requests/s (?)

[ Voor 25% gewijzigd door DeluxZ op 09-10-2018 11:33 ]

[Hydra]

DeluxZ schreef op dinsdag 9 oktober 2018 @ 11:32:
Om jullie wat tijd te besparen https://www.techempower.c...-r16&hw=ph&test=plaintext

aspcore doet 6,970,937 requests/s (?)

Wie wat doet verschilt nogal met welke tab je selecteert

[DeluxZ]

Hydra schreef op dinsdag 9 oktober 2018 @ 11:38:
[...]


Wie wat doet verschilt nogal met welke tab je selecteert

Klopt, daarom is de link naar de plaintext test

[Lethalis]

Sandor_Clegane schreef op dinsdag 9 oktober 2018 @ 10:21:
F#

Ik heb het zowaar voor elkaar dat mijn eerste F# probeersel iets zinnigs lijkt te doen (printers uit een database tonen):

code:

open System
open System.Data
open System.Data.SqlClient

type ConnectionStringParams = { 
    DataSource: string; 
    Catalog: string; 
    UserName: string; 
    Password: string; 
}

let getConnectionString (connectionStringParams: ConnectionStringParams) =
    let b = new SqlConnectionStringBuilder()
    b.DataSource <- connectionStringParams.DataSource
    b.InitialCatalog <- connectionStringParams.Catalog
    b.UserID <- connectionStringParams.UserName
    b.Password <- connectionStringParams.Password
    b.ToString()

let openConnection connectionString =
    let connection = new SqlConnection(connectionString)
    try 
        connection.Open()
        Ok (connection :> IDbConnection)
    with
        | :? SqlException as ex -> Error ex;

let getPrinters (dbConnection:IDbConnection) =
    seq {
        let cmd = dbConnection.CreateCommand()
        cmd.CommandText <- "SELECT prn_Printernaam FROM Printers"
        use rd = cmd.ExecuteReader()
        while rd.Read() do
            yield rd.GetString(0)
    }

[<EntryPoint>]
let main argv =
    let connectionStringParams = { DataSource = "server"; Catalog = "development"; UserName = "pietje"; Password = "1234" }
    let connectionString = getConnectionString connectionStringParams
    printfn "Connecting to: %s.%s" connectionStringParams.DataSource connectionStringParams.Catalog

    let connection = openConnection connectionString
    match connection with
    | Ok conn -> 
        printfn "Connection established"
        let printers = getPrinters conn
        for printer in printers do
            printfn "%i %s (%s)" printer.Printernr printer.Naam printer.Omschrijving
        conn.Dispose()
        0
    | Error ex -> 
        printfn "Error connecting to server: %s" ex.Message
        1

Het is even wennen, maar ik vind het wel interessant

Volgende is dat ik naar het inlezen van configuratiebestanden ga kijken, want SQL connection parameters in de code wil je natuurlijk niet.

[ Voor 10% gewijzigd door Lethalis op 10-10-2018 13:15 ]

[Sandor_Clegane]

Lethalis schreef op woensdag 10 oktober 2018 @ 00:19:
[...]

Ik heb het zowaar voor elkaar dat mijn eerste F# probeersel iets zinnigs lijkt te doen (printers uit een database tonen):


[...]

Het is even wennen, maar ik vind het wel interessant

Volgende is dat ik naar het inlezen van configuratiebestanden ga kijken, want SQL connection parameters in de code wil je natuurlijk niet.

Yay!

Enige ding, weet niet of het aan de F# versie ligt die je gebruikt, maar sinds 4.1 denk ik heb je een Result<Ok,Error> type. Scheelt weer een type definitie.

[Lethalis]

Sandor_Clegane schreef op woensdag 10 oktober 2018 @ 06:30:
[...]
Yay!

Enige ding, weet niet of het aan de F# versie ligt die je gebruikt, maar sinds 4.1 denk ik heb je een Result<Ok,Error> type. Scheelt weer een type definitie.

Nee het ligt aan mij Result<Ok,Error> werkt inderdaad. Bedankt. Ik heb de code in mijn bericht aangepast (meteen wat variabelen beter genoemd en ik geef nu de hele Exception terug ipv alleen de Message).

Alleen zie ik nog even niet hoe ik de F# versie kan opvragen voor .NET Core

Ik heb alleen .NET Core 2.1.402 geïnstalleerd en VS Code met de laatste Ionide-fsharp plugin.

MSDN: Announcing F# 4.5 | .NET Blog

Waarschijnlijk heb ik dan sowieso F# 4.5.

[ Voor 8% gewijzigd door Lethalis op 10-10-2018 09:46 ]

[RayNbow]

RobIII schreef op woensdag 3 oktober 2018 @ 22:19:
WindowsKey + .

[Afbeelding]

_{Ik ging altijd naar https://emojipedia.org om daar te copy/pasten}

Ik kom er net achter dat het best wel uitmaakt wat je toetsenbordtaal is als je emoji's probeert op te zoeken. Ik maar Engelse termen intikken, om vervolgens gegroet te worden met de melding dat er geen emoji gevonden kan worden. Zie ik dat m'n toetsenbord op NL i.p.v. EN staat.

[.oisyn]

RayNbow schreef op woensdag 10 oktober 2018 @ 17:45:
[...]

Ik kom er net achter dat het best wel uitmaakt wat je toetsenbordtaal is als je emoji's probeert op te zoeken. Ik maar Engelse termen intikken, om vervolgens gegroet te worden met de melding dat er geen emoji gevonden kan worden. Zie ik dat m'n toetsenbord op NL i.p.v. EN staat.

Ik kan helemaal niets vinden, omdat ik een custom layout heb wat blijkbaar niet meer compatbile is met het moderne Windows . Kan ook niet meer van taal switchen, ookal heb ik zowel Engels als Nederlands geconfigureerd. Ook het onscreen keyboard kan ik niet activeren.

Hij blijft ook alleen maar zeggen dat ik een language pack moet installeren.

.edit: Oh wacht, blijkbaar vind hij dat English (US) geen valide taal is. Als ik English (UK) ook installeer, dan mag ik ineens switchen tussen NL en EN(UK). Maar EN(US) staat er niet tussen. Ook al is dat mijn Windows taal. Nu ik een keer geswitched heb werkt de emoji search wel.

En waarom doet text-to-speech en handwriting het niet in NL? Ik heb er wel voor gekozen om dat te installeren.

.edit: ok wow, taal op NL gezet, sign out/sign in, English (US) verwijderd, English (US) opnieuw toegevoegd, nu werkt het allemaal wel goed

[ Voor 33% gewijzigd door .oisyn op 10-10-2018 18:22 ]

[RayNbow]

Mjah... het taalgebeuren is nog steeds buggy in Windows. Op 1 werkmachine komt er soms naast de reeds geinstalleerde EN/US en JP toetsenborden opeens een 3e ongevraagde EN/UK te voorschijn (die past weer verdwijnt bij een reboot).

[.oisyn]

Huub huub, barbatruc

Nieuw deel

[RobIII]

Negen pagina's nieuw deel alweer?

[DevWouter]

.oisyn schreef op woensdag 10 oktober 2018 @ 20:21:
Huub huub, barbatruc

Nieuw deel

En zoals altijd, vond ik het voorgaande deel beter

[.oisyn]

RobIII schreef op woensdag 10 oktober 2018 @ 20:28:
Negen pagina's nieuw deel alweer?

Ja even wat Lorem Ipsum posts gegenereerd voor verse content.

[azerty]

2 jaar voor een nieuw topic... Het gaat achteruit

[Sebazzz]

Ik vond het al een handige feature dat een nieuw deel automatisch bij je posthistorie komt, maar helaas...

[Vincentio]

Yeah mijn gepinde tabs eindelijk weer eens updaten.

[Matis]

Wel fijn deze manier, hoef ik heb TVP meer te maken

[ Voor 4% gewijzigd door Matis op 10-10-2018 22:58 ]

[Antrax]

azerty schreef op woensdag 10 oktober 2018 @ 20:41:
2 jaar voor een nieuw topic... Het gaat achteruit

Het is inderdaad wat langzamer gegaan. Misschien had de zomervakantie ermee te maken?

[Sandor_Clegane]

Antrax schreef op donderdag 11 oktober 2018 @ 00:05:
[...]

Het is inderdaad wat langzamer gegaan. Misschien had de zomervakantie ermee te maken?

Het is net als met computers in het algemeen, hoe sneller alles wordt hoe trager alles gaat.

[RayNbow]

azerty schreef op woensdag 10 oktober 2018 @ 20:41:
2 jaar voor een nieuw topic... Het gaat achteruit

Tijd om alle pagina's van deze topicreeks te scrapen, een NN trainen, botje scripten en dan op de volautomatische piloot dit topic volgooien met content.

[azerty]

RayNbow schreef op donderdag 11 oktober 2018 @ 07:11:
[...]

Tijd om alle pagina's van deze topicreeks te scrapen, een NN trainen, botje scripten en dan op de volautomatische piloot dit topic volgooien met content.

Het gaat wel wat opvallen als plots alle posts van 1 persoon komen, en die persoon vervolgens met zichzelf in discussie gaat

[Antrax]

RayNbow schreef op donderdag 11 oktober 2018 @ 07:11:
[...]

Tijd om alle pagina's van deze topicreeks te scrapen, een NN trainen, botje scripten en dan op de volautomatische piloot dit topic volgooien met content.

Ja joh, @Inspector, doet eens een aapje (api.tweakers.net) flansen voor ons!

* Antrax gaat anders zelf wel even naar HQ..

[Mitchell]

Een nieuw deel! Meteen maar even reageren zodat dit in "Mijn topics" staat.

[ThomasG]

Mitchell schreef op donderdag 11 oktober 2018 @ 08:56:
Een nieuw deel! Meteen maar even reageren zodat dit in "Mijn topics" staat.

Goed idee, want dit topic verlies je anders nogal snel uit het oog

[Firesphere]

14 pages... wut? Stel spammers dat jullie zijn!

[Creepy]

.oisyn doet iets met time travel....

[Merethil]

In webdesign (Webdesign, Markup & Clientside Scripting) staat 'ie nog gewoon als Devschuur CC 11 en open! Maar als je erop klikt ga je dus naar de oude die is gesloten.... Duidelijk!

[CodeCaster]

Hydra schreef op dinsdag 9 oktober 2018 @ 08:34:
[...]


Dat is wel apart. Weet je dat zeker? Java laadt alleen de classes die nodig zijn uit een Jar. Als je dan bijvoorbeeld Spring gebruikt heb je alsnog ongeveer de hele Jar omdat al die classes naar elkaar verwijzen, maar als je uit Guava een enkele collection gebruikt wordt alleen die geladen.

Nee. .NET laadt in een webcontext alle assemblies, en in een standalone-applicatie on demand.

Met "laden" wordt hier bedoeld dat de DLL's (een assembly bestaat uit één of meer DLL's) worden gelezen om hun metadatatabel te parsen, zodat de runtime weet welke types (klassen/structs) er zijn in die assembly.

Pas bij het eerste keer aanroepen van een methode (of field, of ...) in een type wordt de IL van dat type daadwerkelijk gecompileerd naar native code door de JITter.

Zie ook Back to Basics: When does a .NET Assembly Dependency get loaded.

Reminds me, ik moet CLR via C# nog steeds uitlezen. Nog een week of twee, dan zit het motorseizoen er wat woonwerkverkeer betreft weer op voor mij, dus kan ik weer in de trein gaan zitten lezen.

[ Voor 22% gewijzigd door CodeCaster op 11-10-2018 11:32 ]

[Hydra]

Thanks voor de uitleg @CodeCaster !

In other news:

https://niels.page

Als iemand de zijne aan wil vragen: https://get.page

[DynaSpan]

Hydra schreef op donderdag 11 oktober 2018 @ 11:42:
Thanks voor de uitleg @CodeCaster !

In other news:

https://niels.page

Als iemand de zijne aan wil vragen: https://get.page

Voor mij meer dan $100,- per jaar... Ik pas

[.oisyn]

Hydra schreef op donderdag 11 oktober 2018 @ 11:42:
https://niels.page

Ah, customized page toiletpapier. Handig!

DynaSpan schreef op donderdag 11 oktober 2018 @ 11:47:
[...]


Voor mij meer dan $100,- per jaar... Ik pas

He who what now? Ik kom op €13,nogwat per jaar (€9,nogwat eerste jaar)

Antrax schreef op donderdag 11 oktober 2018 @ 08:07:
[...]

Ja joh, @Inspector, doet eens een aapje (api.tweakers.net) flansen voor ons!

* Antrax gaat anders zelf wel even naar HQ..

t.net heeft al een API, het heet HTTP

[ Voor 68% gewijzigd door .oisyn op 11-10-2018 11:54 ]

[DynaSpan]

@.oisyn mijn naam is blijkbaar 'premium'. Dat krijg je als je naar een Italiaanse stad bent vernoemd ;p (mijn naam is Milan).

[.oisyn]

Wat een smeerpoetsen bij GoDaddy



Wie ziet het?

[RobertMe]

.oisyn schreef op donderdag 11 oktober 2018 @ 11:58:
Wat een smeerpoetsen bij GoDaddy

[Afbeelding]

Wie ziet het?

oatyn.nl?

En "Premium" gebeurd wel meer. "robert.page" is ook al premium. Mag je ook $300+ aftikken bij namecheap en net onder de $300 bij GoDaddy. Beetje geldklopperij zo.

[Koenvh]

@.oisyn oatyn of het feit dat het tweede jaar vele malen duurder is?

[CodeCaster]

.oatyn schreef op donderdag 11 oktober 2018 @ 11:58:
Wat een smeerpoetsen bij GoDaddy

[Afbeelding]

Wie ziet het?

Ik niet?

[.oisyn]

Koenvh schreef op donderdag 11 oktober 2018 @ 12:00:
@.oisyn oatyn of het feit dat het tweede jaar vele malen duurder is?

Dat eerste. oisyn.nl heb ik zelf al, dus die is bezet. Gaan ze gewoon maar wat letters veranderen . Je zou het maar niet zien.

[Koenvh]

.oisyn schreef op donderdag 11 oktober 2018 @ 12:01:
[...]


Dat eerste. oisyn.nl heb ik zelf al, dus die is bezet. Gaan ze gewoon maar wat letters veranderen . Je zou het maar niet zien.

Handig zulke suggesties toch?
Wel beter dan "DEZE NAAM IS BESCHIKBAAR!" "Oh, toch niet, sorry"

Ik zie het nut van .page nog niet echt, maar dat kan ook aan mij liggen.

[.oisyn]

Koenvh schreef op donderdag 11 oktober 2018 @ 12:06:
Ik zie het nut van .page nog niet echt, maar dat kan ook aan mij liggen.

Mja, dat is mijn mening over gTLD's in het algemeen

[ThomasG]

.oisyn schreef op donderdag 11 oktober 2018 @ 12:07:
[...]


Mja, dat is mijn mening over gTLD's in het algemeen

Beetje hypocriete mening als je een gTLD als schuilnaamt hebt

[Koenvh]

.oisyn schreef op donderdag 11 oktober 2018 @ 12:07:
[...]


Mja, dat is mijn mening over gTLD's in het algemeen

Je hebt vast liever emojis in je domeinnaam dan zeker?
https://i❤.ws/

[.oisyn]

ThomasG schreef op donderdag 11 oktober 2018 @ 12:13:
[...]
Beetje hypocriete mening als je een gTLD als schuilnaamt hebt

[ThomasG]

.oisyn schreef op donderdag 11 oktober 2018 @ 12:13:
[...]

.oisyn

[.oisyn]

ThomasG schreef op donderdag 11 oktober 2018 @ 12:15:
[...]
.oisyn

Dat was meer gewoon creatief met leestekens . Maar zou ik er dan niet juist blij mee moeten zijn? Want nu kan ik in theorie mijn eigen gTLD kopen

[EddoH]

Hoe langer ik in de IT werk, hoe meer ik besef dat met welke technologie of taal ik werk geen enkele invloed heeft op mijn werkgeluk.

Maar damn wat lopen er een debiele, stinkende, arrogante, irritante, luidruchtige mensen rond in de IT en wat kunnen die je humeur beïnvloeden.

Ik werk liever in VB met een paar normale weldenkende gemanierde teamgenoten dan dat ik cutting edge research bij Google kan doen met een stelletje nerds met bovenstaande eigenschappen.

Fijne vrijdag allemaal trouwens.

[mcDavid]

.oisyn schreef op donderdag 11 oktober 2018 @ 12:18:
[...]


Dat was meer gewoon creatief met leestekens . Maar zou ik er dan niet juist blij mee moeten zijn? Want nu kan ik in theorie mijn eigen gTLD kopen

Heheh, ik zou dan eerder een mooi vrijstaand huis in de randstad kopen. Of een luxe jacht of zo.

[Lethalis]

EddoH schreef op vrijdag 12 oktober 2018 @ 10:14:
Hoe langer ik in de IT werk, hoe meer ik besef dat met welke technologie of taal ik werk geen enkele invloed heeft op mijn werkgeluk.

Dat kan ik mij echt moeilijk voorstellen.

Maar goed, ik moet dan ook regelmatig aan VB.NET projecten werken. Met Windows.Forms.

Het lukt mij nauwelijks om daar - in technisch opzicht - iets leuks van te maken voor mezelf.

[EddoH]

Lethalis schreef op vrijdag 12 oktober 2018 @ 10:54:
[...]

Dat kan ik mij echt moeilijk voorstellen.

Maar goed, ik moet dan ook regelmatig aan VB.NET projecten werken. Met Windows.Forms.

Het lukt mij nauwelijks om daar - in technisch opzicht - iets leuks van te maken voor mezelf.

Misschien heb ik het technisch dieptepunt nog niet echt ervaren
Maar in elk project kun je toch wel iets van je probleemoplossend vermogen danwel creativiteit kwijt?

[Lethalis]

EddoH schreef op vrijdag 12 oktober 2018 @ 10:57:
[...]
Misschien heb ik het technisch dieptepunt nog niet echt ervaren
Maar in elk project kun je toch wel iets van je probleemoplossend vermogen danwel creativiteit kwijt?

Ja dat wel. Ik kom ook vaak dingen tegen die waarschijnlijk een stuk ingewikkelder zijn dan wat de gemiddelde web developer tegenkomt.

Maar je krijgt wel het gevoel dat je niet mee met de tijd gaat.

Thuis speel ik dan ook met zo ongeveer alles dat "hip" is tegenwoordig. Vooral ook om mijn kennis een beetje uptodate te houden. Ik kan dan ook REST API's bouwen met .NET Core, kan met Angular overweg, enzovoorts.

En ik daag mezelf ook uit, door bijvoorbeeld iets heel anders te doen zoals Java en Kotlin. Of functional programming met F#.

Alleen elke keer dat ik dan weer op mijn werk naar VB.NET code zit te staren, krijg ik daar wel jeuk van

[Crazy D]

Lethalis schreef op vrijdag 12 oktober 2018 @ 11:04:
Alleen elke keer dat ik dan weer op mijn werk naar VB.NET code zit te staren, krijg ik daar wel jeuk van

Je moet er ook niet naar staren maar gewoon je werk doen

[Hydra]

Lethalis schreef op vrijdag 12 oktober 2018 @ 11:04:
Alleen elke keer dat ik dan weer op mijn werk naar VB.NET code zit te staren, krijg ik daar wel jeuk van

Tja. Jobs voor 't oprapen

[Alex)]

EddoH schreef op vrijdag 12 oktober 2018 @ 10:14:
Hoe langer ik in de IT werk, hoe meer ik besef dat met welke technologie of taal ik werk geen enkele invloed heeft op mijn werkgeluk.

Maar damn wat lopen er een debiele, stinkende, arrogante, irritante, luidruchtige mensen rond in de IT en wat kunnen die je humeur beïnvloeden.

Lethalis schreef op vrijdag 12 oktober 2018 @ 10:54:
[...]

Maar goed, ik moet dan ook regelmatig aan VB.NET projecten werken. Met Windows.Forms.

Het lukt mij nauwelijks om daar - in technisch opzicht - iets leuks van te maken voor mezelf.

Je kunt altijd nog buschauffeur worden

[EddoH]

Alex) schreef op vrijdag 12 oktober 2018 @ 13:43:
[...]


[...]

Je kunt altijd nog buschauffeur worden

Want in de bus zitten geen stinkende, asociale en irritante mensen?

[Alex)]

EddoH schreef op vrijdag 12 oktober 2018 @ 13:45:
[...]


Want in de bus zitten geen stinkende, asociale en irritante mensen?

Die zijn na 10 minuten weer opgerot, en daar hoef je verder niet naar te luisteren.

[BarôZZa]

EddoH schreef op vrijdag 12 oktober 2018 @ 10:14:
Hoe langer ik in de IT werk, hoe meer ik besef dat met welke technologie of taal ik werk geen enkele invloed heeft op mijn werkgeluk.

Maar damn wat lopen er een debiele, stinkende, arrogante, irritante, luidruchtige mensen rond in de IT en wat kunnen die je humeur beïnvloeden.

Ik werk liever in VB met een paar normale weldenkende gemanierde teamgenoten dan dat ik cutting edge research bij Google kan doen met een stelletje nerds met bovenstaande eigenschappen.

Fijne vrijdag allemaal trouwens.

Daarom werk ik al een tijd lang voornamelijk voor niet-IT bedrijven. IT werk vind ik prima, maar IT'ers zijn over het algemeen niet echt mijn ding. Momenteel de enige vaste programmeur voor een salesbedrijf. Heerlijk man, veel vrouwen en extraverte mensen die niet alleen over technische zaken willen praten.
Veel meer vrijheid en je werk wordt ook een stuk meer gewaardeerd. Niet alleen voor de meest complexe technische oplossing gaan, maar vooral met mensen meedenken, wat minstens zo'n grote uitdaging is.

Talen en techniek zijn niet meer dan een middel voor mij. Je kan jezelf helemaal gek maken door technisch zo vooruitstrevend mogelijk te zijn (in het verleden vaak gedaan en ook veel van geleerd), maar uiteindelijk vindt niemand het zo belangrijk als jij zelf.

[EddoH]

BarôZZa schreef op vrijdag 12 oktober 2018 @ 14:07:
[...]

Daarom werk ik al een tijd lang voornamelijk voor niet-IT bedrijven. IT werk vind ik prima, maar IT'ers zijn over het algemeen niet echt mijn ding. Momenteel de enige vaste programmeur voor een salesbedrijf. Heerlijk man, veel vrouwen en extraverte mensen die niet alleen over technische zaken willen praten.
Veel meer vrijheid en je werk wordt ook een stuk meer gewaardeerd. Niet alleen voor de meest complexe technische oplossing gaan, maar vooral met mensen meedenken, wat minstens zo'n grote uitdaging is.

Talen en techniek zijn niet meer dan een middel voor mij. Je kan jezelf helemaal gek maken door technisch zo vooruitstrevend mogelijk te zijn (in het verleden vaak gedaan en ook veel van geleerd), maar uiteindelijk vindt niemand het zo belangrijk als jij zelf.

Mee eens(al zou ik niet de enige ITer willen zijn). Ik heb nu ook een leuk en gevarieerd team van mensen, alleen moet je natuurlijk ook soms samenwerken met mensen die je niet 'kiest' (waar mijn rant uit voortkwam).

Sommige ITers hebben bij sollicitaties een aantal vragen of minimumeisen voor wat betreft tech-stacks, of andere technisch gerelateerde punten. Ik heb de afgelopen sollicitaties alleen gevraagd om eerst het team te mogen ontmoeten... De rest maakt me niet heel veel uit.

[Lethalis]

BarôZZa schreef op vrijdag 12 oktober 2018 @ 14:07:
[...]

Daarom werk ik al een tijd lang voornamelijk voor niet-IT bedrijven. IT werk vind ik prima, maar IT'ers zijn over het algemeen niet echt mijn ding. Momenteel de enige vaste programmeur voor een salesbedrijf. Heerlijk man, veel vrouwen en extraverte mensen die niet alleen over technische zaken willen praten.

Mja, op mijn vorige werk zat ik met 3 andere IT-ers. De rest was management, marketing, sales, etc. Dat was inderdaad veel gevarieerder qua mensen.

En de grap is dat ik nog met modernere techniek werkte ook...

Maar ja, salaris was daar het breekpunt voor mij... ze vonden daar 3000 per maand al veel.

Hydra schreef op vrijdag 12 oktober 2018 @ 11:58:
[...]
Tja. Jobs voor 't oprapen

Ja en nee. Ik ben namelijk wel aan een bepaald inkomen en voorwaarden gewend, waardoor ik alleen op senior functies kan solliciteren. En die zijn wel iets schaarser.

Daarnaast heb ik voor de rest wel erg veel vrijheid nu. Dag vrijnemen? Wil je eerder naar huis? Allemaal geen probleem (als je ergens al 10+ jaar werkt, word je toch ook anders behandeld).

Voor nieuwe projecten mag ik ook gewoon C# gebruiken. Het grote probleem is alleen de enorme hoeveelheid bestaande code in VB.NET waarvan het simpelweg niet nuttig is om deze te herschrijven.

[ Voor 37% gewijzigd door Lethalis op 12-10-2018 16:11 ]

[BladeSlayer1000]

Altijd leuk waarneer je een aantal nieuwe talen heb geleerd, je zin hebt om te gaan programmeren en de nieuwe talen toe te passen en geen idee hebt wat je wilt gaan maken...

Iemand tips?

[ Voor 4% gewijzigd door BladeSlayer1000 op 12-10-2018 20:04 ]

[Sandor_Clegane]

BladeSlayer1000 schreef op vrijdag 12 oktober 2018 @ 20:03:
Altijd leuk waarneer je een aantal nieuwe talen heb geleerd, je zin hebt om te gaan programmeren en de nieuwe talen toe te passen en geen idee hebt wat je wilt gaan maken...

Iemand tips?

Wat heb je geleerd?

[BladeSlayer1000]

Sandor_Clegane schreef op vrijdag 12 oktober 2018 @ 20:39:
[...]


Wat heb je geleerd?

Vue.js en native javascript ES6 (maakte hiervoor alleen gebruik van jquery). Ben ook sinds kort bezig met Laravel

[Sandor_Clegane]

BladeSlayer1000 schreef op vrijdag 12 oktober 2018 @ 20:41:
[...]


Vue.js en native javascript ES6 (maakte hiervoor alleen gebruik van jquery). Ben ook sinds kort bezig met Laravel

Ah, dat is niet echt mijn ding om eerlijk te zijn, alhoewel voor javascript vind ik Leaflet wel leuk om te programmeren. Als dat je ding is tenminste.

Een ToDo lijstje!

[Lethalis]

Sandor_Clegane schreef op vrijdag 12 oktober 2018 @ 20:45:
[...]
Een ToDo lijstje!

http://todomvc.com

Daar moest ik meteen aan denken

[ Voor 10% gewijzigd door Lethalis op 12-10-2018 23:59 ]

[Sandor_Clegane]

Lethalis schreef op vrijdag 12 oktober 2018 @ 23:58:
[...]

http://todomvc.com

Daar moest ik meteen aan denken

[EddoH]

Zie net op LinkedIn een vacature voor een C++ developer, inclusief de volgende tekst:

"Je toekomstige collega’s willen je dit alvast laten weten (-std=c11)"

??= in??/
clude <stdio.h>
??=de??/
fine Ob1101100 voi??/
d main(
??=de??/
fine Ob1011101101 pu??/
tchar(
??=de??/
fine Ob11001 in??/
t
??=de??/
fine Ob101 fo??/
r(
Ob1101100)??<ob11001
O0O<::>=??<0b01000110,0b00000000001101111,0b000000001110010,0b1100111,0b01100101,0b1110100,0b100000,0b1110100,0b1101000,
0b1100101,0b000100000,0b1100010,0b001110101,0b0000001111010,0b00001111010,0b0000001110111,0b00001101111,0b0000001110010,
0b00001100100,0b0000000100000,0b00000001100010,0b0001101001,0b1101110,0b001100111,0b00000000000001101111,0b000000101110,
0b100000,0b001010111,0b001100101,0b000100000,0b000001110011,0b00001101001,0b00001101101,0b1110000,0b001101100,0b1111001,
0b100000,0b001110111,0b1100001,0b1101110,0b1110100,0b100000,0b1111001,0b01101111,0b01110101,0b100001,0b1010 ??>;Ob11001
O000=0;Ob101;O000<0b101111;)Ob1011101101 O0O<:O000++:>);??>

Wut?

[.oisyn]

Ze zoeken een C++ developer, waarin trigraph sequences zijn verwijderd in C++17, en dan komen ze met C11 code aan?

[ Voor 9% gewijzigd door .oisyn op 13-10-2018 11:35 ]

[EddoH]

Dat en waarom zou je in hemelsnaam je code zo willen presenteren? Om te kijken of er mensen 'slim' genoeg zijn om het te ontcijferen?

[.oisyn]

Blijkbaar is iedereen die code kan compileren en uitvoeren geschikt voor de functie

[ Voor 8% gewijzigd door .oisyn op 13-10-2018 12:19 ]

[Marc3l]

BladeSlayer1000 schreef op vrijdag 12 oktober 2018 @ 20:41:
[...]


Vue.js en native javascript ES6 (maakte hiervoor alleen gebruik van jquery). Ben ook sinds kort bezig met Laravel

Een tijdje terug hier ook in verdiept, best krachtig. Kwam ook van alleen jquery. Wel een Ionic app gemaakt, gebruikt Angular dus wist het een en ander al wel.

Misschien iets maken waar je zelf tegenaanloopt?

Heb een app gemaakt om bij te houden hoeveel huisvuil ik heb weggegooid. Dat is bij ons nu betaald dus altijd overzichtje met kosten.

[DevWouter]

Lethalis schreef op vrijdag 12 oktober 2018 @ 23:58:
[...]

http://todomvc.com

Daar moest ik meteen aan denken

Yeah... Over todo lijstjes gesproken...

In mijn vrije tijd ben ik al meer dan een jaar (9 okt 2017 was de start) bezig om een programma te schrijven welk mij continue kan vertellen waar ik mee bezig moet zijn. Elke week was het meerdere avonden (en weekenden) waarbij ik achter de computer zat om het systeem te verbeteren. In principe is het een takenlijstje, maar dan wel met een paar features die je nergens anders ziet (behalve misschien TaskWarrior).

Ik ben denk ik nog 6 maanden bij de eerste echte release vandaan ben. Ik wil nog clientside encryptie toevoegen (het liefst met een private key die nooit verstuurd wordt), een admin gedeelte en de mogelijkheid om "lijstjes" te delen.

Als ik dan kijk naar demo's van JS libraries waarbij ze een takenlijstje bouwen in 10 minuten en dat vergelijk met "mijn missie" dan heb ik toch heel erg een dubbel gevoel

@BladeSlayer1000: Maak een systeem waarbij je ideeën voor projecten kan bijhouden zodat je in de toekomst (wanneer je weer een geniaal idee hebt) je ze kan toevoegen of juist kan gebruiken om iets te bouwen. En om je een idee te geven van hoe zo iets zou kunnen werken: https://github.com/open-source-ideas/open-source-ideas.

[kwaakvaak_v2]

DevWouter schreef op zaterdag 13 oktober 2018 @ 17:14:
[...]


Yeah... Over todo lijstjes gesproken...

In mijn vrije tijd ben ik al meer dan een jaar (9 okt 2017 was de start) bezig om een programma te schrijven welk mij continue kan vertellen waar ik mee bezig moet zijn. Elke week was het meerdere avonden (en weekenden) waarbij ik achter de computer zat om het systeem te verbeteren. In principe is het een takenlijstje, maar dan wel met een paar features die je nergens anders ziet (behalve misschien TaskWarrior).

Ik ben denk ik nog 6 maanden bij de eerste echte release vandaan ben. Ik wil nog clientside encryptie toevoegen (het liefst met een private key die nooit verstuurd wordt), een admin gedeelte en de mogelijkheid om "lijstjes" te delen.

Als ik dan kijk naar demo's van JS libraries waarbij ze een takenlijstje bouwen in 10 minuten en dat vergelijk met "mijn missie" dan heb ik toch heel erg een dubbel gevoel

Ik denk dat het woord wat je zoekt 'Overengineering' is

Maar voor een side project waarin je eigen grenzen probeert te verleggen is daar vrij weinig mis mee.

[DevWouter]

kwaakvaak_v2 schreef op zaterdag 13 oktober 2018 @ 17:24:
[...]


Ik denk dat het woord wat je zoekt 'Overengineering' is

Maar voor een side project waarin je eigen grenzen probeert te verleggen is daar vrij weinig mis mee.

Het doel is om een volwassen product op de markt te zetten (waar ik passief wat aan kan verdienen). En dan krijg je toch een iets andere aanpak dan wanneer je jezelf wilt bewijzen.

Je bouwt dus veel meer voor de lange termijn dan de korte termijn en daarbij moet je rekening houden met onderhoud en kwaliteit. Je kan niet zomaar iets schrijven en ervan uit gaan dat het voor altijd goed is.

Een plank over de sloot kan voldoende zijn, maar ik zou dat geen brug noemen

[BladeSlayer1000]

DevWouter schreef op zaterdag 13 oktober 2018 @ 17:14:
[...]


Yeah... Over todo lijstjes gesproken...

In mijn vrije tijd ben ik al meer dan een jaar (9 okt 2017 was de start) bezig om een programma te schrijven welk mij continue kan vertellen waar ik mee bezig moet zijn. Elke week was het meerdere avonden (en weekenden) waarbij ik achter de computer zat om het systeem te verbeteren. In principe is het een takenlijstje, maar dan wel met een paar features die je nergens anders ziet (behalve misschien TaskWarrior).

Ik ben denk ik nog 6 maanden bij de eerste echte release vandaan ben. Ik wil nog clientside encryptie toevoegen (het liefst met een private key die nooit verstuurd wordt), een admin gedeelte en de mogelijkheid om "lijstjes" te delen.

Als ik dan kijk naar demo's van JS libraries waarbij ze een takenlijstje bouwen in 10 minuten en dat vergelijk met "mijn missie" dan heb ik toch heel erg een dubbel gevoel

@BladeSlayer1000: Maak een systeem waarbij je ideeën voor projecten kan bijhouden zodat je in de toekomst (wanneer je weer een geniaal idee hebt) je ze kan toevoegen of juist kan gebruiken om iets te bouwen. En om je een idee te geven van hoe zo iets zou kunnen werken: https://github.com/open-source-ideas/open-source-ideas.

Jouw idee voor een project bevalt mij wel, als ik zo grofweg bedenk kan ik daar al mijn net geleerde kennis gebruiken om het te maken. Ik zal hier eens naar gaan kijken bedankt!

[Sandor_Clegane]

Ik heb een UDP client via .Net Core op Linux draaien in een LXC container, deze stuurt een UDP packet naar een server. Deze server ontvangt deze pakketjes om de seconde.

Waarom zou de client stoppen met het zenden van pakketjes totdat ik de console van de LXC open en dan direct weer beginnen?

Software......

[Marc3l]

DevWouter schreef op zaterdag 13 oktober 2018 @ 17:14:
[...]


Yeah... Over todo lijstjes gesproken...

In mijn vrije tijd ben ik al meer dan een jaar (9 okt 2017 was de start) bezig om een programma te schrijven welk mij continue kan vertellen waar ik mee bezig moet zijn.

Interessant, met een soort van algoritme?

[DevWouter]

Marc3l schreef op zaterdag 13 oktober 2018 @ 21:02:
[...]

Interessant, met een soort van algoritme?

Ja, taken worden altijd gesorteerd op basis van een score. De score wordt berekend op basis van hoe oud de taak is, sleutelwoorden en de afhankelijkheid van andere taken. Taken die afhankelijk zijn worden verborgen. Taken met een negatieve score worden ook verborgen. Hierdoor zie je ten alle tijden de taken die je kan oppakken en zijn ze altijd gesorteerd naar urgentie waarbij tijd als factor wordt meegenomen.

Heb je een taak dat een idee is en je vindt een idee niet urgent (zoals ik) dan zet je in de taak het sleutelword "#idea" welke jij hebt ingesteld als negatieve waarde. Echter omdat elke seconde de score van de taak verhoogd wordt (ook iets wat je kan instellen) zal de taak uiteindelijk positief worden en verschijnt het weer.

Je kan ook instellen dat na een bepaald aantal dagen een taak juist negatief wordt. Daarmee kan je voorkomen dat hele oude taken (die al lang niet meer relevant zijn) uiteindelijk verborgen blijven.

Het gevolg: Ik heb 36 taken op mijn takenlijstje staan terwijl er maar 8 zichtbaar zijn. En dat geeft echt veel meer rust dan.

Ik kwam op dit idee nadat ik de zoveelste takenlijstje weggooide omdat ik steeds meer tijd kwijt raakte aan het managen van mijn lijstje dan het uitvoeren van taken op mijn lijstje. Ook hadden een paar systemen last van het sync-issues (iets wat in mijn systeem onmogelijk is zodra je verbonden bent).

Zodra ik bereid ben om naar 1.0.0 te gaan zal aan de moderators vragen of ik de link hier mag droppen om slachtoffersss... ik bedoel klantûhm... gebruikers(?) te vinden....