mayton2019

Скорее всего прямой формулы не существует. Есть сравниительные подходы. Тоесть к примеру вы знаете уже такую конфигурацию которая "держит" 10 млн запросов. Вот смотрите как она реализована. Скорее всего это не один сервис а целый грид сервисов которые географически разбалансированы так чтобы каждая нода брала на себя часть нагрузки.

Почему в подобного рода задачах нельзя создать формулу? Ну формула - это скорее всего иммитационное моделирование всех уровней вашей системы в том числе сетевого стека и пользователей. По сложности эта модель близка к разработке самой системы. Поэтому я думаю что такой подход вам не нужен. Да и мало кому вообще нужен. Разве что атомный взрыв так моделируют.

Вместо вот этой колбасы

for (int c = zis.read(); c != -1; c++){
      out.write(c);
}

следует использовать из библиотеки Apache Commons IO

import org.apache.commons.io.IOUtils;

   IOUtils.copy(zis, out);

Для оптимизации загрузки landing page, можно хранить копии этой картинки в уменьшенном виде. 2000х1000 => 1000x500 => 500x250 e.t.c. Так игроделы делают для быстрого рендеринга текстур. Mip-уровни кажется называется.
Обновлять эти mip уровни можно не спеша. Через минутку.

База mysql вам вобщем-то не нужна. Картинку можно в реальном времени править atomic операциями и хранить в raw формате. Не знаю делают ли такое на PHP. Возможно вам нужен рукастый програмист на C++ или еще на каком-то языке чтобы подружить PHP с С++ и сделать сервис для этой картинки.

Можно попробовать сделать 2 фото. Одну во время дождя. А другую в ясную погоду. Со штатива и не двигая между снимками. Потом попробовать сравнить 2 фотки и посмотреть какие артефакты дает дождь.

Да и в данном вопросе есть два "хитрых" смысла. Есть художественный смысл. Типа улучшить фото. Этим занимаются художники. И есть смысл информационный. Например понять какой номер машины был замечен в плохую погоду и попытаться его распознать. Вот этот второй смысл - он про другое и к убиранию дождя не имеет отношения. Я-бы сказал что для систем машинного зрения лучше вообще дождь не фильтовать а сразу давать сырое на вход. Это более честно.

Я-бы предложил нарисовать граф зависимостей. Картинку со стрелками кто от чего зависит.
И дальше раскидать софт по железкам так чтобы при выходе из строя железки упало по минимуму
зависимых сервисов.

Вот нарисовать такой граф я не могу. Это наверное автор может.

try-catch - это эволюционно развитый if-else. Вот те кто кодили на "C" знают как тяжело работать с файловыми операциями. Любой fopen,fread e.t.c. надо проверять на код возврата и обеспечивать аварийный выход с очисткой (!) всех ресурсов. И вот отслеживание всех ресурсов и их состояний это нетривиальная задача. Для этого создали try-with-resources. И вообще возврат в это тяжелое мракобесное время проверок errorcode - никому не советую.

В случае с делением на 0 (ArithmeticException). Если вы рисуете на экране график функции - то возможна ситуация
где будет много делений на нуль. Тогда обработка исключений может стать performance issue. Это правда.

Может помочь декомпозиция формулы с делением на результат с Option[Int] (в Scala и Java это уже рабоатет) и возвращать неопределенное значение None в случае когда в знаменателе стоит ноль. Вообще в языках ФП данный подход очень рекомендуется т.к. в этих языках есть синтаксический сахар для быстрого сворачивания (flatMap) списков таких опциональных значений.

Тоесть если вы из функции хотите вернуть пустоту - то возвращаете None вместо бросания прикладных исключений.

Не спец в питонах. Но если getAll возвращает списки то их можно соединить через +.

list1 = xpath('//li[@class="section-list-item"]/a/@href').getall()
list2 = xpath('//a[@class="article-list-link"])/a/@href'). getall()
result = list1 + list2

Насколько я понимаю автору не нужно хостить всю музыку а только лишь делать по ней текстовый поиск.

Можно посмотреть в каталог MuzicBrainz https://ru.wikipedia.org/wiki/MusicBrainz

Ключевая фраза

