Guten Morgen,
ich hab ein Problem, das derzeit nur theoretisch besteht, daher sind auch Antworten, die derzeit nur von theoretischer Natur sind, sehr willkommen.
Ich habe einen Web Service ein einer Hochsprache geschrieben, in der ich mich im unmanaged code Bereich selbst um die Speicherzuweisung und die entsprechende Freigabe kümmere.
Jetzt steht die Portierung in eine Sprache ohne großen Framework Overhead zur Diskussion (ich nutze für den WS Mono). Perl steht ganz oben auf der Liste.
Stellt euch bitte einen Web Service vor, der über SOAP calls entgegennimmt und generische Objekte als eigene Übergabeparamenter nutzt.
Der Web Service nimmt relativ häufig große Mengen an Binärdaten entgegen. (Wir reden hier von ca. 5 MB bis 1 GB pro Call).
Meine Frage ist nun eigentlich mehr eine Bitte um einen Denkanstoß:
Mit welchen Problem kann und muss ich bei der Portierung auf Perl bedenken (damit meine ich lediglich Speicher und Performance Probleme).
Ich bezweifle, dass Perl diese großen Speicherblöcke ohne irgendeine Art von "free" wieder _schnell_ an das Betriebssystem zurückgibt. Kann ich das Speichermanagement und die Größen der Byte Arrays auf eine peristente Art und Weise selbst beeinflussen?
Welche Punkte sprechen noch gegen eine Portierung eins solchen "Monsterprojektes" (bezogen auf Perl und Speichermanagement)...
Danke!
Joey
User since
2006-07-10
2611
Artikel
BenutzerIn
Ich vermute mal, daß Linux als Basissystem arbeitet, und da habe ich gute Erfahrungen mit "shared memory" als Speicher für Daten, über dessen Grösse man gerne volle Kontrolle hat, gemacht. (der auch Appliktionsübergreifend funktioniert) Man kann sich Speicher dynamisch binden und wieder frei geben.
Aber auch Perl geht recht sorgsam mit Speicher um wenn man die Variablen immer lokaisiert oder nach Gebrauch löscht ("delete").
User since
2006-02-08
30
Artikel
BenutzerIn
richtig, linux ist das eingesetzte betriebssystem und linux verfügt über eine gute dynamische speicherverwaltung.
ich gehe auch davon aus, dass perl innerhalb seiner grenzen vernuenftig mit seinen ressourcen umgeht. das problem ist, dass aufgrund der arbeitsweise (geringe anzahl an vordefinierten datentypen, interpretierte sprache) ein performance defizit auftauchen wird - diese muss ich irgendwie quantifzieren - gerne durch aussagekraeftige testszenarien.
die bei der verarbeitung von grossen datenmengen ausserhalb des physikalischen speichers (RAM) gearbeitet wird und daten ausgelagert werden, würde mich eben interessieren, ob diese grossen datenmengen zusaetzlichen (negativen) impact auf die performance haben und wie ich den messen / simulieren kann.
eventuell koennte man mit C - Funktionen in perl arbeiten und shared memory files nutzen. Aber damit verlaesst man natuerlich natives perl...
Joey
User since
2006-07-10
2611
Artikel
BenutzerIn
Du brauchst kein C um mit shared Memory umgehen zu können, das kennt Perl von sich aus. Du findest unter cpan einige module dazu, die aber für deine speziellen Ziele zu überdimensioniert sind. Mach es doch einfach so:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
#!/usr/bin/perl
use strict;
use warnings;
use IPC::SysV qw(IPC_PRIVATE S_IRWXU IPC_RMID);
my $maxbuf=1024; #Bite
my $startpos=0;
# Shared Memory reservieren:
my $key=shmget(IPC_PRIVATE, $maxbuf, S_IRWXU) or die "Konnte kein SHM bekommen ($!)\n";
# etwas rein schreiben:
my $wrt="TEST!";
shmwrite($key, $wrt, $startpos, $maxbuf) or die "Konnte in SHM nicht schreiben ($!)\n";
print "GESCHRIEBEN: $wrt\n";
# und wieder auslesen:
my $rd;
shmread($key, $rd, $startpos, $maxbuf) or die "Konnte in SHM nicht lesen ($!)\n";
print "GELESEN: $rd\n";
# den Shared Memory wieder frei geben:
shmctl($key, IPC_RMID, 0) or die "Konnte SHM nicht frei geben ($!)\n";
User since
2006-02-08
30
Artikel
BenutzerIn
danke, das ist doch schon mal ein guter Ansatz.
ich werd dann mal at least drei programme machen:
WS in mono
WS in perl
WS in perl mit shared memory
Mal sehen, wie sich die Performance bei den verschiedenen deployments auswirkt. Ich werds definitiv posten, hoffe, ich werd in der nächsten Woche fertig.
Joey