Обновить
70
Антон Кортунов@ToSHiC

Программист

25
Подписчики
Отправить сообщение
Много подключений делать плохо как минимум по причине того, что при использовании TCP сокеты (не fd, а именно структуры под сокеты в ядре) могут тупо кончиться. Ещё вариант: при подключении делаются некие настройки соединения. Если подключаться в handleRequest(), то их каждый раз нужно будет делать.

А так, конечно, прям требованием подключение к базе в onLoad() не является. Делайте так, как лучше/быстрее в вашем случае. Своим комментарием я хотел подчеркнуть то, что onLoad() выполняется не в контексте тредпула, а из главного потока FastcgiDaemon при его инициализации.
Да, я в целом понял. Единственный момент — я не предлагал HDFS или нечто подобное вместо S3, скорее иметь штук 10 воркеров, на каждом по 1.2ТБ активных данных, и на них уже считать. Обменять стоимость 10 инстансов на стоимость прокачки данных через S3. Минусы сразу видны: эти 10 воркеров будет существенно сложнее сворачивать в часы наименьшей нагрузки, ну и вообще больше кода писать. Из плюсов — можно получить буст по скорости реакции. Ну и потенциально может быть экономия денег, но надо крайне внимательно считать.
На такой штуке уже можно делать нормальные экспедиции на Марс. В связи с этим вопрос: могут ли принципиально вышеописанные реакторы работать на поверхности планеты, не будет ли им мешать сила тяжести? Ведь главная проблема колонии на другой планете (после появления возможности вернуться обратно на Землю) — это недостаток энергии. Если аккуратненько приземлить туда реактор и заставить работать, то это будет существенным подспорьем. Охлаждать, наверное, вполне можно нагревая грунт, турбины тоже можно попроще и потяжелее поставить.
Какой суммарный объём исходных данных? Не будет ли эффективнее (в вашем случае — дешевле) работать самопальный MR, быстро считающий нужные цифры на машинах с данными (скажем, можно использовать тот же HDFS, но данные обрабатывать демоном, который постоянно запущен и запускает подсчёт по http запросу), и с recude фазой на вашем бэкэнде?
У вас всё смешалось: люди, кони… В смысле в тексте частенько x264, а в тексте командной строки x265. Не всегда до конца понятно, что там с чем сранивается. Четно говоря, из-за этой неразберихи я даже не понял, на скришотах то под h264 имеется в виду кадр из оригинального видео с BD-видео, или пережатый вами с «идеальными» настройками x264?
Оффтоп: фастеки на склоне удобно встёгивать?
У букинг.ком даже галочка есть, называется WiFi в разделе Facility (слева, там где звёздность можно выбирать).
По факту, если планируете перемещаться между несколькими странами, это практически единственный нормальный вариант. Если же будете только в одной стране, то можно и местную симку купить, но там всё грустно на тему лимитов. Разбаловали нас отечественные ОПСОСы.
Это да, но ею же можно крутить, а расширить полосу частот у квадрифиляра сложно.
А это особенность именно rtl чипа, или актуально для любой попытке приёма сигналов с малым SNR?
А дисконусная антенна, применительно к SDR, разве не лучше будет?
А я вас полностью поддерживаю :) Единственное что, 5МБ в качестве первого слоя не всегда круто, всё же нужен баланс между количеством слоёв и их объёмом. Конечно, тут уже нужно смотреть на свои образы и по ним изучать, что же можно назвать общей базой для бОльшей части из них.
А можете рассказать, зачем вообще пытаться делать минимальный размер образа? Ведь фича образов докера в том, что они состоят из слоёв вплоть до запуска контейнера. Если использовать aufs/overlayfs, то тот самый жирный базовый слой будет смонтирован только один раз, и будет пошарен между всеми контейнерами. При этом он будет один раз в page cache, что тоже положительно скажется на скорости работы и потреблении памяти.

В вашем же случае каждый контейнер уникальный, профита от переиспользования базового образа никакого. То есть, если запустить 100 контейнеров, собранных вашим способом, и 100 контейнеров, не ужатых, но с overlayfs, то второй вариант победит по потреблению page cache, а места на диске потребует незначительно больше.
Например потому, что жанр «оскарносные романтические комедии 1950х» — это на самом деле название кластера в многомерном пространстве параметров фильма. Каждый фильм, после проставления ему всех параметров по тому 36-страничному документа, это точка в N-мерном пространстве (судя по всему, там больше 100 параметров, то есть больше 100 измерений). Каким-то образом, на основе уже имеющейся базы оценок, точки объединяются в кластера, и для названия кластера выбираются наиболее значимые измерения.

Когда пользователь смотрит фильмы, рекомендательная система вырисовывает области предпочтений в том N-мерном пространстве, и ищет наиболее близлежащие кластера, и их подсовывает пользователю.
Судя по датам на форуме, вы 3 года угрохали в эту затею. Похвальная уверенность в результате!
На счёт питания по HDMI — это не правда. Всякие хромкасты питаются от usb того же телевизора, а не по HDMI.
В USB не бывает пассивных соединителей же, если вы хотите несколько устройств в один порт воткнуть, то нужен хаб. А раз есть хаб, то он может быть достаточно интеллектуальным, чтобы распределять энергию и включать разные профили питания на разных портах.
Эпл наконец то дожила до момента, когда не нужно делать док-станцию :) Можно подключать ноутбук одним шнурком к стационарному монитору, и будет там сразу и сеть, и USB, и картинка, и зарядка.
Около 10 лет назад сони выпускала UMPC. Не телефон, конечно, но ЕМНИП экран как раз в районе 6 дюймов был, и обычная винда. Так вот, щупал я такой девайс, неудобно им пользоваться. Слишком мелкое всё, каким нибудь вордом вообще нереально пользоваться. Всё же для мелких экраном нужен специальный интерфейс, который внезапно делают для приложений в андроиде/айос.
Намного опаснее не сама молния, а мощные турбулентные потоки, которые всегда бывают в грозовых тучах.

Информация

В рейтинге
4 321-й
Откуда
Россия
Зарегистрирован
Активность