Οι περισσότεροι σχεδόν χρησιμοποιούν τα SSRS στην καθημερινότητα τους καλύπτοντας τις ανάγκες τους σε reporting. Πρόσφατα είχα μια ενδιαφέρουσα ερώτηση από έναν εκλεκτό φίλο και συνάδελφο σχετικά με αυτά, έτσι μου γεννήθηκε η ιδέα να γράψω το post αυτό.

SSRS και IIS

Ένα από τα πρώτα πράγματα που κάνει εντύπωση ειδικότερα σε όσους έχουν προγενέστερη εμπειρία από τον SSRS 2005 είναι το γεγονός ότι από την έκδοση των SSRS 2008 δεν υπάρχει η ανάγκη του IIS. Αν και αυτό μπορεί να είναι κάπως περίεργο, εντούτοις είναι μια σωστή απόφαση ώστε τα SSRS να απαγκιστρωθούν από τον IIS. O IIS είχε μεγάλη επίδραση στα SSRS ιδιαίτερα στην εγκατάσταση τους και αυτό διότι αρκετά IT περιβάλλοντα δεν θέλουν στην ίδια μηχανή να έχουν IIS και SQL Server. Επίσης θα πρέπει να τονισθεί ότι πράγματα όπως το web.config hierarchy μπορεί να έχει, άθελα του, επίδραση στα SSRS επειδή στις περισσότερες περιπτώσεις οι Web Server δεν είναι σωστά configured. Επίσης κατά την γνώμη αρκετών το να έχεις τα SSRS delivery components μέσα στον IIS δεν είναι ότι καλύτερο μιας και δεν σου δίνεται καλύτερο resource governance.

Στις εκδόσεις μέχρι και τα SSRS 2005 ο IIS χρησιμοποιούταν σαν HTTP server για τα SSRS. Από τα SSRS 2008 και μετά αυτά χρησιμοποιούν απευθείας το HTTP.SYS από το λειτουργικό σύστημα. Έτσι το λειτουργικό πλέον κάνει την δουλειά και όχι ο IIS. Έτσι και αλλιώς θα πρέπει να γίνει κατανοητό ότι τα SSRS δεν είναι ένας γενικού σκοπού web server.

Εξαιτίας ότι πλέον ο IIS είναι παρελθόν ο Report Server κάνει φυσικά μόνος του url registration και management τόσο για τον Report Manager όσο και για τον Report Server SOAP endpoints κάνοντας χρήση του HTTP.SYS

Χρησιμοποιώντας το RS Configuration Tool έχουμε την δυνατότητα να settαρουμε αυτά τα URLs μαζί με τις πληροφορίες τους όπως πρωτόκολλο, path, port, virtual directory. Οι πληροφορίες αυτές αποθηκεύονται στο rsreportserver.config στο tag.

Εδώ μου δίνεται η ευκαιρία να κάνω μια μικρή αλλά σημαντική παρατήρηση . Εξαιτίας ότι δεν υπάρχει εξάρτηση από τον IIS ο Report Manager καθώς και το Report Server web service έχουν ενσωματωθεί στο SQL Server Reporting Services Web Service.

Συνεχίζοντας μετά την παρατήρηση μου θα πρέπει να αναφερθεί ότι τα ποιο common IIS settings τα οποία υπήρχαν στα SSRS 2005 υποστηρίζονται και στα SSRS 2008 και SSRS 2008 R2. Τέτοια είναι IP address, host headers, multiple ports, SSL certifications, IIS Security modes( NTLM, Kerberos, Negotiate, Basic, Custom). Δεν υποστηρίζονται anonymous, digest και passport authentication ή client certificates.

Αρκετοί θεωρούν ότι η μεγαλύτερη απώλεια από την ανεξαρτητοποίηση των SSRS από τον IIS είναι τα ISAPI filters. Αν για παράδειγμα είχες single sign-on θα πρέπει να πας με τον ISA πλέον ή αν θέλεις κάποιο άλλο functionality εναλλακτική είναι να πας με ASP.NET HTTP custom modules.

Φυσικά θα ήταν παράλειψη μου να μη τονίζω ότι μπορείς να έχεις εγκατεστημένο τον IIS και να στήσεις και τα SSRS στον ίδιο server. Αλλά θα πρέπει να γίνει κατανοητό ότι ακόμα και έτσι μιλάμε για δύο διαφορετικά services. Ακόμα και αν φτιάξει ένα virtual directory που έχει το ίδιο όνομα και port στον IIS αυτό δεν πρόκειται ποτέ να δεχθεί τα αιτήματα μιας και το HTTP.SYS πρώτο βλέπει τα αιτήματα αυτά και τα δρομολογεί στα SSRS.

SSRS Windows Service και Memory Management

Όλα πλέον στα SSRS είναι ενσωματωμένα σε ένα windows service το οποίο περιέχει τα Report Manager, Report Service Web Service, Scheduling service, Notification service, Event Service.

