Yes, is a little bit old...
Performance factors goes beyond VM in all this cases.. I don't say that is
VM fault...
I think is almost 100% our concer and every application or situation has is
issues. In the VM case there is a lot to tune and so is on the SO and the
infraestructure..
And I still think that Java doesn't scale well in this scenarios.. and for
now, as just said, i had better results with more than one instance of
geoserver with cpu affinity on multicore/cpus.
Still, I will have present all you have said because i'm very new to
Geoserver and I think you and another people on this list really know what
they talk about so i could always learn..
cheers,
facundo.-
On Fri, Apr 18, 2008 at 5:20 PM, Gabriel Roldán <[EMAIL PROTECTED]>
wrote:
> Hey Facundo, thanks for the document, it'll take me some time to ingest,
> but
> definitely seems worth to be read.
>
> Yet, it'll be hard to convince me that with a JRE 1.5 or 1.6
> threading/performance concern is the VM fault and not ours :)
>
> Though yeah, a quick look at the document actually makes sense as it
> evaluates
> JDK 1.4.
>
> Cheers,
>
> Gabriel
>
> On Friday 18 April 2008 10:09:14 pm Facundo Garat wrote:
> > Gabriel,
> > you are rigth on ntpl.. my mistake on this.. anyway, i haven't had good
> > expirience with java and multicores... and of course depends on how the
> > application was programmed...
> >
> >
> > In the case of starting more than one instance of geoserver with cpu
> > affinity, my test showme better results than leave OS/Java resolve the
> > problem in a multicore/multicpu environment..
> >
> > Here is more info (a little bit old but useful):
> > http://www.amitysolutions.com.au/documents/NPTL_Java_threads.pdf
> >
> > cheers,
> > facundo.-
> >
> >
> > On Fri, Apr 18, 2008 at 4:52 PM, Gabriel Roldán <[EMAIL PROTECTED]>
> >
> > wrote:
> > > On Friday 18 April 2008 09:26:27 pm Facundo Garat wrote:
> > > > In my expirience a saw that multiple core/cpu machine doesn't scale
> > >
> > > well
> > >
> > > > with java.
> > >
> > > As always, it is not just a matter of having the horsepower, but of
> using
> > > it.
> > > Modern servlet engines do use thread pooling and modern JVM threads
> spawn
> > > native OS threads.
> > >
> > > Problem is most programs are not programmed taking IO blocking issues
> and
> > > multi core/multi processor into account. If your process is serially
> > > programmed, it'll always use a single thread (ie, a single core) to
> > > accomplish its task. The challenge is in identifying more granular
> > > "execution
> > > units" that can be done in parallel for the same result.
> > > Same for IO. For example, if we were using non blocking io to write
> > > responses
> > > down to client, a single thread may be able to cope up with the taks
> of
> > > many
> > > responses, thus increasing scalability.
> > >
> > > > In unix/linux case, java is only one thread for the SO, so this
> really
> > > > doesn't explote all the cpu power...
> > >
> > > Actually I'm quite sure that's not true.
> > > A JVM instance will be seen as a single process in Linux, which is
> right
> > > to
> > > the point of being multithreaded: one OS process, many threads. This
> > > wasn't
> > > always like this, but since Linux introduced the nptl library (Native
> > > POSIX
> > > Thread Library) its able to spawn multiple threads for a single
> process.
> > > Before that, multi threading was emulated by forking a process, you
> you
> > > were
> > > able to see multiple pids/java processes for a single running JVM.
> > >
> > > > I see two options for multiple core/cpu. Working with cpu affinity
> for
> > >
> > > java
> > >
> > > > and postgres you could improve something the performance.
> > > >
> > > > Another option is, start multiple instance of geoserver all with cpu
> > > > affinity in diferent cpu for each java process and one cpu for
> > >
> > > postges...
> > >
> > > > One things you should have in mind memory..... analyze how GC affect
> > > > you and how much ram you give per java process and how much
> ram/process
> > > > you give to postgres. Avoid memory swapping of java or postgres
> process
> > > > at
> > >
> > > any
> > >
> > > > cost.
> > >
> > > That's funny I was just going to write my findings at fighting with GC
> > > issues
> > > and performance. Keep tuned.
> > >
> > > > Then, if you have intensive disk IO, you should use as many disk as
> > >
> > > posible
> > >
> > > > to avoid wait for IO.
> > >
> > > yup, those are all good advice, except I don't agree with the need to
> > > have multiple geoserver instances to take advantage of multiple cores.
> > > Just run a geoserver 1.6.3 on linux and send some concurrent requests
> > > while
> > > you have some CPU monitor open, will see a single request perhaps only
> > > uses a
> > > single core, and more concurrent requests do use more cores.
> > > You can also notice it by the fact that WMS and WFS requests response
> > > times
> > > are not affected by the number of concurrent requests up to the number
> of
> > > cores (despiting some little IO overhead maybe).
> > >
> > > Cheers,
> > >
> > > Gabriel
> > >
> > > > all of this is IMHO...
> > > >
> > > > hope this help.
> > > >
> > > >
> > > > cheers,
> > > > facundo.-
> > > >
> > > >
> > > > On Fri, Apr 18, 2008 at 3:46 PM, Gabriel Roldán <
> [EMAIL PROTECTED]>
> > > >
> > > > wrote:
> > > > > Arne, right to the point, nice summary.
> > > > >
> > > > > And yeah, we still have a lot of room where optimization could
> take
> > >
> > > place
> > >
> > > > > for
> > > > > both 1) and 2).
> > > > >
> > > > > I'll be hopefully doing some testing and may be even a proposal
> about
> > > > > this in
> > > > > the short term.
> > > > >
> > > > > Cheers,
> > > > >
> > > > > Gabriel
> > > > >
> > > > > On Friday 18 April 2008 05:24:52 pm Arne Kepp wrote:
> > > > > > There are two types of scalability,
> > > > > > 1) How many requests can you complete on average. I.e. if you
> > > > > > double the number of CPU cores, does the number of requests you
> can
> > > > > > respond
> > >
> > > to
> > >
> > > > > > per minute double?
> > > > > > 2) Given X number of CPU cores, how much quicker does a single
> > >
> > > request
> > >
> > > > > > return compared to running it on Y CPU cores?
> > > > > >
> > > > > > My experience, just from looking at CPU utilization on a 8 core
> > > > > > machine, is that we do well on 1) and poorly on 2). But for a
> > > > > > webservice the first one is much more crucial than the second,
> so
> > > > > > that's probably fine..
> > > > > >
> > > > > > As Justin pointed out, GeoServer is a Java Servlet [1], so we
> > > > > > expect
> > >
> > > to
> > >
> > > > > > do quite well on the first one. But we depend on at least two
> > >
> > > things:
> > > > > > A) You could have a limiting backend. Say Postgresql limited to
> a
> > > > > > certain number of threads, thereby stalling GeoServer.
> > > > > > B) The servlet container needs to be configured correctly. For
> > >
> > > Tomcat
> > >
> > > > > > that means enabling the thread pools in the configuration.
> > > > > >
> > > > > > So we do support multiple computational cores, but how well they
> > > > > > utilized depends on a lot of variables. If the number of
> > >
> > > simultaneous
> > >
> > > > > > requests exceeds the number of cores it's quite likely that you
> > > > > > will
> > >
> > > be
> > >
> > > > > > able to make full use of your hardware, but it may require some
> > > > >
> > > > > tweaking.
> > > > >
> > > > > > -Arne
> > > > > >
> > > > > > 1: http://java.sun.com/products/servlet/
> > > > > >
> > > > > > Mike Pumphrey wrote:
> > > > > > > Hi all. I rceived a question offline regarding
> > > > > > > GeoServer's/Java's utilization of multiprocessors and
> multicore
> > > > > > > processors, and I figured this would be the place to pose it.
> > > > > > > Does / how does GeoServer do parallel processing?
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Mike Pumphrey
> > > > > > > Outreach Engineer
> > > > > > > The Open Planning Project
> > >
> > >
> -------------------------------------------------------------------------
> > >
> > > > > > > This SF.net email is sponsored by the 2008 JavaOne(SM)
> Conference
> > > > > > > Don't miss this year's exciting event. There's still time to
> save
> > > > >
> > > > > $100.
> > > > >
> > > > > > > Use priority code J8TL2D2.
> > >
> > >
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/ja
> > >
> > > > > > >vaone _______________________________________________
> > > > > > > Geoserver-devel mailing list
> > > > > > > [email protected]
> > > > > > > https://lists.sourceforge.net/lists/listinfo/geoserver-devel
> > >
> > >
> -------------------------------------------------------------------------
> > >
> > > > > > This SF.net email is sponsored by the 2008 JavaOne(SM)
> Conference
> > > > > > Don't miss this year's exciting event. There's still time to
> save
> > >
> > > $100.
> > >
> > > > > > Use priority code J8TL2D2.
> > >
> > >
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/ja
> > >
> > > > >va
> > > > >
> > > > > >one _______________________________________________
> > > > > > Geoserver-devel mailing list
> > > > > > [email protected]
> > > > > > https://lists.sourceforge.net/lists/listinfo/geoserver-devel
> > >
> > >
> -------------------------------------------------------------------------
> > >
> > > > > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> > > > > Don't miss this year's exciting event. There's still time to save
> > >
> > > $100.
> > >
> > > > > Use priority code J8TL2D2.
> > >
> > >
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/ja
> > >
> > > > >vaone _______________________________________________
> > > > > Geoserver-devel mailing list
> > > > > [email protected]
> > > > > https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
>
>
--
-----------------------------------------
Facundo Garat Mayer
[EMAIL PROTECTED]
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
