4 ms·

This is nice and all but what about page load times? It can have all the bells and whistles but if you have to wait a minute for just one page to load, it's unu

by Walkman 10y ago

This is nice and all but what about page load times? It can have all the bells and whistles but if you have to wait a minute for just one page to load, it's unusable.

connorshea 10y ago
We've spent quite a bit of time this year improving performance, GitLab.com is still slower than it should be but it's a lot better now than it was in January. Self-hosted instances that meet the recommended specs are already fairly performant, though we're always working to improve things regardless. As mentioned in the blog post, this release we decreased page size a lot (from 1800kb to 718kb for a given Merge Request). We're also working on moving to our own infrastructure, the reasoning behind that move is described here: https://about.gitlab.com/2016/11/10/why-choose-bare-metal/ https://about.gitlab.com/2016/11/10/why-choose-bare-metal/ EDIT: Strike that, we've decided against moving to bare metal for now due to the complexity. I somehow missed that decision.
- napsterbr 10y ago
  Don't know exactly why you decided against moving to bare metal, but IMO you definitely should. We've got tremendous improvements moving to metal. I also can't recommend OVH enough. Best price on market plus great hardware and uptime. Technical support isn't the best but you shouldn't need it anyway.
  - lbotos 10y ago
    I also work at GitLab on a non-infra team. Here is Sid's explanation: https://gitlab.com/gitlab-com/infrastructure/issues/727#note_20044060 https://gitlab.com/gitlab-com/infrastructure/issues/727#note... I, personally, was apprehensive of going to bare metal for most of the reasons that Sid lists in the above message, and I think that making the app just _better_ is where we should focus before we try and run to pure hardware to solve the problem.
    - napsterbr 10y ago
      Thanks for the link. I understand the rationale, it's definitely not a simple decision, but if these improvements can be made at the application layer then by all means go for it.
      - sytse 10y ago
        Yes, we're going for the application layer improvements. For our work there please see https://gitlab.com/gitlab-org/gitaly https://gitlab.com/gitlab-org/gitaly
    - Rapzid 10y ago
      I look forward to seeing the open source libgit2 storage backends :)
- Keats 10y ago
  It's a bit better but still extremely slow (didn't try on premise). We're still using it instead of github because of the CI though
  - sytse 10y ago
    On-premises should be fast. Glad to hear you like CI. We're working on improving GitLab.com in https://gitlab.com/gitlab-org/gitaly/ https://gitlab.com/gitlab-org/gitaly/
- mikekchar 10y ago
  This probably sounds like a strange comment/question, but one of the reasons I haven't moved over to gitlab is that I know that it is unlikely that I will every be a paying customer. I actually don't mind that much about the performance issues (because I really just want cloudy git storage), but I don't like to take something for free unless I know the person giving it really wants to give it... So as strange as it sounds, are you happy with people like me moving to GitLab even though it may compound your performance problems?
  - chrismorgan 10y ago
    Networking effects are serious stuff. If you use it, you’re more likely to recommend it to others—or for public stuff, others will see you using it—and then they’ll start using it. And some of them will pay.
    - sytse 10y ago
      Exactly, free users can create familiarity with your product and awareness of your brand. We have a section about how to overcome the network effects https://about.gitlab.com/strategy/#sequence https://about.gitlab.com/strategy/#sequence
  - sytse 10y ago
    We're very happy with people moving to GitLab.com. We just want to warn them that it will take us time to sort out the performance problems. And over time we'll start monetizing it more, see https://about.gitlab.com/gitlab-com/#free-forever https://about.gitlab.com/gitlab-com/#free-forever for more information.
    - mikekchar 10y ago
      Thanks for that. Your link was actually useful because I didn't realise that you do builds as well. It is entirely possible that at some point this will be useful to me, so maybe I will become a paying customer after all. And if I can just say, the more actual services you add to your system (as opposed to SaaS features), the more likely I am to become a paying customer. For me, I really value free software. I'm not so interested in paying for proprietary SaaS features, and receiving free services. I'd much, much rather pay for services and use free software. Whether you can build a business around customers like me, I don't know, but I just wanted to make sure that you know there are at least some of us out there.

