Στην εταιρία στην οποία εργάζομαι έχουμε ξεκινήσει την διαδικασία επιλογής πλατφόρμας η οποία θα αντικαταστήσει το υπάρχον extranet (asp 3.0 – Sql Server 2000).
Ένα από τα κόστη που θα αντιμετωπίσουμε πέρα από το software, είναι το hardware.

Οι εταιρίες που έχουμε προσκαλέσει για την υλοποίηση του extranet για να μπορέσουν να μας υπολογίσουν την βασική υποδομή (χωρίς fail over κλπ.) που θα χρειαστούμε σε  hardware μας ζητάνε τους ¨Concurrent user¨.

Από αυτά που γνωρίζω είναι ότι, σαν ¨Concurrent user¨  εννοούνται τα ταυτόχρονα request που γίνονται σε μια συγκεκριμένη χρονική περίοδο (per second φαντάζομαι είναι ρεαλιστικό).

Επειδή ακούω διαφορετικούς ορισμούς για τους ¨Concurrent user¨ το οποίο αναπόφεκτα οδηγεί  και σε  ακραίες μετρήσεις  (από 15 έως 150) θα ήθελα να απευθυνθώ στην εμπειρία της κοινότητας και να ρωτήσω:

• Πως θα ορίζατε τους ¨Concurrent user¨;
• Οι  ¨Concurrent user¨  υπολογίζονται ως request προς τον application server (IIS, BEA κλπ) ή προς την βάση δεδομένων ή και τα δύο;
• Με ποιο τρόπο θα μπορούσαμε να υπολογίσουμε τους  ¨Concurrent user¨;
• Είναι διαφορετικές οι απαιτήσεις  αν ο  ¨Concurrent user¨ κάνει και transaction;

Αν χρειάζεστε επιπλέον διευκρινήσεις παρακαλώ μην διστάσετε.
Επίσης θα ήθελα αν είναι δυνατόν να μην απαντήσετε με παραπομπές (εκτός αν είναι αναγκαίο για  την τεκμηρίωση) όχι γιατί είμαι περίεργος, αλλά γιατί θα ήθελα να υπάρχει σαν reference (και βεβαίως τι καλύτερο reference από το dotNETZone).

---

Φιλάρετος Σεβαστιάδης.

Albert Camus: Life is the sum of your choices.

Για να μπορέσεις να τους απαντήσεις, θα πρέπει να σου ορίσουν το context δηλαδή ποιό είναι το resource (app ή βάση ή whatever) και ποιά είναι η μονάδα χρόνου. Ο λόγος που ακούς διαφορετικές απαντήσεις είναι γιατί ο καθένας ανάλογα για τι πράγμα μιλάει ή που εστιάζει δίνει διαφορετικό context.

Τώρα, για ένα stateless περιβάλλον όπως είναι τα web apps η έννοια "concurrent user" δεν έχει και πολύ νόημα αλλά ακόμα και αν θέλεις να ορίσεις κάτι τέτοιο ως "η περίοδος από την στιγμή που ο χρήστης στέλνει το request μεχρι που λαμβάνει το response", δηλαδή μια περίοδος που λειτουργίας που εμπλέκει όλα τα μέρη του συστήματος ώστε πχ να συμπεριλαμβάνονται μέσα και τα πιθανά transactions στη βάση, κλπ, κλπ, τότε το δευτερόλεπτο είναι εξαιρετικά μικρό timespan. Νομίζω πιο λογικό είναι ένα timespan των 5 ή 10 λεπτών.

 

---

Vir prudens non contra ventum mingit

Σε ευχαριστώ Μάνο για την απάντηση (αν και άργησα να απαντήσω).
Μου έδωσε μια κατεύθυνση.

Και συνεχίζω και θέτω ένα σενάριο (τα στοιχεία είναι από το υπάρχον σύστημα καταγραφής της πλατφόρμας):

• Εγγεγραμμένοι χρήστες περίπου 5.000
• Μοναδικά Login ανά ημέρα περίπου 2.000
• Page Views ανά ημέρα περίπου 10.000 (60% content, 40%  Application)
• Το 50% της κίνησης είναι μεταξύ 10:00 – 13:00 (70%  Application, 30%  content)

Και ρωτάω:

