dorty Geschrieben 11. September 2007 Teilen Geschrieben 11. September 2007 Hallo erstmal, also mein idee ist die folgende (weil wir es auf arbeit vermutlich eh bald brauchen): Grob: Ein Compiler-RamDisk-Cache-Synchronizer (lang und unverständlich *g*) Also wir entwickeln software in Delphi und dabei wälzt der Compiler ca. 150 mb übers netzwerk (gigabit-netz) das ganze dauert in etwa 3~7 min. (je nach projekt-grösse) .. (liegt daran das der compiler nur byte-weise liesst und dadurch die datenrate bei ca. 300 kb/sekunde liegt) also das ist ultra-lahm ... also dachten wir laut über solid-state-disks und ramdisks nach ... nun dacht ich mir das wäre doch ein schönes projekt wenn ich das für eine ramdisk realisiere. d.h. Die Software synch. (auf verschiedene überwachungs-ereig.) die Daten in der RamDisk mit dennen auf dem Server dadurch sinkt die warte zeit von einem 7min. normalen compile auf ca. 1min. (da wir zu 3't jeden tag ca. 40~70x mal compilen und zeit bekanntlich geld ist ...) aufjedenfall könnte ich die preise für RamDisk-Software und Solid-State-Disk vergleichen sowie vor/nachteile ... das ganze hat ein gewissen anspruch (daten-synch. beim starten projekt-verz. in ram kopieren etc.) also bwl mässig sowie programmatisch wäre da einiges drin, genauso wie eine produkt-besprechung etc.. (kann ja so tun als hätte ich es für einen kunden entwickelt ... die besprechung findet ja dann sowieso mit meinen chefs statt *g*) was denkt ihr darüber? MfG Dorty (FIAE) Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Schiller256 Geschrieben 11. September 2007 Teilen Geschrieben 11. September 2007 Im Moment kann ich dir nicht so ganz folgen das kann aber vielleicht auch an fehlenden Delphi Kenntnissen liegen. Was wirst du in diesem Projekt eigentlich machen? Wieso müssen beim Kompilieren Daten übers Netz geschickt werden? Bringe das mal in einen Antrag und packe da einen Zeitplan dazu. Im Moment sehe ich das eher als FISI Projekt und weniger als FIAE Projekt. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
dorty Geschrieben 11. September 2007 Autor Teilen Geschrieben 11. September 2007 also ich werde die Software schreiben welche den Datentransfer von der RamDisk auf den Server übernimmt (dort liegt der von der RamDisk rückgesicherte SourceCode welcher dort via RAID + Backup-System täglich gesichert werden muss) Da der Compiler aber langsam ist können wir nicht auf dem Netz-Compilen sondern brauchen eine insbesondere extrem schnelle lösung. deshalb die ramdisk, das problem diese ist ja flüchtig .. das programm welches ich schreiben werde, würde zB erkennen wenn eine neue datei in der ramdisk liegt bzw ein neuere und diese dann wenn die CPU-Last zB unter 20 % liegt oder mehr als 5min. vergangen sind oder der Client-PC hinterunterfährt auf den Server übertragen. Das heisst die Software muss die RamDisk-Überwachen und die Änderungen der dortigen Files möglichst schnell auf den Server übertragen, ebenso beim arbeitsbeginn muss die Software ein Projekt-Verz. vom Server in die RamDisk übertragen. Zeitplan *denk* mal ausm bauch raus: 1. Analyse - 4h Besprechung mit Kunden - 2h RamDisk/Solid-State & Co. Produkt vergleich bewertung. - 2h 2. Entwurf Konzeptionierung + Planung - 2h 3. Implementierung Installation Test-System - 1h Entwicklung - 24h 4. Testen Test-Planung: 1h Test-Durchführung: 2h Revision: 2h 5. Dokumentation 14 h Anwenderdokumentation 6 h Projektdokumentation 8 h ----> ca. 50 h (müsste ich mir zwar nochmal genau durch rechnen .. aber das müsste hinkommen) also die herrausforderung liegt in der programmierung einer intelligenten synch.-software zwischen RamDisk und Netzlaufwerk. ( zubillig? ) (** Das Problem ist das wir in der Firma keine Kunden-wünsche/Aufträge direkt umsetzen .. also muss ich so oder so eine standalone-app. schreiben **) Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Lizzy Geschrieben 11. September 2007 Teilen Geschrieben 11. September 2007 Verstehe ich das richtig? Ihr habt 150MB Source-Code und die liegen zentral in einer Netzwerkfreigabe und jeder bearbeitet Dateien auf dieser Freigabe und kompiliert aus dieser heraus? *hust* kein SCM? Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Kaladhor Geschrieben 11. September 2007 Teilen Geschrieben 11. September 2007 Die IHK wird dir als erstes sagen, dass dieses Projekt zu kurz ist (50h!). Dann wird die IHK wissen wollen, was genau du da eigentlich vor hast Speziell wird sie fragen, warum für einen Compile-Vorgang die Daten übers Netz gesaugt werden müssen...Setzt ihr nicht sowas wie subversion ein? Oder compilt ihr direkt von eurem Deployment aus???? :confused::confused::confused: Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
dorty Geschrieben 11. September 2007 Autor Teilen Geschrieben 11. September 2007 also ... nein die 150 mb sind nicht reiner sourcecode (das sind ca. 10~20mb [natürlich mit 3't sourcen]) und beim compilen werden natürlich OBJ-Files sowie tonnen weisse Debug-Files erzeugt .. die finalle exe hat ca. 30 mb ... die compiler einstellungen + optionen können wir nicht ändern (leider) unsere produktionsschritte werd ich hier jetzt nicht bis ins detail erklären aber es ist erforderlich das der sourcecode konstant auf dem server gesichert wird. (lokales arbeiten ohne ramdisk, also auf der festplatte, sind nur grade mal doppelt so schnell wie die netzlaufwerke ... [also schlicht auch noch zu lahm] na die zeit von 50h ist ja nur geschätzt .. je nach aufwand könnte ich die entwicklungszeit locker auf das doppelte aufblasen *denk, grübel, überleg* scm, cvs etc.. nee .. wir sind eine 3 coder firma da tun wir uns mit sowas nicht rumschlagen *g* (wir proggen modular und fügen diese dann zusammen) mhm ... doof ich fand die idee ganz nett .. aber ich seh schon es ist schwer das rüberzubringen. (ich mein mal ehrlich wir sparen da pro jahr ca. im schlimmsten fall 300 h im besten über 2000 h ... wenn das kein sinnvolles ding ist *g*) nagut muss ich nochmal überlegen ob ich was "anspruchsvolleres + leicheter verständliches finde (bringt ja nix wenn ich dann 2h brauch um zu erklären was das ding macht) Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Thanks-and-Goodbye Geschrieben 11. September 2007 Teilen Geschrieben 11. September 2007 Verstehe ich das richtig: statt den Hebel an der richtigen Stelle (dem Compiler) anzusetzen und zu überlegen, ob der Compiler dann das richtige Werkzeug darstellt, willst du unternehmenskritische Daten (und Sourcecode halte ich dafür) in einen flüchtigen Speicher laden? OK, jetzt kommt der Hardwareschrauber in mir raus, aber was machst du bei einem Absturz des Rechners durch ein defektes Netzteil? Dateninkonsistenzen sind doch bei deiner Konstruktion vorprogrammiert. Oder denke ich nur zu pragmatisch? Nun gut, man kann das auf die Spitze treiben und eine Workstation mit redundanten Netzteilen, USV und Notstromdiesel einsetzen. Der Pragmatiker sagt dir: dein Fachgespräch könnte ziemlich hart werden, wenn denn der Antrag überhaupt genehmigt wird. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
dorty Geschrieben 11. September 2007 Autor Teilen Geschrieben 11. September 2007 also ... der hebel an dem compiler der fehlt .. fehlt leider wirklich .. der compiler erlaubt es nicht den einlese-buffer zu erhöhen ... klar könnte ich den compiler decompilen und umschreiben aber dafür reicht die projekt arbeit lange nicht. ähm zu unternehmenskritschedaten + stromausfall etc. ganz klar wenn der strom weg ist etc. sind die daten der ramdisk auch weg .. das der punkt an dem mein tooly ins spiel kommt es überwacht die ramdisk via file-monitoring und bei der kleinsten änderung werden diese auf den server geschreiben ... (speichern eines sourcecodes über strg+s zB etc.) also max. auftrettende datenverlust beläuft sich auf *denk* 5min. idle time beim autosave. damit könnten wir locker leben ... es handelt sich nicht um kundendaten oder andere daten die nicht wieder herstellbar wäre ... zumal eine erneute-programmierung der verlorenen 5min. beim nächsten compile bereits wieder eingespart wären. (ausgehend davon das alle usv's versagen etc...) das der punkt wo eben solid-state-disks besser wären ... (aber halt auch schweine teuer bei der leistung die wir brauchen, diese aber genauso aufs netz aufgespielt werden müssten [wäre dann aber sozusagen zeitunkritisch]) Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
dorty Geschrieben 11. September 2007 Autor Teilen Geschrieben 11. September 2007 achja .. ein anderer compiler geht natürlich nicht ... da wir in delphi/pascal programmieren gibt es keine alternativen compiler die auch nur ansatzweise dieses level bieten. (sind sozusagen compiler-gebunden *g*) Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Lizzy Geschrieben 11. September 2007 Teilen Geschrieben 11. September 2007 unsere produktionsschritte werd ich hier jetzt nicht bis ins detail erklären aber es ist erforderlich das der sourcecode konstant auf dem server gesichert wird. Dann liegt in der Regel schon ein Planungsfehler vor. Wenn ich eine komplexe Funktion implementiere, die viel Zeit in Anspruch nimmt, muss ich Zwischenstaende abspeichern koennen, auch wenn sie nicht kompilierbar sind. (lokales arbeiten ohne ramdisk, also auf der festplatte, sind nur grade mal doppelt so schnell wie die netzlaufwerke ... [also schlicht auch noch zu lahm] Dann laesst sich auch bei Nutzung einer Ramdisk kein nennenswerter Geschwindigkeitsvorteil erreichen. 300 KB/s bei Netzlaufwerken, bei lokalen Laufwerken doppelt so schnell hiesse 600 KB/s. Ergo: Flaschenhals kann nicht der Datenspeicher sein. Jede halbwegs aktuelle Festplatte hat einen weitaus hoeheren Datendurchsatz. na die zeit von 50h ist ja nur geschätzt .. je nach aufwand könnte ich die entwicklungszeit locker auf das doppelte aufblasen *denk, grübel, überleg* Da braucht man nicht viel ueberlegen. Vorgabe sind 70h. scm, cvs etc.. nee .. wir sind eine 3 coder firma da tun wir uns mit sowas nicht rumschlagen *g* (wir proggen modular und fügen diese dann zusammen) Sorry... geht gar nicht. Bei komplexen Projekten lohnt sich ein SCM bei Teams > 0 Entwickler. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Thanks-and-Goodbye Geschrieben 11. September 2007 Teilen Geschrieben 11. September 2007 Hmmm... Also die Ramdisk-Software wollt ihr kaufen und du willst eine Art robocopy oder rsync-Variante erfinden? Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
dorty Geschrieben 11. September 2007 Autor Teilen Geschrieben 11. September 2007 nein lizzy ... zu 1: selbst verstündlich kann man zwischenstände speichern ... diese 5min. sind der autosave bei IDLE zu 2: die festplatten (sata) haben natürlich deutlich mehr power als 600 kb/s *g* die 600 kb/s entstehn durch die fast schon Random-Read-Zugriffe des Compilers ... (gib mir zeile aus quelltext ... gib mir zeile 1 von verwendeter komponente im quelltext ... etc ... das schleicht schon brutal ..) durch die ramdisk wird die unfähigkeit der festplatte 500mb (gesamt projekt volumen) auf einmal zu cachen übergangen zu 3: wusst ich nicht *seufz* ich hab da nur gelesen "projekt umfang von max. 70h .." und zu 4: mhm ... da könnte man jetzt drüber diskutieren ohne ende ... aber für uns erfüllt es schlicht keine funktion die wir brauchen ... unsere software ist und wir so entwickelt das es komplett überflüssig ist .. wir arbeiten niemals an ein und dem selben file geschweigeden am selben modul...blabla... aber zu deiner beruhigung *g* wir sichern den code täglich auf 6 versch. geräte (inkl. dezentralerSicherung). egal .. sag ja da könnte man ewig rumdiskutieren ... [darum sollte es im projekt ja auch nicht gehn *g*] nein nein .... ich werd mir was anderes überlegen (hab nur keine gescheide idee) ... was mich so ärgert ist das jeder schreiner als prüfstück ein schrank baut und als fachinformatiker man nicht einfach mal sagen kann ich bau ein hexeditor ... das bissel gestört ... na trotzdem an alle ein herzliches danke schön Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
dorty Geschrieben 11. September 2007 Autor Teilen Geschrieben 11. September 2007 @wiggum: jup rsync triffts relativ gut ... nur eben noch eine ecke rafinierter durch das aktive monitoring. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Schiller256 Geschrieben 12. September 2007 Teilen Geschrieben 12. September 2007 Ich habe bei deinem Projekt echt Bauchschmerzen, denn jetzt ist mir zwar klarer was du machen willst aber denn sinn dahinter mag ich im Moment nicht so recht verstehen. Wie Chief Wiggum schon richtig geschrieben hat würde ich da eher grundlegend über die Infrastruktur (Netz, Compiler) nachdenken als diese dann noch mit einer solchen Lösung weiter zu betreiben. Denn die schon angesprochen plötzlichen Ausfälle sind das eine, eine andere Sache wäre was ist wenn zwei Leute den gleichen Sourcecode ändern? Welcher dieser beiden Änderungen gewinnt dann auf dem Server? Was ist mit der Netzlast die auftritt weil ja ständig Daten auf den Server gesichert werden müssen? Dann zu deinen Zeitangaben wie schon richtig festgestellt muss dein Projekt 70 Std. umfassen. Zudem solltest du nicht auf viel mehr als 35 Std. für die Implementierung kommen. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Kaladhor Geschrieben 12. September 2007 Teilen Geschrieben 12. September 2007 nein lizzy ... zu 1: selbst verstündlich kann man zwischenstände speichern ... diese 5min. sind der autosave bei IDLE Das ist damit auch nicht gemeint gewesen. Aber ihr habt anscheinend überhaupt keine VersionsKontrolle.... ist es bei euch eigentlich möglich, einen älteren Entwicklungsstand wiederherzustellen? mit [sTRG]+ überschreibe ich beim Speichern alte Werte....das ist aber gerade beim entwicklen ziemlich mistig, da der normale Entwickler seltenst direkt die endgültige Programmierfassung eintippt. Ein Tool wie CVS oder SVN ist also dringenst geboten.... zu 2: die festplatten (sata) haben natürlich deutlich mehr power als 600 kb/s *g* die 600 kb/s entstehn durch die fast schon Random-Read-Zugriffe des Compilers ... (gib mir zeile aus quelltext ... gib mir zeile 1 von verwendeter komponente im quelltext ... etc ... das schleicht schon brutal ..) durch die ramdisk wird die unfähigkeit der festplatte 500mb (gesamt projekt volumen) auf einmal zu cachen übergangen Das deutet für mich eigentlich eher auf ein unstrukturiertes Projekt hin. Bin persönlich Java-Entwickler, und der javac ist wirklich nicht gerade der Schnellste.....habe hier ein Projekt mit einem Umfang > 700 MB, und selbst da bekomme ich nicht so langsame Werte hin wie du sie hier vorstellst. und zu 4: mhm ... da könnte man jetzt drüber diskutieren ohne ende ... aber für uns erfüllt es schlicht keine funktion die wir brauchen ... unsere software ist und wir so entwickelt das es komplett überflüssig ist .. wir arbeiten niemals an ein und dem selben file geschweigeden am selben modul...blabla... aber zu deiner beruhigung *g* wir sichern den code täglich auf 6 versch. geräte (inkl. dezentralerSicherung). egal .. sag ja da könnte man ewig rumdiskutieren ... [darum sollte es im projekt ja auch nicht gehn *g*] Und genau diese Vorgehensweise ist mit an Sicherheit grenzender Wahrscheinlichkeit um ein Vielfaches aufwändiger als das, was deinem geplanten Projekt zu Grunde liegt. Mach doch als Projekt die Einführung einer umfassenden Versionskontrolle im Entwicklungsprozess deiner Firma....wäre bestimmt sinniger.... Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Akku Geschrieben 12. September 2007 Teilen Geschrieben 12. September 2007 würde ich da eher grundlegend über die Infrastruktur (Netz, Compiler) nachdenken Es gibt definitiv keine Alternative zu Delphi. Was dem Microsoft seine MFC ist dem Borland seine BCL bzw. VCL, von daher wäre ein Produktwechsel (wer macht eigentlich noch Pascal unter Windows?) mit immensen Kosten und sehr hohem Zeitaufwand verbunden. Die Idee mit der Ramdisc ist schon mal nicht schlecht. Du must natürlich dafür sorgen, dass das Ganze ein wenig ausgebaut und ausgeschmückt wird. Nur: Erzähl dem PA ja nichts davon, dass ihr zu dritt per Netzwerk eure Sourcecodes gegenseitig auf dem Server zerschiesst. Das macht, -sagen wir mal vorsichtig-, keinen professionellen Eindruck. Eure Software wird lokal, und mittels der Ramdisc mit erhöhter Performance, kompiliert und am Ende des Tages mittels irgendeinem CVS System (Tortoise, WinCvs o.ä.) auf eurem Server synchronisiert? Dies war eine Frage;) Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Schiller256 Geschrieben 12. September 2007 Teilen Geschrieben 12. September 2007 Na dann habe ich das ganze vielleicht doch noch nicht verstanden. Wenn er lokal kompiliert und entwickelt für was braucht er dann noch die Netzanbindung? Ich bringe im Moment den Server und den Compiler noch nicht unter einen Hut. Was befindet sich wo und was wird dann synchronisiert? Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Akku Geschrieben 12. September 2007 Teilen Geschrieben 12. September 2007 Ich bringe im Moment den Server und den Compiler noch nicht unter einen Hut. Was befindet sich wo und was wird dann synchronisiert? Auf einem dezidierten Server liegen alle Sourcecodes. Innerhalb der IDE von Delphi wird nun ein Projekt kompiliert. Hierbei wird auf den Server refferenziert. Das heißt: Er zieht tatsächlich die zu kompilierenden Sourcecode-Dateien vom Server und überträgt (davon gehe ich jetzt mal aus) die kompilierten .obj-Dateien auf dem Server zurück, um letztendlich alle .obj Dateien wieder vom Server zu ziehen und mittels des Linkers eine .Exe zu machen. Solange jeder an seinen eigenen Code rumfummelt geht das noch. Wehe jedoch zwei Entwickler öffnen die selbe Datei, ändern diese und speichern sie wieder. Eigentlich unverständlich; aber jedem sein Grab Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Schiller256 Geschrieben 12. September 2007 Teilen Geschrieben 12. September 2007 Solange jeder an seinen eigenen Code rumfummelt geht das noch. Wehe jedoch zwei Entwickler öffnen die selbe Datei, ändern diese und speichern sie wieder. Eigentlich unverständlich; aber jedem sein Grab Genau das ist mein Problem denn ich kann mir beim besten willen nicht vorstellen das dieser Fall nie eintreten wird. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
dorty Geschrieben 12. September 2007 Autor Teilen Geschrieben 12. September 2007 seis drum .. sag ja da kann man drüber diskutieren und und und .. bei uns funzt das wunderbar (wir sind der meinung, das sogar besser als mit scm oder co.) klar wenn man seine projekte schlecht strukturiert brauch man so oder so ein scm ... oder wenn man gigantische quelltexte hat .. aber wiegesagt wir arbeiten sowieso modular weshalb der fall das zweileute am selben fall arbeiten schlicht nicht auftritt, wenn dies passieren können würde hätte einer von beiden blödsinn gemacht .. das hätte auch keinerlei konseq. außer das er das fremd-modul welches erverändert hat nachträglich auf dem server anpassen müssten ... aber egal ... egal ... *g* ich muss nu meine neue idee durch denken *g* Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
sxs Geschrieben 12. September 2007 Teilen Geschrieben 12. September 2007 Faszinierend, wir haben auch ne weile so gearbeitet. Nachdem wir uns zum x-ten Mal was kaputtgespeichert hatten, hat auch der letzte bei uns gemerkt das wir sowas brauchen. Das kann man nicht Schönreden! Nebenbei ist die Änderungshistorie eine wichtige Sache. Der Kunde setzt eine alte Version der Software ein, und hat nen Bug... Kein SCM ist nie eine gute Idee, ich benutze es sogar für Projekte an denen ich alleine arbeite. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Empfohlene Beiträge
Dein Kommentar
Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.