by Walkman 10y ago

This is nice and all but what about page load times? It can have all the bells and whistles but if you have to wait a minute for just one page to load, it's unusable.

connorshea 10y ago

We've spent quite a bit of time this year improving performance, GitLab.com is still slower than it should be but it's a lot better now than it was in January. Self-hosted instances that meet the recommended specs are already fairly performant, though we're always working to improve things regardless. As mentioned in the blog post, this release we decreased page size a lot (from 1800kb to 718kb for a given Merge Request). We're also working on moving to our own infrastructure, the reasoning behind that move is described here: https://about.gitlab.com/2016/11/10/why-choose-bare-metal/ https://about.gitlab.com/2016/11/10/why-choose-bare-metal/ EDIT: Strike that, we've decided against moving to bare metal for now due to the complexity. I somehow missed that decision.

napsterbr 10y ago
Don't know exactly why you decided against moving to bare metal, but IMO you definitely should. We've got tremendous improvements moving to metal. I also can't recommend OVH enough. Best price on market plus great hardware and uptime. Technical support isn't the best but you shouldn't need it anyway.
- lbotos 10y ago
  I also work at GitLab on a non-infra team. Here is Sid's explanation: https://gitlab.com/gitlab-com/infrastructure/issues/727#note_20044060 https://gitlab.com/gitlab-com/infrastructure/issues/727#note... I, personally, was apprehensive of going to bare metal for most of the reasons that Sid lists in the above message, and I think that making the app just _better_ is where we should focus before we try and run to pure hardware to solve the problem.
  - napsterbr 10y ago
    Thanks for the link. I understand the rationale, it's definitely not a simple decision, but if these improvements can be made at the application layer then by all means go for it.
    - sytse 10y ago
      Yes, we're going for the application layer improvements. For our work there please see https://gitlab.com/gitlab-org/gitaly https://gitlab.com/gitlab-org/gitaly
  - Rapzid 10y ago
    I look forward to seeing the open source libgit2 storage backends :)
Keats 10y ago
It's a bit better but still extremely slow (didn't try on premise). We're still using it instead of github because of the CI though
- sytse 10y ago
  On-premises should be fast. Glad to hear you like CI. We're working on improving GitLab.com in https://gitlab.com/gitlab-org/gitaly/ https://gitlab.com/gitlab-org/gitaly/
mikekchar 10y ago
This probably sounds like a strange comment/question, but one of the reasons I haven't moved over to gitlab is that I know that it is unlikely that I will every be a paying customer. I actually don't mind that much about the performance issues (because I really just want cloudy git storage), but I don't like to take something for free unless I know the person giving it really wants to give it... So as strange as it sounds, are you happy with people like me moving to GitLab even though it may compound your performance problems?
- chrismorgan 10y ago
  Networking effects are serious stuff. If you use it, you’re more likely to recommend it to others—or for public stuff, others will see you using it—and then they’ll start using it. And some of them will pay.
  - sytse 10y ago
    Exactly, free users can create familiarity with your product and awareness of your brand. We have a section about how to overcome the network effects https://about.gitlab.com/strategy/#sequence https://about.gitlab.com/strategy/#sequence
- sytse 10y ago
  We're very happy with people moving to GitLab.com. We just want to warn them that it will take us time to sort out the performance problems. And over time we'll start monetizing it more, see https://about.gitlab.com/gitlab-com/#free-forever https://about.gitlab.com/gitlab-com/#free-forever for more information.
  - mikekchar 10y ago
    Thanks for that. Your link was actually useful because I didn't realise that you do builds as well. It is entirely possible that at some point this will be useful to me, so maybe I will become a paying customer after all. And if I can just say, the more actual services you add to your system (as opposed to SaaS features), the more likely I am to become a paying customer. For me, I really value free software. I'm not so interested in paying for proprietary SaaS features, and receiving free services. I'd much, much rather pay for services and use free software. Whether you can build a business around customers like me, I don't know, but I just wanted to make sure that you know there are at least some of us out there.