Если отфильтровать данные по пользователю а затем по работе, то пагинация сломается (записей будет меньше, чем мы ожидали бы увидеть)

Мне кажется что здесь надо просто с бизнесом обсудить что собственно надо публиковать. С фильтрацией или без. А пагинация - это просто технический приём. К корректности результата вобщем то не имеет прямого отношения.

Дело в том что торрент архитектурно не различает качающих и раздающих. Все - суть участники одного сомнительного процесса обменом файлами. И ты становишся раздающим как только закачка достигает 100%.

Как на это смотрит закон - чорт его знает. Но мне кажется что важно скорее смыться с раздачи как только ты собрал полный релиз игры.

А если ты скачал порно-видео с несовершеннолетними и сидируешь - то нужно смыться тем более.

Можно посмотреть стандартный туториал по Spring+Mongo https://spring.io/projects/spring-data-mongodb

Хеш-таблица - это не массив. Хотя она может опираться на массив как на базовую структуру хранения (в случае метода открытой адресации). В классическом варианте хеш таблица - это совокупность структур данных в памяти. Массив массивов. Или массив списков (как будет угодно).

Про количество элементов - это сложный вопрос. Хеш таблица (ХТ) обычно резервирует памяти чуть больше чем надо. И экстендится когда памяти не хватает. Там для экстенда есть отдельный алгоритм. Можно считать что оверхед такой хеш-таблицы больше чем у массива. А количество элементов фактически - хранится отдельным счетчиков.

Вообще русская wiki достаточно хорошо описывает ХТ и можно начать читать с нее и далее по ссылкам.

Можно брать любой симметричный алгоритм и разделив его ключ на 2 половинки передать его лицам принимающим решение. Получается что-то вроде схемы Шамира. Нужен кворум людей чтобы сделать какое-то важное дествие.

Если я верно понял вопрос.

Возможно топик уже неактуален. Но я спрошу.

В наше время все хотят затащить в проект НС потому что это стильно и модно и кроме того наличие тега НС очень сильно может впечатлить заказчика. Но может быть настало время переосмысления НС и рассмотрения старых добрых проверенных методов?

Почему-бы не попробовать авто-корреляционную функцию. И если она будет лучше и проще - разве это не будет решением задачи?

Непонятно зачем в теме вопроса добавлено уточнение про GIL. Это специфика Python?

Добавлю что понятие процесса и потока может уж очень сильно отличаться в разных средах. Процесс в Erlang/OTP - это по сути актор который существует в сильной изоляции от всего остального мира и шарит память с другими процессами только через систему месседжей. Поток в Java - вообще не мапится в поток операционной системы.

Тоесть когда говорим о процессах и потоках то желательно сужать это определение до конкретной ОС и системы разработки.

Бесполезно учить АСМ в вакууме. Он - тоже часть экосистемы программирования железа и сетей. Если у вас например есть performance issue и требуется глубокий анализ того как С++ сгенерировал код и почему - тогда вам дорога в АСМ. Если такой задачи не стоит - то знания асма будут не нужны вообще.

Современные компилляторы настолько умны и сложны что их генерируемый код в большинстве случаев лучше чем тот ассемблерный код который может писать человек. Поэтому асм это не просто язык. Это обычно какая-то проблема которую нельзя или невозможно решить средствами соверменных компилляторов.

Чтобы просто почитать память процесса - ему можно послать сигнал SIGQUIT и он должен ссыпать самого себя в дамп файла. Это законный метод. Программист пытается понять state процесса.

Все прочие методы должны вызывать настоящий ужас спецов по инфо-безопасности. Кому понадобилось изменять чужие процессы? Какой юзкейс?

Если компиллятор глотает оба варианта и тесты проходят - то я-бы взял просто первый вариант.

Там меньше букв.

Для новичка лучше не использовать LVM. Помимо того что это легаси софт она еще и не самостоятельый. Все равно нужно затаскивать конкретные файловые системы. Это создает определенную путацицу и вообще - правильно использовать утилиты lvcreate/vgcreate/pvcreate и не напортачить при этом - большое искусство. Готов спорить что с 1 раза ничего не выйдет.

+1 к btrfs.

Вообще лучше взять какой-то старый диск который не жалко и на нем потренирваться а потом уж на нужных файлах.