Να απαντήσω καταρχήν στο τελευταίο σου ερώτημα: Δεν υπάρχει θέμα σύγκρισης μεταξύ δύο πλατφορμών (μια και πρόκειται για πλατφόρμες, στην ουσία, και όχι απλά για γλώσσες). Η καθε μία κάνει κάποια πράγματα καλύτερα και κάποια χειρότερα, στην πραγματικότητα όμως η ποιότητα των προγραμματιστών είναι αυτή που εγγυάται την ποιότητα του αποτελέσματος.
Μια πεποίθηση που επικρατεί στην αγορά (και δυστυχώς επιβεβαιώνεται μέχρι σήμερα, από κουβέντες που έχω με εταιρίες) είναι οτι οι PHP developers στην Ελλάδα είναι λιγότερο "μπασμένοι" στο χώρο και προσπαθούν να χρησιμοποιούν πολλά έτοιμα πράγματα τα οποία στην πραγματικότητα δεν πολυγνωρίζουν πως λειτουργούν, κάτι που οδηγεί σε ερασιτεχνικά, στην καλύτερη περίπτωση, αποτελέσματα. Το φαινόμενο αυτό συντηρείται και από τις εταιρίες, οι οποίες πληρώνουν συνήθως λιγότερα για ένα php developer από ο,τι για έναν ASP.NET developer παραπλήσιου επιπέδου. Εχει βέβαια μια λογική, μια και ο asp.net developer συνήθως μπορεί να μεταπηδήσει ευκολότερα σε enterprise-level εφαρμογές ή / και win32 εφαρμογές, κάτι που αποτελεί συνήθως επένδυση για τις εταιρίες.
Στο θέμα μας τώρα (και μιλώντας κυρίως για asp.net): Οταν έχεις πολλαπλά sites σε ένα server τα οποία τρέχουν κάτω από το ίδιο process, σημαίνει συνήθως (στον IIS) οτι μοιράζονται το ίδιο application pool, ήτοι τον ίδιο χώρο μνήμης. Αυτό μειώνει τον αριθμό των processes (μονο ένα που κάνει τα πάντα), αλλά αυξάνει την πιθανότητα αν "σκάσει" ένα από τα sites να συμπαρασύρει μαζί του και όλα τα άλλα. Επίσης, αν ένα από τα sites έχει π.χ. memory leaks για κάποιο λόγο δεν έχεις κανένα έλεγχο στο πόση μνημη δεσμεύει και πόση μνήμη αφήνει ελεύθερη στα υπόλοιπα. Εκεί περιλαμβάνονται και σενάρια DoS.
Με πολλαπλά application pools έχεις απόλυτο έλεγχο στο πόση μνήμη καταλαμβάνει το καθένα, έχεις έλεγχο στο πότε θα κάνει recycle ("καθαρισμό" ουσιαστικα) - μετά από ένα συγκεκριμένο αριθμό requests, όταν η μνήμη φτάσει σε κάποιο νούμερο, ακόμα και όταν η virtual memory φτάσει σε κάποιο σημείο. Φυσικά, για κάθε application pool έχεις και ένα process.
Σε production περιβάλλοντα αυτό είναι critical, μια και δεν μπορείς να αφήνεις ΕΝΑ process να παίρνει το ρίσκο να "κατεβάσει" 100 π.χ. sites αν κάτι δεν πάει καλά. Ειναι μια τακτική που την έκαναν και παλιότερα οι asp classic άνθρωποι, όλα τα sites στο default application pool. Ομως, μιλάμε για sites που δεν είχαν ιδιαίτερη περιπλοκότητα ούτε μεγάλες απαιτήσεις σε μνήμη. Αν βάλεις όμως πέντε portals σαν το e-steki, γραμμένα σε asp.net, σε ΕΝΑ application pool, τότε μοιράζεις το ρίσκο που μπορεί να έχει ένα από αυτά και στα άλλα τέσσερα. Συνεπώς, η ύπαρξη πολλαπλών processes (σαν αποτελεσμα των πολλαπλών app pools) είναι τελικά καλό πράγμα
Οσον αφορά στα com objects: Η asp πράγματι μπορεί (και το κάνει) να καλέσει διάφορα com objects. Κλασική περίπτωση το adodb.recordset που χρησιμοποιούνταν ευρέως στην asp classic. Στην asp.net, οπου όλα τα objects αποτελούν (σε μεγάλο ποσοστό τουλάχιστον) managed .net assemblies, δεν υπάρχει αυτό το θέμα πλέον. Και οχι, η άποψή μου είναι οτι δεν καθυστερεί ΑΥΤΟ την εκτέλεση των εφαρμογών και δεν αυξάνει τη μνήμη. Εμπειρική άποψη, και όχι benchmark-based βεβαια.
Τελος, να ξεκαθαρίσω για άλλη μια φορά οτι άλλο asp classic (μια τεχνολογία που έχει "φύγει" εδώ και χρόνια) και άλλο asp.net. Δεν θα μπω, λόγω έλλειψης χρόνου, σε πλεονεκτήματα και μειονεκτήματα. Εξάλλου, θα ήταν άδικο προς την php, μια και γνωρίζω πιό καλά τα πλεονεκτήματα του asp.net. Ομως, θα μπορούσα να ανταπαντώ σε κάθε πλεονέκτημα που παρατίθεται για php με ένα αντίστοιχο ή παραπλήσιο πλεονέκτημα (αν υπάρχει ) της asp.net.
