Re: Some issues.

> Â> 2. ÂResponse time is quite slow. ÂI substituted my old server (Pentium
> Â> II, 333 MHz) only recently with an 2,8 GHz and 1,5 GB RAM, but
> Â> typically, it takes 6-8 seconds to most screens to show up after I have
> Â> clicked on my selection.
>
> That's really way too slow. I have - privately - a relatively slow Intel
> Atom "server" with 2 GB RAM running in the Czech Republic (I'm in the
> Netherlands myself). The response times are less than a second (except
> for login which takes 2 or 3) where I use wifi for my local network
> connection.

Thank you for responding. ÂAnd such response times for me also would be
really nice! :-) ÂMy network is cabled 100 MBit.

Ok. Then at least the wired setup can't be your issue.

> It'd be interesting to understand if this is due to your local network
> or that it is really your server taking this much time to process the
> response.

I have thought of that, and I do have some strange issues with DNS; now
and then I have to restart BIND to get it working.

To get LedgerSMB working? Or to get the server working at all? I mean, you say that you're using intranet on the same server. Does intranet work when you have to restart BIND "to get it working"?

ÂMy setup files are
copied from my old server and should be correct (of course I might have
missed something). ÂAnd I've changed the local domain name after setup,
but so far i have not found any old domain name strings hanging around.

The 'ledgersmb.conf' file usually contains the name of the host to be used as the database IP connection host. If you're using a database on the local host, it's best to enter 'localhost' there - not the name of the host in the DNS.

Actually, what I do when I run against a database which is local, I enter the unix domain socket file's directory as the host name. On my debian system that'sÂ/var/run/postgresql/. This reduces chances of your firewall interfering with your database connection.

Â But it certainly can be some problems here (at least I hope so, so it
can be fixed), any hints to track this down?

The only errors I can find is this and seems related to login:

/var/log/postgresql/postgresql-9.1-main.log:
2013-07-14 16:53:58 CEST LOG: Âcould not receive data from client:
Connection reset by peer

/var/log/apache2/error.log:
[Sun Jul 14 16:53:58 2013] [error] [client 192.168.1.1] DBI
connect('dbname=nix','',...) failed: fe_sendauth: no password supplied
at LedgerSMB.pm line 986, referer: http://ledgersmb.kingel.net/login.pl

Hmm. if you're able to log in afterwards, this is a bit unexplicable. Does this happen on every page? or just when logging in?

> Did you try requesting a static file from the server?
> Did you set up a CGI or a CGId setup?
> Do you have other applications runningon the server?

I do run Apache for "normal" intranet pages (static or PHP) and they
show up immediately. ÂI run local DNS (bind9) and lsmb and couple of
other "sites" is set up as virtual hosts (I access lsmb using URL
ledgersmb.kingel.net). ÂBut my server is in no way busy, there is only
one user (me). ÂOnly LSMB is slow.

As for CGI og CGId setup, I'm not sure what you're asking, sorry there
are many holes in my knowledge about these things. ÂI followed the
INSTALL file instructions. Â:-/

Ok. Then your setup is most likely CGI. CGI is a bit slower than CGId, but that can't account for the difference in speed.

I have this in /usr/share/postgresql/9.1/pg_hba.conf:
host Â Âall Â Â Â Â Â Â all Â Â Â Â Â Â 127.0.0.1/32 Â Â Â Â Â Âmd5
host Â Âall Â Â Â Â Â Â all Â Â Â Â Â Â 192.168.1.0/24 Â Â Â Â Âmd5

Ok. I assume you have restarted the postgresql server after you changed its configuration files (such as pg_hba.conf)?Â

> There is one remark: if your setup is configured to cache compiled
> templates, the first request to a certain page may take longer. Further
> requests should be answered much quicker. This is a one-time hit -
> usually once per upgrade. ie the first request takes longer and then all
> requests until the next application upgrade don't.

Again I'm unable to answer. ÂI can't remember to have to take any
actions in this respect...

Bye,

Erik.

http://efficito.comÂ-- Hosted accounting and ERP.

Robust and Flexible. No vendor lock-in.