• Θα μετρήσω τα request από το καταγραφικό της πλατφόρμας;
• Θα μετρήσω τα request από τα logs files του IIS (π.χ. χρησιμοποιώντας το WebTrends);
• Θα μετρήσω τα request χρησιμοποιώντας κάποιον από τους μετρητές του λειτουργικού;
• Με κάποια άλλη μεθοδολογία;

Αν χρειάζεστε επιπλέον διευκρινήσεις εδώ είμαι...

---

Φιλάρετος Σεβαστιάδης.

Albert Camus: Life is the sum of your choices.

Γενικά εγώ θα χρησιμοποιούσα ένα συνδιασμό για να βρω τα στοιχεία που θέλω και να πάρω ένα μέσω όρο. Log files του IIS και performance counters σε connections κλπ, νομίζω ότι είναι ο καλύτερος τρόπος. Πχ με Performance Counter θα μπορούσες να βρεις πόσους concurrent χρήστες έχει, πόση ώρα μένουν ανοιχτά τα connections και διάφορα τέτοια.

---

Παναγιώτης Κεφαλίδης

"Για να επιτύχεις, θα πρέπει το πάθος σου για την επιτυχία να είναι μεγαλύτερο απο τον φόβο σου για την αποτυχία"

Οι απαντήσεις παρέχονται για συγκεκριμένες ερωτήσεις και χωρίς καμιά εγγύηση. Παρακαλώ διαβάστε τους όρους χρήσης.

Ζητώ συγνώμη αν θα τινάξω στον "αέρα" οποιαδήποτε φιλόδοξη προσπάθεια γίνεται για υπολογισμό των concurrent users, αλλά εκτιμώ οτι οι περισσότεροι (των εταιριών μη εξαιρουμένων) έχουν στο μυαλό τους ως concurrent users σε τέτοια περιβάλλοντα τα active sessions. 

---

Σωτήρης Φιλιππίδης

DotSee Web Services

Μην έχοντας ασχοληθεί ξανά με το θέμα, και κινδυνεύοντας να εκτεθώ οικτρά, θα δώσω κάποια links που ίσως δώσουν απάντηση σε κάποιες από τις ερωτήσεις. Στα books on line του Content Management Server βρήκα αυτό το βιβλίο στο οποίο απαντούνται πολλές τέτοιου είδους ερωτήσεις. Για μια γρήγορη ματιά στον τύπο δες κι εδώ. Επίσης, ενδιαφέρον ως προς την αποσαφήνιση εννοιών και μεθοδολογιών παρουσιάζουν και οι πηγές από το "αντίπαλο στρατόπεδο" (Usage Analysis for Portal Server και Sizing Your Portal). Ρίχνοντας μια ματιά στο βιβλίο, παρατήρησα ότι ο Παναγιώτης έχει δίκιο. Χρειάζονται δεδομένα από πάρα πολλές πηγές για να εκτιμήσεις αυτά τα μεγέθη. Περισσότερες λεπτομέρειες στο βιβλίο.

---

Ακόμα κι ένας άνθρωπος μπορεί ν' αλλάξει τον κόσμο. Μη θέλεις να κυβερνήσεις. Απλά δείξε το μονοπάτι κι ο κόσμος θ' ακολουθήσει!!

Γενικά συμφωνώ με τους προλαλήσαντες. Θα σου πρότεινα να μην το παιδεύεις πολύ και στο κάτω-κάτω, θεωρώ ότι αυτό είναι ευθύνη της εκάστοτε εταιρείας. Τα στοιχεία που έχεις είναι αρκετά, από εκεί και πέρα, το pre-sales θα πρέπει να φροντίσει ώστε αν χρειάζεται κάτι παραπάνω να σου στείλει τεχνικούς να πάρουν τις μετρήσεις που θέλουν. Διαφορετικά κινδυνεύεις να καταλήξεις με ένα σύστημα που σε συνθήκες υψηλού φόρτου να μην μπορεί να ανταποκριθεί και να σου λένε ότι φταίς εσύ επειδή είπες "x concurrent χρήστες" αλλά αυτοί "δεν εννοούσαν τους χρήστες του IIS αλλά τους χρήστες του xyz".

 

---

Vir prudens non contra ventum mingit

---

Φιλάρετος Σεβαστιάδης.

Albert Camus: Life is the sum of your choices.