Αυτό δεν είναι άλλο από το ReportingServicesService.exe. Το service αυτό κάνει host πολλαπλά application domains. Κάθε ένα από τα παραπάνω ενσωματωμένα services χρησιμοποιεί ξεχωριστό application domain. Αυτό μας δίνει την δυνατότητα να τα ενεργοποιούμε ή απενεργοποιούμε ξεχωριστά αν και υπάρχει εξαρτήσεις μεταξύ τους.

Παρόλο που έχουμε ξεχωριστά application domains η διαχείριση της μνήμης είναι κοινή για κάθε service μέσα σε αυτό. Tα SSRS χρησιμοποιούν components από το SQL OS για να κάνουν διαχείριση μνήμης. Έτσι ενώ στις προηγούμενες εκδόσεις δεν μπορούσαμε να ελέγξουμε αυτή, εξαιτίας ότι όλα ήταν κάτω από την σκεπή του IIS, τώρα έχουμε την δυνατότητα να ελέγξουμε αυτή ορίζοντας τα πάνω και κάτω όρια αυτής. Επίσης υπάρχουν memory thresholds με αποτέλεσμα όταν ένας από αυτούς εμφανιστεί τα SSRS αλλάζουν συμπεριφορά ώστε να είναι πάντα διαθέσιμα στον τελικό χρήστη.

Κάθε application domain το οποίο φιλοξενείται μέσα στο SSRS Windows Service όταν ξεκινάει παίρνει το ελάχιστο ποσό μνήμης που χρειάζεται για να ξεκινήσει. Από εκεί και μετά αρχίζει να αναφέρει το τι μνήμη χρησιμοποιεί και φυσικά ακούει τα notification που ο memory manager στέλνει σε αυτό και αφορούν το πόσο μνήμη χρησιμοποιεί και πόση θα πρέπει να απελευθερώσει. Όλα αυτά γίνονται με βάση έναν αλγόριθμο ο οποίος είναι βασισμένος στο χαμηλό κόστος και στο μεγαλύτερο memory consumption.

Εάν δεν υπάρχει διαθέσιμη μνήμη τότε ο Report Server γυρίζει HTTP 503 error.

Εάν θέλω να ορίσω το μέγεθος της μνήμης υπάρχουν διαθέσιμα τέσσερεις νέες επιλογές μέσα (ναι δεν είναι γραφικό) στο rsreportserver.config. Αυτές είναι:

1. WorkingSetMinimum

Ορίζουμε το ελάχιστο ποσό μνήμη που θέλουμε τα SSRS να χρησιμοποιούν

2. WorkingSetMaximum

Ορίζουμε το μέγιστο ποσό μνήμη που θέλουμε τα SSRS να χρησιμοποιούν

3. MemorySafetyMargin

Ορίζει το μέγιστο επιτρετό για το low-memory section

4. MemoryThreshhold

Ορίζει το μέγιστο επιτρεπτό για το medium-memory pressure section.

Σε αυτό το σημείο θα πρέπει να σας εξηγήσω λίγο περισσότερο την διαχείριση της μνήμης ώστε να γίνουν κατανοητές οι επιλογές 3 και 4.

Όταν έρχεται ένα αίτημα για μείωση της μνήμης που χρησιμοποιείται, ο server υπολογίζει το ελάχιστο μέγεθος της μνήμης που θα ελευθερωθεί και λαμβάνει από τα application domains πληροφορίες τέτοιες ώστε να μπορεί να ξέρει πόση μνήμη θα ελευθερώσει και πόσο εύκολα μπορεί να γίνει αυτό γιατί όπως έχω αναφέρει και ποιο πάνω ο αλγόριθμος αυτό κοιτάζει επειδή όταν προσπαθεί να μειώσει την μνήμη ο Report Server κάνει serialize κάποια state information στο δίσκο. Αυτό σημαίνει ότι θα πρέπει να γίνει παύση σε κάποια μεγάλα reports και αυτό το κάνει με το να κάνει serialize και να αφήσει τα μικρά. Έτσι έχουμε τρεις memory pressure καταστάσεις.

1. Low

Σε αυτή όλα τα request γίνονται processed και φυσικά νέα γίνονται αποδεκτά. Requests τα οποία απαιτούν background processing συνεχίζουν με χαμηλή προτεραιότητα.

2. Medium

Αυτά τα request που είναι σε εξέλιξη συνεχίζουν να εκτελούνται, ενώ τα νέα γίνονται αποδεκτά ανά περίπτωση. Το memory allocation σε όλα τα application domains αρχίζει να μειώνεται με μεγάλη μείωση στα background processing application domains (πχ Scheduling). Tα requests στο web service και στο URL access μπαίνουν στην υψηλή προτεραιότητα ώστε να μην υπάρχει επίπτωση στον τελικό χρήστη.

3. High

Δεν γίνονται αποδεκτά νέα request όπως επίσης requests για μνήμη απορρίπτονται. Σε αυτή την περίπτωση αρχίζει και το serialization στο δίσκο όπου φυσικά έχουμε σαν απόρροια να πέφτει η απόδοση των τρεχόντων request.

Στην παρακάτω εικόνα συνοψίζονται όλα τα παραπάνω