Кого поставить на апач? Наверняка ваш nginx уже собран с этим модулем, как, например, в репозиториях debian. Вот и допишите в конфиг использование этого модуля. Ну а если не собран - то придётся пересобрать кастомный nginx.
Клонировать каждый объект коллекции в отдельности. Например,
public static function getItems(){
return array_map(function($el) {
return clone $el;
}, self::$arItems;
}
Статический класс здесь значения не имеет. По ссылке передаются сами stdClass
WeReng: это расходник. Всегда считайте, что можете в любой случайный момент времени потерять все на него записанные данные.
Плюсы и минусы:
сдать по гарантии - до 45 суток его могут держать в СЦ согласно этому самому ЗоЗПП (насчёт условий выдачи подмены на этот срок не помню точно, надо уточнять). Минимум и в среднем - в зависимости от СЦ. Есть вероятность, что они сами запустят это же самое восстановление, диск исправится и его же вам вернут через пару дней. Но есть и вероятность, что диск вам заменят на новый с новой гарантией.
запустить программу самому - соответственно, если поможет, то у вас уже не будет повода обращаться в СЦ. Если не поможет - то в СЦ всё равно (и повыше вероятность замены).
Вот по-моему и вся разница.
Hello1: проблема в формулировке. Накопитель должен читать-писать свой номинальный адресуемый диапазон LBA. Если этого не происходит либо происходит с ошибками - да, это гарантия. Если же всю свою адресуемую ёмкость диск читает и пишет - значит диск исправен. И никого не волнует, что это достигнуто резервной областью диска и ремапами неисправных секторов в эту область. Если просто в каком-то там SMART значение какого-то там параметра не 0 - это не является дефектом.
> Это может быть как S-ATA1 (в таком случае покупка SSD выглядит неоправданной тратой денег)
Оправданной.
Да, в этом случае не нужен топовый диск. На десктопах всё-таки не такие жёсткие требования к случайному вводу-выводу, где даже современные топовые SSD едва преодолели отметку в 50мб/с (случайное чтение, глубина очереди 1).
IOPS же штука полезная только с указанием методики тестирования. И не имеет ровно никакого отношения к времени доступа. Можно и на одном SATA HDD намерить 300-400 IOPS из физически возможной сотни. https://habrahabr.ru/post/154235/
На указанные производителем цифры можно вообще не смотреть. Там всё равно будут пиковые цифры с идеальных условий, если вообще реальные, а не с потолка переписали.
Передача данных на стороннюю машину - зачем вообще делать синхронно? Кладёте сообщение в очередь. Демон, который очередь разгребает, на dev вообще не запускаете (кстати, очень простой и дубовый демон, который становится куда легче отлаживать, т.к. выполняет только 1 задачу). Можете подцепиться к очереди и посмотреть, всё ли правильно оформлено для отсылки на сторонний сервис. Не говоря о штатной работе, если удалённая машина недоступна - демон разгребёт очередь попозже.
И это же хороший пример конфигов, которые на dev-машине вовсе неуместны. По крайней мере во включенном состоянии. Даже в синхронном режиме работы запросы просто заворачиваете на эту же локальную машину с простой и глупой эмуляцией API и ведением логов для разбора, правильный ли запрос был отправлен.
Хотите закомментировать временно - зачем вообще в гит коммитить? И зачем хотите комментировать? Может, это должна быть директива конфига на самом деле, отключенная в dev-окружении?
Конфиги вы должны иметь возможность создавать разные. Реализовать можно разными путями - через переменные окружения сообщать, конфиги какого окружения подтаскивать; класть в гит глобальный дефолтный конфиг, а в прописать .gitignore локальный конфиг, который собой может заменять некоторые директивы из глобального и всякие другие способы. В частности, продовых конфигов в гите может не быть вовсе.
dev и prod на разных платформах - вообще порочная практика. Используйте vagrant с окружением, наиболее близким к проду. Ну кроме случая, когда вы пилите что-то коробочное, что должно работать на любых чайниках.
Ну ладно. Значит берёте исходник и раскуриваете его. https://github.com/zendframework/zf1/blob/master/l... ничего примечательного, что-то неверное генерируется для _execute. Метод public, так что берите стектрейс и читайте промежуточный код, где поведение идёт куда-то не туда.
> непонятно отличие переменной заданной через SET и переданной в процедуру с точки зрения возможности её изменения
Я видимо спутал с каким-то другим диалектом, думал, что IN параметру в принципе ничего другого присвоить уже нельзя. Оказывается, можно.
Но переменные - всё-таки другая штука. Во время выполнения запроса переменную изменить легко, а вот параметр - уже нет, с ходу вообще не получилось найти способа. У них даже разный синтаксис.
По поводу индекса по dt - чтобы получить данные по индексу, надо прочитать индекс, доставать из него указатели на данные (а в случае Innodb это значения первичного ключа), потом доставать данные. Это всё дофига случайного чтения.
Если относительно общего массива данных вам нужно получить небольшое число строк - то по индексу работать всё-таки гораздо быстрее.
А вот если по индексу выбирается много данных относительно общего массива - часто выгоднее от использования индекса отказаться и читать напрямую таблицу простым и последовательным чтением seq scan. Некоторые данные прочитаем напрасно, но последовательное чтение на пару порядков быстрее случайного.
Судя по названию таблиц, у вас большая часть данных будет как раз в куске индекса до указанной даты.
Возвращаясь к теме - да, всего на 50 тыс записей виснуть не должен.
Посмотрите как mysql переписывает запрос: после explain сделайте show warnings - будет примерный вид переписанного оптимизатором запроса. Может будет понятнее, что он решает делать странно.
