cap
Νεοφερμένος
Ο Σωτήρης! αυτή τη στιγμή δεν είναι συνδεδεμένος. Είναι 50 ετών και επαγγέλεται Μηχανικός λογισμικού. Έχει γράψει 80 μηνύματα.
21-04-08
12:03
Οσον αφορά στην αρχική ερώτηση του φίλου μας, έχω να παρατηρήσω τα εξής:
Ειτε έστησες IIS αφοτου έστησες το .net framework, είτε κάτι έγινε κατά τη δημιουργία των mappings των διαφόρων extensions και το .aspx extension δεν έχει γίνει mapped σωστά στο asp.net με αποτέλεσμα ο iis να το βλέπει ως απλό xml αρχείο.
Δες εδώ για πληροφορίες για το πώς να διορθώσεις αυτό το πρόβλημα:
https://support.microsoft.com/?id=306005
Ειτε έστησες IIS αφοτου έστησες το .net framework, είτε κάτι έγινε κατά τη δημιουργία των mappings των διαφόρων extensions και το .aspx extension δεν έχει γίνει mapped σωστά στο asp.net με αποτέλεσμα ο iis να το βλέπει ως απλό xml αρχείο.
Δες εδώ για πληροφορίες για το πώς να διορθώσεις αυτό το πρόβλημα:
https://support.microsoft.com/?id=306005
Σημείωση: Το μήνυμα αυτό γράφτηκε 16 χρόνια πριν. Ο συντάκτης του πιθανόν να έχει αλλάξει απόψεις έκτοτε.
cap
Νεοφερμένος
Ο Σωτήρης! αυτή τη στιγμή δεν είναι συνδεδεμένος. Είναι 50 ετών και επαγγέλεται Μηχανικός λογισμικού. Έχει γράψει 80 μηνύματα.
21-04-08
11:59
Να απαντήσω καταρχήν στο τελευταίο σου ερώτημα: Δεν υπάρχει θέμα σύγκρισης μεταξύ δύο πλατφορμών (μια και πρόκειται για πλατφόρμες, στην ουσία, και όχι απλά για γλώσσες). Η καθε μία κάνει κάποια πράγματα καλύτερα και κάποια χειρότερα, στην πραγματικότητα όμως η ποιότητα των προγραμματιστών είναι αυτή που εγγυάται την ποιότητα του αποτελέσματος.
Μια πεποίθηση που επικρατεί στην αγορά (και δυστυχώς επιβεβαιώνεται μέχρι σήμερα, από κουβέντες που έχω με εταιρίες) είναι οτι οι 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.
Μια πεποίθηση που επικρατεί στην αγορά (και δυστυχώς επιβεβαιώνεται μέχρι σήμερα, από κουβέντες που έχω με εταιρίες) είναι οτι οι 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.
Σημείωση: Το μήνυμα αυτό γράφτηκε 16 χρόνια πριν. Ο συντάκτης του πιθανόν να έχει αλλάξει απόψεις έκτοτε.
cap
Νεοφερμένος
Ο Σωτήρης! αυτή τη στιγμή δεν είναι συνδεδεμένος. Είναι 50 ετών και επαγγέλεται Μηχανικός λογισμικού. Έχει γράψει 80 μηνύματα.
21-04-08
10:33
Σε αντίθεση με την php όπου για τα πάντα χρησιμοποιεί την Ram χωρίς μάλιστα να γεμίζουν το σύστημα με άχρηστα Procress, όπως η asp που για κάθε compiler χρησιμοποιεί και άλλο Procress
Αυτό το τελευταίο ομολογώ αγαπητέ οτι δυσκολεύομαι να το καταλαβω.
Το οτι ένα process (PHP) χρησιμοποιεί για τα πάντα τη RAM είναι καλό; Αν είναι έτσι όπως φαντάζομαι οτι το εννοείς, μάλλον κακό ειναι
Το οτι "η php χρησιμοποιεί τη RAM χωρίς να γεμίζει το σύστημα με άχρηστα processes" δεν καταλαβαίνω που κολλάει. Η ίδια η php είναι ένα process στο σύστημα, και ούτως η άλλως, και τα processes, άχρηστα ή χρήσιμα, τη RAM χρησιμοποιούν. Αρα το να χρησιμοποιεί κάποιος τη RAM δεν τον απαλάσσει από το να γεμίζει το σύστημα με processes. Εκτός αν κάτι άλλο εννοούσες και δεν το κατάλαβα.
"Η asp για κάθε compiler χρησιμοποιεί και άλλο process" - Μιλάς για asp classic ή για asp.net; Γιατί στην asp classic έχουμε interpretation και όχι compilation. Διαφορετικά processes χρησιμοποιούνται σε επίπεδο συστήματος όταν υπάρχουν isolated application pools, και αυτό είναι επιλογή του administrator. Αν μιλάς για πιό low-level πράγματα, ίσως να έχει μεν ενδιαφέρον, αλλά από ακαδημαϊκής απόψεως και όχι από απόψεως επιδόσεων.
Προς Θεού: ΕΙΜΑΙ microsoft developer, αλλά ούτε ευλογώ τα γένια μου ούτε υποστηρίζω άκριτα μια τεχνολογία/εταιρία. Απλά όταν βλέπω κάτι που δεν καταλαβαίνω προσπαθώ να το κατανοήσω και να το εξηγήσω και / ή να ζητήσω περισσότερες λεπτομέρειες από τον αρχικό γράφοντα.
Σημείωση: Το μήνυμα αυτό γράφτηκε 16 χρόνια πριν. Ο συντάκτης του πιθανόν να έχει αλλάξει απόψεις έκτοτε.
cap
Νεοφερμένος
Ο Σωτήρης! αυτή τη στιγμή δεν είναι συνδεδεμένος. Είναι 50 ετών και επαγγέλεται Μηχανικός λογισμικού. Έχει γράψει 80 μηνύματα.
22-02-08
22:39
Αν και πολύ πολύ καθυστερημένα, γιατί τώρα το εντόπισα το θέμα, να σας ενημερώσω οτι μέχρι και πριν λίγο καιρό η εταιρια Xelixis.NET πρόσφερε δωρεάν web hosting σε .NET developers. Για περισσότερες πληροφορίες, εδώ. Δεν γνωρίζω αν ισχύει ακόμα αυτή η προσφορά. (Δεν σχετίζομαι με την εταιρία, αν και γνωρίζω τους ανθρώπους της).
Σημείωση: Το μήνυμα αυτό γράφτηκε 16 χρόνια πριν. Ο συντάκτης του πιθανόν να έχει αλλάξει απόψεις έκτοτε.