Γνωρίζει κάποιος αν υπάρχουν αξιόπιστα benchmark που να συγκρίνουν το ServiceStack και το Web API? Τα benchmark στο site του ServiceStack έχουν τόσο βασικά λάθη που καταλήγουν άχρηστα - π.χ. χρησιμοποιούν διαφορετικό κώδικα για να καλέσουν το κάθε service, και ο κώδικας για Web API χρησιμοποιεί τον DataContractSerializer, τον πιο αργό Json deserializer που υπάρχει. Το benchmark καταλήγει να μετράει τους χρόνους του client, όχι των services που υποτίθεται ότι πρέπει να μετρήσει.

Αν χρησιμοποιηθεί ο ίδιος client για να καλέσει και τα δύο services, αντί για 300% καλύτερο, το ServiceStack βγαίνει μόλις 10% καλύτερο ... Τουλάχιστον αυτά ήταν τα αποτελέσματα όταν το Json.NET ήταν ακόμα στην έκδοση 5.06. Τώρα στην 6.05 μπορεί να έχουμε ανατροπή

Υποψιάζομαι ότι και αυτή η διαφορά οφείλεται στις διαφορές μεταξύ του ServiceStack.Text και του Json.Net που χρησιμοποιούν τα δύο services. Αν 

Λογικά, ένα καλό benchmark θα έπρεπε να συγκρίνει πράγματα πέρα από το χρόνο για sequential calls, όπως:

• χρόνους για διαφορετικά μεγέθη Json και διαφορετική πολυπλοκότητα 
• CPU και κατανάλωση μνήμης για κάθε συνδυασμό
• Συμπεριφορά για αυξανόμενο αριθμό ταυτόχρονων κλήσεων
• Όχι μόνο μέσους χρόνους αλλά και διασπορές και percentiles

Μιλώντας για ανατροπή, έκανα update το Web API και το Json.NET και οι διαφορές με το ServiceStack source του Ιουνίου έπεσαν κάπου στο 2% και κάτω, με διακυμάνσεις που κάνουν τη διαφορά ασήμαντη.

Με το τελευταίο Service Stack source, οι διαφορές είναι ανύπαρκτες οπότε κάτι κάνανε και έγινε "κομματάκι πιο αργό".  Μιλάμε για 20000 επαναλήψεις που δίνουν χρόνους πχ 4502 vs 4506 ή το ανάποδο.

Άρα το συμπέρασμα Παναγιώτη είναι ότι τα δυο frameworks είναι σχεδόν ισοδύναμα, σωστά; 

Και εμένα με ενδιαφέρει το θέμα άμεσα μιας και στο project που εργάζομαι αυτό το διάστημα πρέπει να επιλέξουμε ένα framework για να κάνουμε expose ένα REST API. 

Παναγιώτη, πόσο εύκολο - ή δύσκολο - θα είναι να γίνει η υλοποίηση και με τα Mobile Services και να έχουμε ένα benchmark και με αυτά. Δεν εννοώ τα Azure Mobile Services, αλλά τα Mobile Services που παίζουν local. Έχεις κάποιο κώδικα και σχήμα βάσης που θα μπορούσα να δω και να τα φτιάξω, ώστε να μπορέσεις να τα τρέξεις σε αντιπαράθεση;

George J.

George J. Capnias: Χειροπρακτικός Υπολογιστών, Ύψιστος Γκουράρχης της Κουμπουτερολογίας w: capnias.org, t: @gcapnias, l: gr.linkedin.com/in/gcapnias

@xabikos Το συμπέρασμα είναι "Lies, damn lies and benchmarks". Γίνεται τόση φασαρία για την ταχύτητα του ServiceStack αλλά αν τρέξεις ένα από τα δικά τους benchmarks, δεν βλέπεις διαφορά. Από εκεί και πέρα, θα σκεφτόμουν πολλά πράγματα πέρα από το πόσο γρήγορα απαντάει το framework σε ένα dummy benchmark με μία παράμετρο και ένα sting response.

