Home

on problem solving

2008/11/05

(ή πως το γρήγορο hardware μας κάνει τεμπέληδες)

Διαβάζω στο Punk Rock Operations Research:

“Sometimes we rely on software too much and on good modeling too little. A IIE blog entry writes about blindly using software as a quick fix. When computing power wasn’t very powerful, making a tight, efficient formulation was necessary for finding optimal solutions.”

Πόσο αληθινό είναι αυτό. Πάει αργά η εφαρμογή;

– Φταίει ο server. Να πάρουμε καινούργιο για να πάει πιο γρήγορα.

Ενώ στην πραγματικότητα αυτό που φταίει είναι η ίδια η εφαρμογή η οποία δεν μπορεί να εκμεταλλευτεί ικανοποιητικά το υπάρχον hardware και άρα ούτε και το επόμενο. Το να προσθέτεις hardware στη λύση δεν μπορεί να είναι το πρώτο μέτρο- κυρίως γιατί είναι ημίμετρο. Είναι το τελευταίο χαρτί που μπορούμε να τραβήξουμε, όταν δεν μπορούμε να κάνουμε κάτι καλύτερο. Ακόμα θυμάμαι τη συμβουλή εταιρίας να αγοράσουμε το Zend για να “πάει πιο γρήγορα” η εφαρμογή που συντηρούσαν, ενώ ταυτόχρονα ο DBA μας ανακάλυπτε πως στη βάση δεν υπήρχε index πουθενά!

Θεωρία; Αυτά είναι για τους θεωρητικούς. Εμείς εδώ γράφουμε software που δουλεύει!

Αλήθεια;

(next)

Advertisements

3 Responses to “on problem solving”


  1. Ακόμα θυμάμαι τη συμβουλή εταιρίας να αγοράσουμε το Zend για να “πάει πιο γρήγορα” η εφαρμογή που συντηρούσαν, ενώ ταυτόχρονα ο DBA μας ανακάλυπτε πως στη βάση δεν υπήρχε index πουθενά!

    Δε σε πιστεύω!!!

  2. BruteForce Says:

    Η ευρύτερη διαπίστωσή μου (και η κατάσταση χειροτερεύει όσο περνάνε τα χρόνια) είναι ότι οι άνθρωποι που γράφουνε software ΔΕΝ γνωρίζουν πως λειτουργούν οι υπολογιστές και σαν μηχανές αλλά και βασικά τμήματα software όπως το λειτουργικό, ένας database server, κλπ. Φυσικά νομίζουν ότι γνωρίζουν, είναι 100% βέβαιοι ότι γνωρίζουν, αλλά δεν γνωρίζουν ή για να το πω καλύτερα δεν “κατέχουν” αυτή τη γνώση.

    Π.χ. από πραγματικό περιστατικό: όποιον και να ρωτήσεις “Τι είναι πιο γρήγορο, να γράψεις 1.000 φορές ένα αρχείο του 1ΜΒ και να το σβήνεις στο καπάκι ή να γράψεις 1 φορά ένα αρχείο των 1.000ΜΒ”?

    “Μα φυσικά το πρώτο” θα σου πουν.

    Κι όμως, οι ίδιοι άνθρωποι (και το συγκεκριμένο παράδειγμα είναι από μέγα και τρανό R&D Manager) σχεδιάζουν ένα σύστημα που κάνει 1 transaction με transaction log 1GB, αντί για 1000 transactions με transaction log 1MB το καθένα και μετά αναρωτιούνται γιατί κάνει τόση ώρα…

    “Μα ΟΟΟΟΛΟΙ ξέρουν ότι είναι πιο efficient να ενημερώνεις τις εγγραφές μαζικά σε ένα transaction αντί για μία-μία σε δικό της transaction”.

    Σε κάποιο βαθμό αληθεύει αυτό, αλλά όχι πάντα. Εξαρτάται από το case. Και ιδίως αν τα 1000 transactions είναι πρακτικά ανεξάρτητα μεταξύ τους και μπορούν να τρέξουν και παράλληλα, τότε τα 1000 transactions μπορεί να είναι 5-10 φορές πιο γρήγορα από το 1 big transaction. Αλλά για αυτούς π.χ. το transaction log είναι ένα abstraction, ένα irrelevant implementation detail.

    Όπως και ένα network connection φυσικά. Ποια δηλαδή η διαφορά του να φέρω κάποια data από τη RAM ή από τον database server; Και τι έγινε που ο προγραμματιστής έφτιαξε μια ωραία class για να κρύψει τα “dirty details” και καταλήγει μια και μόνη ρουτίνα να κάνει 1000 φορές το ίδιο query; Και τι έγινε που τα data που “κασάρει” η εφαρμογή από τη βάση είναι 180ΜΒ;

    Και το top για το τέλος (επίσης από πραγματικό παράδειγμα ελληνικής εταιρίας): “Τι έγινε που ο πίνακας CLIENT έχει 580 πεδία; Αυτή τη δουλειά θα κάνουμε τώρα να ασχολούμαστε με θεωρίες για normalization και physical design, να σπάμε τον πίνακα σε κομμάτια (vertical) και μετά να έχουμε να γράφουμε συνέχεια joins και να πολυπλοκεύουν τα queries; Έχουμε και ΔΟΥΛΕΙΑ να κάνουμε…”.

    Για να κλείσω, πολλοί softwarάδες, ιδίως όσοι μεγάλωσαν με .NET/Java ΔΕΝ ΚΑΤΕΧΟΥΝ πως πραγματικά δουλεύουν οι υπολογιστές (hardware & OS & software) με τα γνωστά αποτελέσματα. Δυστυχώς η ταχύτατη και αλματώδης πρόοδος στην υπολογιστική ισχύ τους επέτρεψε να κάνουν τη δουλειά τους ακόμα και να γίνουν “κάποιοι”. That’s life :-)

    Τώρα για πόσο ακόμα θα έχουν αυτό το “μαξιλάρι” δεν ξέρω…

  3. gvasilei Says:

    Megales alitheies ipothikan se auto to post! Pantos min xexnate oti otan prepei na lithei ena tetoio provlima sinithos o poio simantikos paragontas einai o xronos epilisis.

    An mia etaireia exei diathesimo kefalaio kai to Zend tha parei kai web server kai db server kai otidipote xreiastei gia na lithei to provlima amesa. Mono otan to diathesimo kefalaio den einai arketo gia na epilisei to provlima, tha ginoun to aparaitites energeies gia tin veltiosi tis apodosis tou logismikou.

    Auto to exo dei na ginete apeires fores kai se sistimata, poli pio artia organomena apo auta pou perigrafikan.

    Pros theou den leo oti den prepei na ginete prosektiki sxediasi tis efarmogis os pros tin apodosi, auto einai to autonoito!

    Telos pisteuo oti ta paradeigmata pou ipothikan parapano (na min xerei kapoios ti kanei to index se mia DB, i gia tin diafora ston xrono prosvasis dedomenon metaxi RAM kai sklirou diskou) einai akraia kai sigoura aforoun tin sintriptiki meiopsifia ton developers. Toulaxiston auto thelo na elpizo!


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: