[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Performance Issues w/Ledgersmb 1.3.x



On Sat, Dec 3, 2011 at 19:51, Steven Marshall
<..hidden..> wrote:
> Looking for some help resolving a performance issue with Ledgersmb 1.3.7.  I
> originally had an earlier version 1.3.x installed on a Xen VM guest and
> things ran very slowly so I setup a new server without using virtualization
> and loading Ledgersmb pages is still extremely slow to the point it is not
> usable for production.  I don't have anything else running on the server and
> have not done any tweaking to Apache2, Perl, Postgresql, or openSUSE.  Here
> is my setup:
>
> Setup:
> Hardware: Poweredge 6400 Dual Xeon 700 Mhz processors w/1 Gb of RAM
> OS: OpenSUSE 12.1
> Applications: Ledgersmb 1.3.7 (Base setup with Postgresql 9.1, Apache2, and
> Perl 5.14.2)
> Network: Currently only using my private network (i.e. 192.168.1.x).  There
> is very little traffic on this network and in most cases I am the only one
> on the network.
>
>
>
> I ran the following test:
>
> Test 1; Connecting to Apache's default html page from laptop to server via
> WiFi
>
> URL: http://192.168.1.10
>
> Results: I get Apache's "It works!" page in less than a second
>
>
> Test 2; Connecting to Ledgersmb's setup.pl from laptop to server via WiFi
>
> URL: http://192.168.1.10/ledgersmb/setup.pl
>
> Results: It takes on average about 13 seconds for this page to open.
>
>
> Test 3; Connecting to Ledgersmb's setup.pl directly from server.
>
> URL: http://localhost/ledgersmb/setup.pl
>
> Results: It takes on average about 4 seconds for this page to open.  Same
> thing if I substitute 192.168.1.10 for localhost in the server's browser.

This is starting to sound suspiciously like a DNS problem, not a
LedgerSMB problem.

First check /etc/resolv.conf, then use dig (dig google.com).  Near the
bottom of the output, you should see the server used.  That server
should be the first in the /etc/resolv.conf list.

Run a tcpdump and watch port 53 -- see what you get (or don't get).

>
>
> Test 4: Traceroute test from laptop to server
>
> C:\Users\Steven Marshall>tracert 192.168.1.10
>
> Tracing route to ledgersmb.tekmerge.com [192.168.1.10]
> over a maximum of 30 hops:
>
>   1     1 ms     2 ms     1 ms  ledgersmb.tekmerge.com [192.168.1.10]
>
> Trace complete.
>
>
>
> It doesn't appear to me while running "top -i" on the server that it is
> being heavily taxed.  My initial thought was there was something wrong with
> the router until I loaded the Apache's default page and it loaded almost
> instantaneously so that seems to tell me the bottleneck is specific with
> ledgersmb.  It would also seem to be specific to connecting via a computer
> and not directly from the server.  I have ran these test from several
> browsers on my laptop along with my iPad all with the same results.
>  My suspicion is the bottleneck is due to apache waiting for postgresql to
> respond, but I don't really have anything to base that on other than
> watching (i.e. tail -f) the Apache logs when their appears to be a delay
> before Apache's response gets written to the log. That being said, I don't
> know if just loading the setup.pl page actually requires a connection to the
> database server. Has anybody else experienced this issue or anyone have any
> suggestions how best to troubleshoot this?

You would be surprised at just how badly DNS can slow things down.

Ciao,

David A. Bandel
-- 
Two things are infinite: the universe and human stupidity; and I'm not
sure about the the universe. -- Albert Einstein
Visit my web page at: http://david.bandel.us/