Αυτό τον καιρό δουλεύω σε online travel agency με τους servers στο Amazon, και είναι τυπικό να έχουμε περίπλοκα responses της τάξης των 2ΜΒ (φαντάσου 200 ταξίδια με όλες τις λεπτομέρειες), με κλήσεις σε 3-4 third party services με κάποια να έχουν 3+ sec latency.  Αυτό σημαίνει ότι μας καίει το scalability, το density (πόσα requests μπορούμε να σηκώσουμε σε κάθε server), το CPU (για να μην γίνει κανένα app pool recycle) και η ασύγχρονη συμπεριφορά. 

Η ασύγχρονη συμπεριφορά είναι εξαιρετικά σημαντική αν έχεις κίνηση και καλείς άλλα services ή βάσεις, γιατί έτσι γλυτώνεις IIS threads και CPU. Μεγάλο CPU μπορεί να οδηγήσει σε recycle του application pool, το οποίο θα έχει σαν αποτέλεσμα η κίνηση που πήγαινε σε ένα server να πάει τώρα στους άλλους server της φάρμας και να τους ρίξει και αυτούς. 

Επίσης, μπλοκαρισμένα threads ==> αυξανόμενο IIS queue ==> φόρτωμα των επόμενων server στη φάρμα και πάλι cascading failure. Μπορεί να μην πέσουν, αλλά η καθυστέρηση θα είναι τέτοια που είτε οι clients θα κάνουν timeout είτε οι πελάτες θα πάνε σε άλλα sites. Να βάλεις ένα queue μπροστά όπως προτείνει το ServiceStack δεν λύνει *αυτό* το πρόβλημα.

Το Web API τώρα έχει φτιαχτεί εξαρχής για να δουλεύει καλά ασύγχρονα, ενώ το Service Stack πρόσθεσε ασύγχρονη επεξεργασία μόλις στην έκδοση 4. Θα ήθελα να δω πραγματικά πόσο καλά την υλοποιεί. Το ServiceStack πολύ απλά είχε μείνει πίσω και δεν μπορούσε να προχωρήσει χωρίς να σπάσει τον κώδικα.

Επιπλέον, ο λόγος που το ServiceStack.Text ήταν γρηγορότερο από το Json.NET σε προηγούμενες εκδόσεις, ήταν ότι κάλυπτε απλούστερες περιπτώσεις από το Json.Net. Πράγματα όπως το Json schema δεν υπήρχαν καθόλου (και νομίζω ακόμα λείπουν). Έχουν βγει άλλοι, γρηγορότεροι parsers οι οποίοι όμως υποστηρίζουν ακόμα πιο απλά σενάρια.

Όσον αφορά το licensing, το Web API είναι open source, τσάμπα license, με ξεκάθαρα versions, εύκολο deployment με Nuget, documentation. Το ServiceStack σου δίνει μεν τον κώδικα αλλά πρέπει να πληρώσεις αν θέλεις nuget. Versioning δεν υπάρχει στον κώδικα (ούτε ένα tag), το documentation συχνά αναφέρεται σε παλιότερες εκδόσεις.

Άλλο σημαντικό στοιχείο είναι πόσο καλά θα υποστηρίζεται το ASP.NET vNext και κυρίως το cloud-optimized environment. Αυτό θα μου δώσει καλύτερο density , να εξυπηρετήσω δηλαδή περισσότερους clients με τα ίδια ή φθηνότερα VMs στο Amazon ή το Azure και έτσι να γλυτώσω χρήματα. Μπορεί 200MB στο desktop να ακούγονται αστεία, αλλά είναι αρκετά για να κατέβω μία κλίμακα στο cloud.  Πραγματικά δεν θα ήθελα να δω επανάληψη της ιστορίας με το Service Stack v3 και γενικά την χρήση των features του .NET 4+. Δεν θέλω να βρεθώ του χρόνου να λέω "αχ πότε θα το υποστηρίξουν να κατέβω κλίμακα".

