On Thu, Nov 1, 2018 at 11:11 PM Gabriel Roldan <[email protected]>
wrote:
> Hello,
>
> I can't comment on app schema tests nor splitting security out of main,
> although the latest sounds like a good idea and will probably lead to a bit
> of decoupling which should be a good thing, say you want a stripped down
> version of geoserver with no security at all, then you could go for it. But
> maybe I'm just talking out of ignorance here.
>
Eh, I agree it would be a good idea, but like you I'm not familiar enough
with it to tell if that would be feasible, or not.
> What I do want to bring to the table is two things:
> - On build.geoserver.org, there's a tmpfs mount at /mnt/memtmp that can
> be used to speed up the build by means of avoiding tests to hit the disk so
> much. We've done that for the geogig builds and it helped a lot. Would just
> need to add the following JVM argument to the build:
> -Djava.io.tmpdir=/mnt/memtmp/geoserver
> Last time I checked (a rather long time ago) the build left quite a bit of
> garbage in /tmp (though not sure of it was geoserver's or geotools' build
> that left the most).
>
Believe it's mostly GeoTools, but might be wrong. The quantity of garbage
left in /tmp has been reduced a lot compared to many years ago, but there
is still a good bunch lying there
that one day or the other we should try to kill.
> This could also be an opportunity to avoid flooding the build server with
> that many remanents (it ran out of disk space once upon a time due to
> that). To do so we could run a post build shell script that just removed
> everything in /mnt/memtmp/geoserver, if no two builds will ever run in
> parallel. Otherwise it'd be cool if the tmp directory could be parametrized
> on a per build basis, like in running a pre build script that creates
> /mnt/memtmp/${build.number} or so, and a post script that removes it.
>
Right. The GeoServer build creates and destroys a lot of data dirs, one per
test class normally, that all live in ./target/ (current module's).
Profiling surefire on a full module build (tried both wms and wfs) did not
show IO to be dominant though, the results are very spread out
and the only consistent bits showing in every module are related to
classloading, the rest tend to change module by module.
The first I/O related bit is like in 10-15th position (but I have a fast
SSD in this machine, the situation might be different on others).
However, since most temp directory handling is centralized inside
SystemTestData, I've created a 1GB ramdisk and
had that class create all data dirs in it, then made SystemTestData create
the data dirs in it.
Doing a -T6 builds (seems to be the fastest on my machine, at around
440seconds unmodified), I got a 430s build time...
an improvement of 10 seconds can be random swinging, but even if it was
not, does not look like worthwhile :-)
> - The other thing I'd like to mention, although a bit off topic, is a what
> if the main codebase is reduced. That is, _IMHO_, the current policy for
> both gt and gs of allowing almost anyone to create almost any community
> module on the main codebase is rather archaic. What do you guys think of
> creating sibling projects under each project github organization to hold
> those (that is, github.com/geoserver/community and
> github.com/geotools/unsupported)? After all, one should (would, could)
> keep an unofficial project/module as an independent project until deemed
> good enough to ask to be included as an unsupported module, and then just
> once it's good enough for the main codebase be moved to it, instead of
> flooding it with runaway unsupported modules?
> I don't know, I think that could work out pretty well.
>
Community modules are not built on a normal build on a dev machine, the
customary command line is "mvn clean install -TX -nsu -Prelease" which
leaves them out.
On the build server they do account for 8 minutes out of 31 total on the
jenkins build server, and only 6 out of 41 minutes on Travis,
however at the moment I'm mostly concerned about developer productivity, as
everybody participating in the JDK 11 code sprint has experienced,
having to wait 7-9 minutes for a full GeoServer build is a tad too much
imho (timings out of my machine, overall build time varies a lot
depending on what else I'm doing during the build)
Cheers
Andrea
--
Regards, Andrea Aime == GeoServer Professional Services from the experts!
Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime
@geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054
Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339
8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it
------------------------------------------------------- *Con riferimento
alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 -
Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni
circostanza inerente alla presente email (il suo contenuto, gli eventuali
allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i
destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per
errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le
sarei comunque grato se potesse darmene notizia. This email is intended
only for the person or entity to which it is addressed and may contain
information that is privileged, confidential or otherwise protected from
disclosure. We remind that - as provided by European Regulation 2016/679
“GDPR” - copying, dissemination or use of this e-mail or the information
herein by anyone other than the intended recipient is prohibited. If you
have received this email by mistake, please notify us immediately by
telephone or e-mail.*
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
