gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] Re: Mirth setup, versions etc was Lab importing ...


From: richard terry
Subject: Re: [Gnumed-devel] Re: Mirth setup, versions etc was Lab importing ...
Date: Fri, 25 Jan 2008 08:40:08 +1100
User-agent: KMail/1.9.7

On Thu, 24 Jan 2008 06:18:34 pm Andreas Tille wrote:
> On Thu, 24 Jan 2008, richard terry wrote:
> > I got one really good reply from a guy about why my
> > mirth was being really slow to boot up in linux.
>
> It might be usefull if you would share the solution of
> your problem if there would be a general problem.
>

For sure, If I'd got around to figuring it out, however I enclose the guys 
post of what happens when MIRTH starts up. Havn't had time to see why mine is 
so slow:

===================================================
Form the MIRTH forum:

The first time you try to start the admin console, first it will download 
the .jlnp file, which shouldn't take too long, since it's a pretty small file 
(5K), but then, since it's your first time logging in, Java Webstart will 
have to download a huge amount of jar files to your local machine. Depending 
on your connection speed and server horsepower, this can really take some 
time.

But it only happens the first time you do the download from a machine.  After 
that, the jar files should already be there, and the admin UI should come up 
a bit faster.

I access remote Mirth servers over a satellite connection (I live in a rural 
area and that is my only option for broadband), and so it can take a little 
while for the admin UI to initialize, but after the first jar download 
process, it seems to be reasonable.

It could be reloading the jar files at home, the first time, if the internal 
versus external server names/url's are different.  But again, after the first 
time starting up from home, it should be faster.

Should be pretty fast if you're running the Mirth server on your local machine 
though, but keep in mind that laptops have very slow disk drives, so that it 
will probably take some time to boot up the Admin console, just having to 
access all the jars on the slow drive, plus the contention you'll get between 
the server process and the java-based client admin process.  Might depend on 
how much memory you have in your machine and allocated to the java JVMs as 
well, so that might be worth looking into.  The JVMs may be garbage 
collecting too much, or the OS could be thrashing a bit if the laptop is not 
tricked out with enough memory.

Not sure what you mean by myip in the url.  Are you running mirth server on 
your laptop?  If that is the case, then you should use localhost:8080.  Could 
be that if you are using myip (whatever that is) it's forcing the connection 
to go back to your office (over a VPN connection perhaps) and back again?

Don't think it has anything to do with the fact you are running Linux though.

I just ran a test on my laptop, with the latest 1.7 SVN build of 
Mirth.  Running both Mirth Server and the Admin client and Firefox on the 
same laptop.  My machine is a LG T1, with a 1.6ghz Core2Duo processor, 2.5GB 
memory, 4500rpm drive (prett slow!) and running Ubuntu Linux (Gutsy, 7.10).

Mirth server startup was only a few seconds,if that.

First time I hit the localhost:8080 in Firefox, it took a bit less than 50 
seconds to connect, do the java webstart stuff, download all the 
client-side/admin jars and present me with the login window.  Once I logged 
in, it took about 10 seconds till I saw the Channels display, with all my 
running channels (3 of them).

Second time I hit the URL, since the jars were already available, it took 
about 10 seconds till I got the login window.

Hope some of this stuff helps you to track down what might be causing the 
excessive load times...running locally, even on a slower laptop drive it 
shouldn't take that long, as my tests tonight indicate.
===========================================
>
>         Andreas.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]