Και ακόμα δεν έχω πιάσει καν θέματα όπως το authentication (πόσο εύκολα δουλεύει το OAuth?), πρωτόκολλα (BSON, Protobuf, MessagePack, τί-με-νοιάζει-αφού-έχω-gzip), validation, parameter binding.

Τελικά, αν σκέφτεστε τί framework να διαλέξετε για τα επόμενα 1-2 χρόνια καλό θα ήταν να κάνετε τη δική σας σύγκριση αντί να βασιστείτε σε στημμένα benchmark. 

George J. Capnias:

Παναγιώτη, πόσο εύκολο - ή δύσκολο - θα είναι να γίνει η υλοποίηση και με τα Mobile Services και να έχουμε ένα benchmark και με αυτά. Δεν εννοώ τα Azure Mobile Services, αλλά τα Mobile Services που παίζουν local. Έχεις κάποιο κώδικα και σχήμα βάσης που θα μπορούσα να δω και να τα φτιάξω, ώστε να μπορέσεις να τα τρέξεις σε αντιπαράθεση;

 

George J.

 

Έλεος, ένα benchmark έκανα και μου ζητάς το φεγγάρι? Για ποιά mobile services μιλάς ? Θα το κάνω, αν υποσχεθείς να φτιάξεις τον editor του DNZ για να δουλεύει με chrome

Υπόσχομαι δημόσια ότι θα έχει αλλάξει πριν από τέλους του χρόνου - προς το παρόν πριν ξεκινήσεις να γράφεις, θα πατάς το Bold {Β} δύο φορές...

George J. 

George J. Capnias: Χειροπρακτικός Υπολογιστών, Ύψιστος Γκουράρχης της Κουμπουτερολογίας w: capnias.org, t: @gcapnias, l: gr.linkedin.com/in/gcapnias

@Παναγιώτη για άλλη μια φορά η απάντηση σου είναι σκέτος χρυσός. Μπόρεσες και χώρεσες σε ένα απλό post τις περισσότερες από τις παραμέτρους που πρέπει να λάβω υπόψιν για την επιλογή framework. Με τα μέχρι τώρα δεδομένα θα επιλέξω το WEB API μιας και έχω μια σχετική εμπειρία με αυτό και στην συγκεκριμένη περίπτωση δε νομίζω να μπορέσω να δεσμεύσω χρόνο για να δοκιμάσουμε κάτι διαφορετικό. Και ο ασύγχρονος τρόπος είναι κάτι που θα ακολουθήσουμε ευλαβικά σε όλα τα layers τις εφαρμογής για όλους αυτούς του λόγους που παράθεσες. Και επειδή ο στόχος είναι να φιλοξενήσουμε την εφαρμογή στο cloud είναι βασικό να καταναλώνουμε όσο το δυνατόν λιγότερα resources μιας και αυτό θα μειώσει το κόστος. Tο τελευταίο entity framewrok ευτυχώς υποστηρίζει ασύγχρονη πρόσβαση στην βάση και απλοποιεί τα πράγματα. 

Βέβαια στο post σου έθιξες και κάτι άλλο που με απασχολεί ιδιαίτερα. Την τεχνολογία vNext που έρχεται και θα επιφέρει μεγάλες αλλαγές. Έπαιξα λίγο με αυτό αλλά ακόμη είναι σε πολύ πρώιμο στάδιο για να δοκιμάσεις κάτι σε παραγωγή. Απλά θα έχει και breaking changes και σκέφτομαι πόσο σοφό είναι χρησιμοποιήσεις τώρα τεχνολογίες που σε λιγότερο από ένα χρόνο θα χρειαστείς να κάνεις μεγάλες αλλαγές. Αλλά έτσι είναι στα τεχνολογικά θέματα λίγο πολύ τα τελευταία χρόνια.