$start = new DateTimeImmutable('1878-10-11');
$finish = new DateTimeImmutable('2009-10-13');
$interval = $start->diff($finish);
$daysDiff = $interval->format('%a');
$randomDays = rand(0, $daysDiff);
$randomDate = $start->add(new DateInterval("P${randomDays}D"));
echo $randomDate->format('Y-m-d'); // 1896-06-24
$t1 = (new DateTimeImmutable('1900-01-01T00:00:00'))->getTimestamp();
$t2 = (new DateTimeImmutable('1950-01-01T00:00:00'))->getTimestamp();
$t = rand($t1, $t2);
print (new DateTimeImmutable())->setTimestamp($t)->format(DateTimeInterface::RFC3339);
// 1915-10-14T19:08:14+00:00
Минусы как бы очевидны:нет, не очевидны, по крайней мере миллионам разрабов
1 Код становится трудно читаем. По месту использования не всегда понятно что имеется ввиду под Order::load() - \Framework\Sale\Order::load или \Vendor\Project\Sale\Order::load - приходится проматывать к верху файла.Вам как разрабу должно быть в принципе фиолетово, какой из пакетов используется, если они соблюдают один интерфейс. Если не соблюдают, при том что называются одинаково, значит все пошло не так задолго до проблем с определением пакета...
2 Код становиться длиннее - там где было бы просто:Код становится длиннее в проектах где 2 контроллера и в них по 1 экшену. Там где Extension::load будет вызываться больше одного раза, очевидно экономия на эксплуатации клавиатуры заметно увеличивается. А в больших проектах создание объекта может (и будет) повторяться многократно.
\Framework\Main\UI\Extension::load([ 'vendor.module.components.cabinet.personal' ]);
приходится писать:
use \Framework\Main\UI\Extension;
Extension::load([ 'vendor.module.components.cabinet.personal' ]);
4 Код становиться замусоренным, так как верхушки файлов запросто превращаются во что-то вроде:Если не обращать внимание на отсутствие пункта 3, то... нет, не могу не обращать внимание, вот же торопыга....
И хрен его знает используются импортированные классы ниже ещё или уже нет, ведь никто не убирает этот мусор.Хрен не знает, а ИДЕ замечательно знает и даже подсвечивает серым цветом неиспользуемые.
Есть необходимость писать в базу данных по 10к записей в секунду. .....Чтение относительно редко из бд происходит, только запись очень частаяНе проще писать в файл? Это не шутка. Если только писать и практически не читать. Логи nginx легко могут лететь с такой скоростью.
WebAPI браузера поедоставляет вещи типа setTimeout, или async await, коллбек-функции которые закидываются в очередь, а оттуда в порядке своей приоритетности попадают в стек по очереди. Промисы обрабатываются в приоритетном порядке.Обычные callback-функции не попадают в очередь, они вызываются в общем стеке. Кроме промисов в приоритетную очередь микрозадач функция может быть добавлена через queueMicrotask(function).
А что если "асинхронные" операции занимают много памяти и выполняются долго. Если они выполняются в том же стеке, то они также перекроют доступ ко всем остальным операциям?Асинхронные операции выполняются отдельными служебными потоками параллельно с основным стеком. Поэтому сами они не могут заблокировать основной стек. По завершению/таймеру асинхронная операция кладёт функцию в очередь микро- или макрозадач.
# Информация о 1000 файлов, может хранится в кеше. Если не было активности к файлу в течение 5 мин, то информация о нем удаляется из кеша
open_file_cache max=1000 inactive=5m;
# Активностью считается обращение к файлу хотя бы 2 раза. В кеш они также попадают, если было хотя бы 2 обращения к файлу
open_file_cache_min_uses 2;
# Вся информация о файлах в кеше обновляться раз в 1 минуту
open_file_cache_valid 1m;
# Сохранять ли информацию об ошибках, например, если файла, к которому вы обратились - нет, то это будет тоже в кеше, информация тоже обновится через 1 мин
open_file_cache_errors on;Здесь указывается
Как стоит поступить на многоядерной системе Debian 11 x64?
Говоря простым языком, на сайте может быть онлайн более одного человека при multi_accept off?
