Та запросто и 60мб/с может быть. Смотря на сколько капитально вы упираетесь в CPU и на сколько аналогичный тест под виндами скатывается к random write вместо seq write.
Для виндов это нативная фс, где-то в тех недрах и сделанная десятилетия 2 назад, если не больше. Она там до сих пор единственная, кстати? К этому артефакту спеки-то хоть опубликовали или всё так же реверсинжинирингом разбирать приходится?
В linux запись в NTFS работает через FUSE, т.е. обрабатывается в пространстве пользователя, а не ядра. Это довольно много жрёт CPU.
Смотреть php://input чтобы понять, что эти гении прислали в этот раз. Если там реально нормальный XML - то скормитьэту строку simplexml или другому вашему любимому парсеру XML.
Смотреть на мониторинг. Графики загруженности сети и дисков. Для сети учитывать, что 100% утилизация невозможна, 900мбит/с уже неплохая пропускная способность, дешёвые сетевые карты могут такое и не переваривать. Можно замерить iperf'ом, сколько ваше сетевое оборудование реально может передать между двумя точками. Для дисков смотреть показатель утилизации, плюс график латентности обработки запросов. Бутылочное горлышко может быть как в сети, так и в диске.
ммм, где я такое говорил?
Если сущность - датавремя около настоящего момента - то timestamp подходящий выбор.
А, это где я про сравнения писал? Физически timestamp в mysql занимает 4 байта, как int32 и хранится, поэтому и сравнение двух интов будет.
Александр Алексеев: если не заметно, я про конкретную статью. Там кстати в комментариях сказано, как можно попробовать на одной видеокарте, но без подтверждённого результата эксперимента. Поэтому оставил примечание из статьи.
Можно глянуть тесты зависимости производительности вашего ПО с памятью разной частоты. Для многих задач - никакой разницы от частоты памяти. Соответственно, любая память.
romy4: в зависимости от СУБД и её версии. Это не коррелирующий запрос, отдельный запрос для каждой строки не требуется. Нормальная СУБД и даже современный mysql дадут нормальный план. На postgresql лично видел план для in subquery лучше, чем для эквивалентного join.
Не думаю, что работал в sqlite. Исполнялся и возвращал какой-то случайный результат - да. Может даже иногда похожий на правду. Осмысленный результат - нет. Например, любую дату, вместо последней. Иначе бы postgresql со своим нативным запретом на доступ к неаггрегированным данным при наличии группировки согласился бы с вашим запросом.
Перед использованием внешних данных вы обязаны проверить, что эти данные вам вообще прислали.