Schrift
Wiki:Tipp zum Debugging: use Data::Dumper; local $Data::Dumper::Useqq = 1; print Dumper \@var;
[thread]634[/thread]

Grundsätzliches Performanceproblem: Grundsätzliches Performanceproblem



<< >> 9 Einträge, 1 Seite
Gast Gast
 2005-12-28 16:34
#6427 #6427
Hallo,

ich habe Bugzilla bei mir installiert. Das läuft auch ganz gut, hab nur ein Performanceproblem beim Ausführen der enthaltenen Perl-CGI's. Bei allen Anforderungen dauert es bis zu 30 Sekunden, bis ich im Browser eine Antwort auf die Anforderungen erhalte. Wenn ich mir das Ganze im Taskmanager anschaue dann sieht das folgendemaßen aus:
Nach Absenden der Anforderung steigt die CPU-Last kurzfristig an (hauptsächlich von der perl.exe verursacht) und geht dann wieder zurück. Die perl.exe "dümpelt" jetzt erstmal 20-30 Sekunden vor sich hin und dann steigt die CPU-Last nochmals an und ich erhalte die Antwort im Browser. Jetzt frag ich mich was, macht Perl in den 20-30 Sekunden? Ist das Problem schon mal jemanden passiert?

Muss dazu sagen, ich hab von Perl keine Ahnung und will mich auch nicht unbedingt reinvertiefen.

Installation:
- win xp pro
- Apache/2.0.55
- Perl v5.8.7 build 813
- MySQL 5.0.15

Schon mal danke...
format_c
 2005-12-28 16:47
#6428 #6428
User since
2003-08-04
1706 Artikel
HausmeisterIn
[Homepage] [default_avatar]
Das script wäre ganz gut. Bzw. die Auschnitte wo du den Fehler vermutest. Hast du schon mal teile aus deinem Code auskommentiert um das Problem einzugrenzen? So ins blaue hätte ich jetzt gesagt du hast irgendwo ausversehen ein sleep 30 stehen. ;)

Gruß Alex\n\n

<!--EDIT|format_c|1135781344-->
Plinzen
 2005-12-28 17:00
#6429 #6429
User since
2005-12-28
3 Artikel
BenutzerIn
[default_avatar]
Also ein sleep ist nicht drin, denk ich mal.

Code: (dl )
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
#!/usr/bin/perl -wT
# -*- Mode: perl; indent-tabs-mode: nil -*-
#
# The contents of this file are subject to the Mozilla Public
# License Version 1.1 (the "License"); you may not use this file
# except in compliance with the License. You may obtain a copy of
# the License at http://www.mozilla.org/MPL/
#
# Software distributed under the License is distributed on an "AS
# IS" basis, WITHOUT WARRANTY OF ANY KIND, either express or
# implied. See the License for the specific language governing
# rights and limitations under the License.
#
# The Original Code is the Bugzilla Bug Tracking System.
#
# The Initial Developer of the Original Code is Netscape Communications
# Corporation. Portions created by Netscape are
# Copyright (C) 1998 Netscape Communications Corporation. All
# Rights Reserved.
#
# Contributor(s): Gervase Markham <gerv@gerv.net>
#

###############################################################################
# This CGI is a general template display engine. To display templates using it,
# put them in the "pages" subdirectory of en/default, call them
# "foo.<ctype>.tmpl" and use the URL page.cgi?id=foo.<ctype> , where <ctype> is
# a content-type, e.g. html.
###############################################################################

use strict;

use lib ".";

use Bugzilla;

require "CGI.pl";

use vars qw($template $vars);

Bugzilla->login();

my $cgi = Bugzilla->cgi;

my $id = $cgi->param('id');
if ($id) {
# Remove all dodgy chars, and split into name and ctype.
$id =~ s/[^\w\-\.]//g;
$id =~ /(.*)\.(.*)/;
if (!$2) {
# if this regexp fails to match completely, something bad came in
ThrowCodeError("bad_page_cgi_id", { "page_id" => $id });
}

my $format = GetFormat("pages/$1", undef, $2);

$cgi->param('id', $id);

print $cgi->header($format->{'ctype'});

$template->process("$format->{'template'}", $vars)
|| ThrowTemplateError($template->error());
}
else {
ThrowUserError("no_page_specified");
}



Das wäre zum Beispiel der Code von irgendeinem dieser CGI's. Ich denk aber eher nicht, dass das am Code liegt, kann man da irgendwie was debuggen (wenn möglich einfach)?

Ach ja, folgende Module hab ich im nachhinein noch installiert:
- AppConfig
- TimeDate
- DBI
- DBD-mysql
- TemplateToolkit
- MailTools
- GD
- Chart
- GDGraph
- PatchReader\n\n

<!--EDIT|Plinzen|1135782710-->
ptk
 2005-12-28 19:03
#6430 #6430
User since
2003-11-28
3645 Artikel
ModeratorIn
[default_avatar]
Weißt du, ob das Skript als mod_perl-Handler (Apache::Registry) oder als reines CGI-Skript läuft?
Plinzen
 2005-12-29 09:23
#6431 #6431
User since
2005-12-28
3 Artikel
BenutzerIn
[default_avatar]
Kann ich jetzt leider nicht genau sagen, aber das Problem tritt auch dann auf, wenn ich das Perlskript direkt mit dem Interpreter in der Dosbox aufruf.

also z.B. so:
perl -wT index.cgi

Er gibt mir zwar das richtige aus, es dauert nur, wie gesagt viel zu lang.\n\n

<!--EDIT|Plinzen|1135841017-->
GwenDragon
 2005-12-29 10:59
#6432 #6432
User since
2005-01-17
14538 Artikel
Admin1
[Homepage]
user image
Kannst du in der Dos-Box nicht mal den Perl Profiler und dprofpp laufen lassen? Dann siehst du die Engpässe. Natürlich auch Parameter eingeben!

Also:
Code: (dl )
1
2
perl -d:DProf meincgi parameter1 parameter2
dprofpp
\n\n

<!--EDIT|GwenDragon|1135847012-->
die Drachin, Gwendolyn


Unterschiedliche Perl-Versionen auf Windows (fast wie perlbrew) • Meine Perl-Artikel

ptk
 2005-12-29 11:08
#6433 #6433
User since
2003-11-28
3645 Artikel
ModeratorIn
[default_avatar]
Oder eher Devel::Trace:
Code: (dl )
perl -d:Trace meincgi parameter1 parameter2
Devel::Prof hilft, wenn die CPU die ganze Zeit beschäftigt ist, was hier ja nicht der Fall ist.
nepos
 2005-12-29 13:23
#6434 #6434
User since
2005-08-17
1420 Artikel
BenutzerIn
[Homepage] [default_avatar]
Eventuell wartet Perl in den 20-30 Sekunden auf die Datenbank...
Plinzen
 2005-12-30 09:24
#6435 #6435
User since
2005-12-28
3 Artikel
BenutzerIn
[default_avatar]
Hallo,

also ich hab das Ganze jetzt nochmal auf einem anderen PC probiert, da gehts wunderbar. Somit hat sich das ganze für mich erledigt. Herzlichen Dank für die Hilfe!
<< >> 9 Einträge, 1 Seite



View all threads created 2005-12-28 16:34.