> > 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.
------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
Ledger-smb-users mailing list
Ledger-smb-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-users
