Да собственно так же как и в справке. Что значит "не удается установить соединение с репозиторием"? Как вы это дело определили, давайте логи, будем посмотреть.
> Блин, только обрадовался, как выяснилось, что оно работает только под VMware, VirtualBox или под амазоновским облаком.
Вы во вкладочку https://www.hipchat.com/downloads не заходили?))
Не те же, ресурсов на одну виртуалку с кучкой контейнеров нужно выделять меньше, чем на кучку виртуалок. Можно как вариант посмотреть в направлении виртуальных сетевых адаптеров
А... ну дык вы бы сразу сказали, что "хостинг" - это dev окружение)) Единственное изменение для подобного окружения - билд каталог === рабочий каталог.
xfg
На сервере нужно 2 сетевых интерфейса. Публичный умеет в 80/443, в остальное умеет приватный.
Хотя... на счет ssh я наверное погорячился)) Исправлю ответ
@lucifer-m
Точно так же каки до этого ставил на эти несколько сотен пк. От вас он получает только скомпилированный бинарь.
Надюсь вы с УК ознакомлены))
Сергей
Монга сама по себе нагрузку не делает. Нагрузку создают запросы ее нагружающие. Вам необходимо определить, что именно ее ушатывает.
> это постоянное количество пользователей
нагрузка не меряется в пользователях)) Нагрузка меряется в Request Per Second (rps), количестве конкурентных подулючений (открытые tcp соединения), *bits/sec
Faer ))
Автор в контексте php спрашивал.
Основное время выполнения как правило тратится на input/output, а это и БД, и кэши, и HTTP, и очереди, и всякие ELK и т.д. PHP сам по себе как правило занимает малую часть времени выполнения, большую часть он ждет. PHP это не быстрый язык, это язык быстрых решений. И что бы эти быстрые решения были еще и надежными - проверки необходимы. Чем крупнее проект - тем более. Почему я писал выше.
> Я писал о системах реального времени т.к. они схожи с HL в том плане.
Не схожи. Системы реального времени под HFT например - вообще ни капли не схожи с системами, рассчитанными на web.
HL - это высоко-нагруженные системы, чаще всего задача: справиться с большим потоком трафика. Подождет клиент на 20мс больше, или меньше - это не так важно. Обычно это дело решается за счет распределения нагрузки между множеством серверов. Для части кейсов - распределение клиентов между разными ДЦ, по ближе географически к ним. С точки зрения бизнеса, как правило, дешевле надежный продукт нежели быстрый, но менее надежный.
Системы реального времени - это вообще другая задача, тут нужно выжать максимум из железа, потому что передавать запросы, даже по udp - это очень долго. Тут вполне прижились сетевые карты с обходом ядра и разнообразные FPGA под конкретные бизнес задачи. На Wall Street даже длинна кабеля имеет цену (меньше заплатишь - длиннее кабель будет). И про php тут речи быть не может.
> веб - это не только php )
Да я и не спорю, в компилируемых языках статической типизацией куча проблем php просто не существует.
вместо reload лучше в данном случае использовать restart
если php подключен через php-fpm - его нужно перезапустить тоже