I've deployed a docker gitlab instance for my workplace. We also struggled
with poor performance.
Gitlab 9.5 has made things noticeably better. What also helped greatly was
increasing the RAM allocated to the machine.
On Fri, Aug 25, 2017 at 10:45 AM, Carlos Soriano wrote:
>
Just a quick update about performance. Seems their "performance team" is
starting to bring some results, in the last release they report
improvements in several places. You can take a look at
https://about.gitlab.com/2017/08/22/gitlab-9-5-released/#performance-improvements
Cheers,
Carlos Soriano
On Fri, Aug 11, 2017 at 08:48:34PM +0200, Carlos Soriano wrote:
> Bugs can be migrated with https://gitlab.com/aruiz/gitlab-gnome-tools, is
> up to the maintainer what to do with them.
Note that this script has a lot of things it does NOT handle. As agreed
with Alberto I'm going to fork this into
And "that was a couple of seconds for me no cache involved whatsoever"
was for gitlab.com
2017-08-15 2:38 GMT+01:00 Michael Catanzaro :
> On Mon, Aug 14, 2017 at 5:15 PM, Alberto Ruiz wrote:
>>
>> That was a couple of seconds for me no cache involved
On Mon, Aug 14, 2017 at 5:15 PM, Alberto Ruiz wrote:
That was a couple of seconds for me no cache involved whatsoever. I am
pretty sure our numbers are GNOME infra related.
But that 17-second result was for gitlab.com, not for us.
Ok thanks for testing Michael. I just tested in Incognito Window and with
different browsers and it was fast (2 secs). So it looks like it's random.
I guess there is a bug around.
On Tue, Aug 15, 2017 at 12:15 AM, Alberto Ruiz wrote:
> 2017-08-14 22:55 GMT+01:00 Michael
2017-08-14 22:55 GMT+01:00 Michael Catanzaro :
> On Mon, Aug 14, 2017 at 2:08 PM, Carlos Soriano wrote:
>>
>> Can you try with https://gitlab.com/gitlab-org/gitlab-ce/commits/master?
>> It took me 1 second.
>
>
> 17 seconds here on my first attempt.
On Mon, Aug 14, 2017 at 5:03 PM, Carlos Soriano
wrote:
Ok, I'm happy if the cache at least work and won't hit that hard on a
daily basis.
But it's true is weird, I can raise this concern and see where they
are at.
Just checking, did the second time in our instance went
Ok, I'm happy if the cache at least work and won't hit that hard on a daily
basis.
But it's true is weird, I can raise this concern and see where they are at.
Just checking, did the second time in our instance went faster? I can
definitely feel it slower than previous weeks, in general.
On Mon,
On Mon, Aug 14, 2017 at 2:08 PM, Carlos Soriano
wrote:
Can you try with
https://gitlab.com/gitlab-org/gitlab-ce/commits/master? It took me 1
second.
17 seconds here on my first attempt. Wy too long. That suggests
it's not a GNOME hosting problem. But I tested that
Can you try with https://gitlab.com/gitlab-org/gitlab-ce/commits/master? It
took me 1 second.
On Mon, Aug 14, 2017 at 7:47 PM, Jens Georg wrote:
>
> > > Ah yes, this is slower than before, this was not the case with our
> > > instances few weeks ago.
> > >
> > > I need to check
> > Ah yes, this is slower than before, this was not the case with our
> > instances few weeks ago.
> >
> > I need to check with Andrea.
>
> I tried to load the commit log for json-glib (from North America)
> and
> it took 28 seconds. With our cgit the page loads in maybe half a
> second.
On Mon, Aug 14, 2017 at 5:29 AM, Carlos Soriano
wrote:
Ah yes, this is slower than before, this was not the case with our
instances few weeks ago.
I need to check with Andrea.
I tried to load the commit log for json-glib (from North America) and
it took 28 seconds. With
Ah yes, this is slower than before, this was not the case with our
instances few weeks ago.
I need to check with Andrea.
On Mon, Aug 14, 2017 at 12:25 PM, Emmanuele Bassi wrote:
> Considering that large repos on gitlab.com — like, say,
>
Considering that large repos on gitlab.com — like, say,
https://gitlab.com/gitlab-org/gitlab-ce/commits/master — are faster
than gitlab.gnome.org, I think the issue is on our end, unless
GitLab's enterprise edition is more optimised than the community
edition.
Ciao,
Emmanuele.
On 14 August 2017
On 14 August 2017 at 10:02, Jens Georg wrote:
> I'm currently massively underwhelmed by the overall performance and
> snappiness of the web interface, even for a small project with not that
> much commit history.
Right; I also found that when sitting In London browsing
On Mon, 2017-08-14 at 11:02 +0200, Jens Georg wrote:
> > Hello all,
> >
> > As you may know we continue working and pushing for our transition
> > from Bugzilla and cgit to GitLab.
> > Similarly to what we said in the previous mail thread, we are still
> > in
> > the pilot program phase, that
Hello all,
As you may know we continue working and pushing for our transition
from Bugzilla and cgit to GitLab.
Similarly to what we said in the previous mail thread, we are still in
the pilot program phase, that means projects that go into our real
deployment at gitlab.gnome.org [1] are still
Hi.
On Fr, 2017-08-11 at 14:37 +0200, Carlos Soriano wrote:
> Also I hope in the time frame of 3-4 months the pilot program is successful
For completeness sake:
Are we still considering to *not* move to Gitlab if that pilot is not
successful?
How do we measure "success"?
Cheers,
Tobi
Yeah I guess, when the full migration is done, if the maintainer wants to
migrate the bugs, we will use that tool.
On Sat, Aug 12, 2017 at 4:48 PM, Sébastien Wilmet wrote:
> On Fri, Aug 11, 2017 at 08:48:34PM +0200, Carlos Soriano wrote:
> > Bugs can be migrated with
On Fri, Aug 11, 2017 at 08:48:34PM +0200, Carlos Soriano wrote:
> Bugs can be migrated with https://gitlab.com/aruiz/gitlab-gnome-tools, is
> up to the maintainer what to do with them.
OK, and when the full migration will be done for all GNOME modules, do
you already know if that script will be
Bugs can be migrated with https://gitlab.com/aruiz/gitlab-gnome-tools, is
up to the maintainer what to do with them.
Best,
Carlos Soriano
On Fri, Aug 11, 2017 at 5:06 PM, Sébastien Wilmet wrote:
> On Fri, Aug 11, 2017 at 02:37:41PM +0200, Carlos Soriano wrote:
> > As usual,
On Fri, Aug 11, 2017 at 02:37:41PM +0200, Carlos Soriano wrote:
> As usual, feel free to ask any questions in this thread or personally to
> Alberto Ruiz or me, we are happy to answer.
Are all the bugs on bugzilla also migrated when a module moves to
GitLab? How is that handled currently?
--
Hello all,
As you may know we continue working and pushing for our transition from
Bugzilla and cgit to GitLab.
Similarly to what we said in the previous mail thread, we are still in the
pilot program phase, that means projects that go into our real deployment
at gitlab.gnome.org are still
24 matches
Mail list logo