Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5 6 7   вперед  Ctrl      все
 Re: Выбор сервера, чтобы не тормозило ...  [new]
ЛП
Guest
2 с127
Продолжайте и дальше болтать языком в том же духе.

Товарисч с127, а Вы продолжайте и дальше не замечать уже трижды написанного - обещанных тормозов в Вашем любимом фаре не наблюдалось :))
Ни на "нескольких сотнях файлов" (с) с127, ни на нескольких тысячах не наблюдалось "жести" (с) mv, ни даже на десятках тысяч (с) DocAI.

Разумеется, откуда ж им взяться, ведь тест на выбор файлов так и не проведен.

Кажется Вы тоже молча замолчали вопрос "Какие Ваши цифры", но тем не менее с жизнерадостностью дибила продолжаете утверждать, что "будут тормоза, вах, абасраццо и не жить будут тормоза" :)
25 окт 06, 01:17    [3305306]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
ЛП
Guest
Кстати, с127, меня почему-то преследует мысль, что Вы просто врёте. Нагло и банально.

Посудите сами. Топику уже неделя. За это время можно было сто раз написать простейший тест, который бы показал, что (например) поиск в ста файлах - секунда, поиск в двухстах файлах - две секунды, поиск в трехстах файлах - три секунды, и т.д., и т.п. Ну типа чтобы проиллюстрировать Ваши же слова о том, что дескать тормоза заметны невооруженным глазом, и растут эти тормоза при поиске линейно.

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

Нет же, Вы почему-то предпочитаете юлить, подменять свои слова, говорить, что дескать "не прикидывайтесь дурачком, вы же прекрасно поняли, что когда я говорил видно невооруженным глазом, то я имел в виду ограничения системы, когда я имел в виду ограничения системы, то я говорил про открытие каталога, когда я говорил про открытие каталога, то читал про поиск, а поиск тормозит, потому что я наблюдал линейные тормоза при сортировке, которая видна невооруженным глазом".

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

------------------------------------

Чтоб не выглядеть аналогичным Вам звездоболом, решил таки свой винт изнасиловать. Правда у меня места совсем мало, 5 Гб всего свободно (было), поэтому я ограничился миллионом трехкилобайтовых файлов в одной директории.

Тестовые скрипты (запускать из какого-нибудь ворда/экселя/аксеса):

Private Const strRoot = "e:\test\"

Public Function Test()
    Dim lngMaxFiles As Long: lngMaxFiles = 1
    Dim lngCurrentFileNumber As Long: lngCurrentFileNumber = 1
    
    Dim tTotalStart As Single, tTotalEnd As Single
    Dim tStepStart As Single, tStepEnd As Single
    
    tTotalStart = Timer
    
    ' создаем кучу файлов
    Dim i As Long: i = 0 ' степени десятки (кол-во файлов)
    For i = 0 To 6
        Debug.Print "Step " & i + 1;
        tStepStart = Timer
        
        While lngCurrentFileNumber <= lngMaxFiles
            Dim strFileName As String
            strFileName = strRoot & Format(lngCurrentFileNumber, "0000000") & ".txt"
            Open strFileName For Output As #1 ' создаем файл
                Dim j As Long
                For j = 1 To 300 ' записываем в него 3Кб текста
                    Print #1, "0123456789";
                Next j
            Close #1
            lngCurrentFileNumber = lngCurrentFileNumber + 1
        Wend
        
        tStepEnd = Timer
        Debug.Print , "Files: ", , lngMaxFiles
        Debug.Print , "Create time (total, sec): ", tStepEnd - tStepStart
        ' проверяем время поиска
        Debug.Print , "Random seek (avg, sec):", TestSeek(lngMaxFiles)
        
        lngMaxFiles = lngMaxFiles * 10
    Next i
    
    tTotalEnd = Timer
    Debug.Print "========================="
    Debug.Print "Total time:", tTotalEnd - tTotalStart
    Debug.Print "========================="
    Debug.Print "c127 - пяздун"
End Function

Public Function TestSeek(lngMaxFiles As Long) As Single

    Dim tStart As Single, tEnd As Single, tTotal As Single
    
    Dim i As Long
    For i = 1 To 1000
        Dim strFileName As String
        ' рандомный файл
        strFileName = strRoot & Format(Int(Rnd(1) * lngMaxFiles) + 1, "0000000") & ".txt"
        
        tStart = Timer
        Open strFileName For Input As #2 ' Нашли и открыли
            Dim c As Byte
            c = Input(1, #2) ' на фсяк случай прочитали аж целый байт
        Close #2
        tEnd = Timer
        
        tTotal = tTotal + (tEnd - tStart)
    Next i
    
    TestSeek = tTotal / 1000
End Function

Результаты:
Step 1        Files:                       1 
              Create time (total, sec):    0 
              Random seek (avg, sec):      4,6875E-05 
Step 2        Files:                       10 
              Create time (total, sec):    1,660156E-02 
              Random seek (avg, sec):      4,6875E-05 
Step 3        Files:                       100 
              Create time (total, sec):    0,046875 
              Random seek (avg, sec):      7,8125E-05 
Step 4        Files:                       1000 
              Create time (total, sec):    0,421875 
              Random seek (avg, sec):      4,6875E-05 
Step 5        Files:                       10000 
              Create time (total, sec):    12,88965 
              Random seek (avg, sec):      0,0000625 
Step 6        Files:                       100000 
              Create time (total, sec):    133,6416 
              Random seek (avg, sec):      9,202149E-03 
Step 7        Files:                       1000000 
              Create time (total, sec):    1316,548 
              Random seek (avg, sec):      0,0381875 
=========================
Total time:    1511,251 
=========================
c127 - пяздун
25 окт 06, 05:15    [3305384]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
c127
Guest
ЛП
Посудите сами. Топику уже неделя. За это время можно было сто раз написать простейший тест, который бы показал, что (например) поиск в ста файлах - секунда, поиск в двухстах файлах - две секунды, поиск в трехстах файлах - три секунды, и т.д., и т.п. Ну типа чтобы проиллюстрировать Ваши же слова о том, что дескать тормоза заметны невооруженным глазом, и растут эти тормоза при поиске линейно.

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

Тормоза росли бы линейно в случае отсутствия индексации, я ошибочно считал что в НТФС файлы не индексируются, а какая-то индексация в НТФС есть. Я сам нашел ссылки и признал свою ошибку, нет смысла мне на нее каждый раз указывать, я о ней знаю.

Но не нужно врать, я нигде не говорил, что линейный рост времени поиска был зафиксирован в эксперименте при поиск или сортировке. Или процитируйте где я это говорил.

Невооруженным глазом видны тормоза при открывании больших директорий фаром и при поиске из фара и виндовз експлорера, я об этом тоже сказал в явном виде тут
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=351165&pg=2#3292545

Причем Вы отлично поняли о чем шла речь, но продолжаете прикидываться дурачком. Не надоело еще передергивать мои слова?

Хорошо, что через неделю обсуждения Вы таки решились провести тест, о котором я говорил с самого начала. Возможно в нашем тесте были какие-то неправильные файлы, как у DocAl и многих других, ссылки я приводил. У Вас файлы правильные - отличный от нашего результат. Но кто поручится, что автор ветки сложит в директорию только правильные файлы.

Важно что от этого ничего не меняется, советовать сложить 18 млн картинок в одну директорию может только нездоровый человек, я уже не говорю о миллионе записей служебной информации в день, от обсуждения которых Вы по очевидным причинам упорно уходите.
26 окт 06, 01:39    [3311729]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
ЛП
Guest
2 c127
Зачем, в нашей фирме этот тест провели еще в 2000-2001 году

Я Вам не верю. Либо Вы врёте, либо же Вам самому наврали, Вы поверили, и теперь уже других па-децки пытаетесь дезинформировать.
Типа "зуб даю, видел Лох-Несское чудовище в двухтысячном году... линейно растущее... ну не я видел... но с моей фирмы человек видел... ну не видел, а только нюхал... но зуб даю, 220%, говном пахло"

Циферки, с127, циферки в студию. Тем более что "файловая система не поменялась"

Выяснили, что тормоза растут быстро

Опа! Чуть раньше было "линейно". Куда-то Ваша точность высказываний делась :)

много файлов в такой задаче в одной директории хранить нельзя, я об этом сказал.

Ну да, Вы сказали.
Ку.
А DocAI показал, что можно. Я проверил - действительно можно.

Тормоза росли бы линейно в случае отсутствия индексации

Надо же, вчера был День Знаний, теперь день сомнений в собственных силах?
Когда это "бы" появилось в Ваших высказываниях? Раньше было всё гораздо более категорично. Все проверили, не работает, хранить нельзя, не то чтобы искать, не прикидывайтесь дурачком, теста не провели, не болтайте языком, продолжайте болтать языком, и прочие бездарные сопли. У ЧАЛа научились методике ведения споров? Убейте себя ап стену.

я ошибочно считал что в НТФС файлы не индексируются, а какая-то индексация в НТФС есть. Я сам нашел ссылки и признал свою ошибку, нет смысла мне на нее каждый раз указывать, я о ней знаю.

Тринадцатый удар часов ставит под сомнение предыдущие двенадцать.

Но не нужно врать, я нигде не говорил, что линейный рост времени поиска был зафиксирован в эксперименте при поиск или сортировке. Или процитируйте где я это говорил.

Ааа... Так Вы таки вообще экспериментов по замеру тормозов не проводили, даже на глаз, а про линейный рост тормозов при поиске просто так спизднули, для красного словца? (причем спизднули как минимум дважды?) Флаг в руки. Моя оценка Вам - в последней строчке представленных результатов проведенных тестов.

Невооруженным глазом видны тормоза при открывании больших директорий фаром и при поиске из фара и виндовз експлорера, я об этом тоже сказал в явном виде тут

Линейные тормоза? Как Вы упомянули тут, после этого поменяв "поиск" на "сортировку" (или наоборот, я запутался)? Впрочем, неважно, поиск это был или сортировка, ведь Вы уже чуть выше убедили меня в том, что эксперимента не было :)

Хорошо, что через неделю обсуждения Вы таки решились провести тест

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

Важно что от этого ничего не меняется

Само собой. Лжец остается лжецом, от каких-либо высказываний в форуме не меняется ровным счетом ничего.
26 окт 06, 02:26    [3311754]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
c127
Guest
ЛП
Циферки, с127, циферки в студию.

Никаких проблем, вот они:
файлов   время_поиска
10000    6.250000E-05      
100000   9.202149E-03    (6.25E-04 должно быть при линейном росте, замедление в 147 раз вместо 10)
1000000  3.818750E-02    (6.25E-03 должно быть при линейном росте, замедление в 608 раз вместо 100)
https://www.sql.ru/forum/actualthread.aspx?tid=351165&pg=4#3305384

Я ошибся, когда сказал, что результаты другие, виноват, невнимательно посмотрел. Похоже что резульаты ЛП подтверждают мое утверждение о тормозах.

На трех последних точках рост даже хуже чем линейный, что подтверждает, что индексирование если и есть, то очень кривое, как я и говорил тут
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=351165&pg=3#3299341
Поправьте если я не прав.

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

ЛП
Вы - простой лжец. Никогда никаких экспериментов на заданную тему не проводили, не наблюдали ни сами, ни на работе, и воспроизвести результаты не сумеете при всем желании.

Продолжайте в том же духе.
26 окт 06, 03:30    [3311780]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
c127
Guest
c127

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

В этой фразе речь идет об абсолютном времени поиска и только если индекс действительно присутствует и используется.
26 окт 06, 03:35    [3311782]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
ЛП
Guest
2 с127
с127, ну Вы понимаете, что я еще мышью куда-то кликал в ходе эксперимента? По интернету ползал, диск смотрел, почту читал... Если не понимаете, то просто поверьте

Если что-то из этих операций дало изменение среднего времени поиска на тысячные доли секунды, при небольшом в общем-то количесте тестовых поисков - ну типа я не удивлюсь :)

Плюс к этому обратите внимание на то, что это уже было совсем под завязку диска. Там ужо фрагментация сказываться должна, файлы под конец теста писались в "остатки", с соответствующим влиянием на поиск :)

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

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

Хосспадя, да не вопрос. Скрипты все выложены, путем небольших модификаций можете повторить тест для случайной последовательности имён файлов. Типо Ваша очередь. Будет интересно посмотреть, тем более что я с ходу не сильно понимаю - почему при рандомном поиске результат должен быть хуже в случае случайных имен. На времени создания файлов еще как-то может сказаться, на времени поиска - чет не верится.
26 окт 06, 03:52    [3311788]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
ЛП
Guest
Кстате, с127, а почему вы не обратили внимание на нулевой (и даже на одном из шагов отрицательный) прирост времени поиска на тех самых пресловутых сотнях файлов (вплоть до тысячи)?
Типо обладаете умением замечать только то, что Вам выгодно замечать?
26 окт 06, 04:18    [3311796]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
ЛП
Guest
Ну и на всяк случай еще
Создал 10000 файлов, после чего 50 раз запустил свой TestSeek(10^4)
Получил колебания среднего времени поиска от 9.18Е-05 до 1.0Е-02
Создал 100000 файлов, после чего 50 раз запустил TestSeek(10^4)
Получил колебания среднего времени поиска от 4,313Е-03 до 7.34Е-03

с127, о каких таких "замедлениях в 608 раз" Вы говорите, когда на одном и том же наборе файлов один и тоже же рандомный поиск по среднему времени колеблется вплоть до стократных расхождений?

миллисекунды - это в пределах погрешности измерений. аська запустилась - поиск замедлился, system idle занял 100% проца - поиск убыстрился, MFT закешировалось - совсем быстро стало.

я уж молчу про "на глаз заметно".
26 окт 06, 04:53    [3311801]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
ЛП
Guest
Создал 100000 файлов, после чего 50 раз запустил TestSeek(10^4)

Пардон, неудачно опечатался, во втором случае 10^5
26 окт 06, 04:55    [3311804]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
hvlad
Member

Откуда:
Сообщений: 11640
ЛП
я ограничился миллионом трехкилобайтовых файлов
Каждый из которых целиком ложится в один кластер ntfs. Сдаётся мне - они будут целиком лежать в mft. Не показательный тест
26 окт 06, 11:01    [3312823]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
ы
Guest
hvlad
ЛП
я ограничился миллионом трехкилобайтовых файлов
Каждый из которых целиком ложится в один кластер ntfs. Сдаётся мне - они будут целиком лежать в mft. Не показательный тест

Во-первых,
Ultrin
картинки эдак так под 50000 (каждая размером под 15 киолбайт)

15 кб тоже ложится в один стандартный кластер ntfs. Показательный тест.
Во-вторых, что важнее :), размер размер файла не влияет на скорость его поиска никак.
26 окт 06, 12:28    [3313655]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
ы
Guest
да, вышеприведенный тест запускался при включенном индексировании, кстати?
26 окт 06, 12:38    [3313748]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
hvlad
Member

Откуда:
Сообщений: 11640
ы
15 кб тоже ложится в один стандартный кластер ntfs. Показательный тест.
Во-вторых, что важнее :), размер размер файла не влияет на скорость его поиска никак.
а) стандартный кластер (тот, который по-умолчанию для раздела указанного размера), таки 4К
б) кому нужно просто искать файлы, тот один раз распечатывает вывод команды dir :) файлы обычно читают, после того как находят, так что р-р файла будет иметь значение
в) посмотрите как сама MS работает с большим кол-вом файлов - на примере файлового устройства кеша IE
26 окт 06, 14:21    [3314817]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
ы
Guest
hvlad

a) таки да. Беру свои слова обратно
б) в данном случае речь идет о скорости поиска. Для того чтобы найти файл по имени, не нужно читать содержимое ни его самого, ни его соседей
в) а что я должын там увидеть?
26 окт 06, 14:40    [3314982]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
hvlad
Member

Откуда:
Сообщений: 11640
ы
б) в данном случае речь идет о скорости поиска. Для того чтобы найти файл по имени, не нужно читать содержимое ни его самого, ни его соседей
в) а что я должын там увидеть?
б) в реальной прикладной задаче речь шла о хранении картинок в блобах\файлах. просто искать эти картинки без их чтения бессмысленно в данном контексте :)
в) уж никак не один каталог с тысячами файлов - это о чём-то говорит, не так ли ?
26 окт 06, 16:51    [3316164]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
ЛП
Guest
2 hvlad
ЛП
я ограничился миллионом трехкилобайтовых файлов
Каждый из которых целиком ложится в один кластер ntfs.

Ну да, ложаться в кластер. Проводился бы эксперимент более близкий к реальным условиям (т.е. 180 млн 15-тикилобайтных файлов) - я бы порекомендовал кластер до 16Кб увеличить, дабы оно опять таки в кластер влезло. Оно не критично, но поприятнее жить будет.

Сдаётся мне - они будут целиком лежать в mft.

Я по-моему уже говорил, что целиком в MFT ложаться файлы с характерным размером в сотню байт (и меньше). Т.е. в тесте DocAI они таки в MFT лежали, в моём - нет.

в) уж никак не один каталог с тысячами файлов

Еще раз - откройте каталог Windows\system32
Увидьте там тысячи файлов.
Прекратите пугать людей сотнями и тысячами файлов :). Не те это цифры.

это о чём-то говорит, не так ли ?

О чем? Может о том, что поиск по небольшой директории выполняется быстрее, чем поиск по большой? Но с этим никто и не спорит.

2 ы
да, вышеприведенный тест запускался при включенном индексировании, кстати?

Хрен его знает :)
Я по примеру DocAI играл в северного варвара, ничего нигде не настраивал и не менял. Вряд ли индексация содержимого файлов была включена, но зуб не дам. Вечером смогу сказать.
26 окт 06, 17:26    [3316513]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
ы
Guest
hvlad
б) в реальной прикладной задаче речь шла о хранении картинок в блобах\файлах. просто искать эти картинки без их чтения бессмысленно в данном контексте :)
в) уж никак не один каталог с тысячами файлов - это о чём-то говорит, не так ли ?

б) может мы о разных вещах говорим? Я прочитал вопрос так: "программа ... должна быстро получить по индексу (имени) <одну> картинку". Для поиска одной картинки по имени не важен ни ее размер, ни размер других картинок, лежащих рядом с ней в каталоге (или в базе). Причем это равно справедливо и для fat, и для ntfs. Правда, со второй системой я знаком поверхностно :( (надо исправиться), но список файлов в папке, насколько я помню, там хранится почти так же, как и в первой.

в) кстати, в опере кэш живет в одной папке. Это о чем-то говорит? За неделю жизни свежеустановленной системы у меня там накопилось 13'000 файлов. Опера как работала, так и работает. И будет работать еще с полгода, до следующей переустановки виндовса.

Не нужно ссылаться на корявую работу с миллионом файлов в одной папке программ, которые для такой работы не предназначены. Это не вам, это про far и Co. Еще бы пузырьком список файлов сортировать начали (с) не мой :)
26 окт 06, 17:59    [3316793]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
c127
Guest
ЛП

с127, ну Вы понимаете, что я еще мышью куда-то кликал в ходе эксперимента? По интернету ползал, диск смотрел, почту читал... Если не понимаете, то просто поверьте

Если что-то из этих операций дало изменение среднего времени поиска на тысячные доли секунды, при небольшом в общем-то количесте тестовых поисков - ну типа я не удивлюсь :)

Непонятно зачем публиковать данные эксперимента, а потом на следующий день самому же на протяжении трех постов доказывать что он некорректен. Уже молчали бы и не позорились.

Не пубилкуйте таких результатов, или думайте до публикации результатов, а не после, не нужно будет выкручиваться, рассказывя о чтении почты. Если Вы проведете аналогичный эксперимент с поиском на РСУБД при нормальной индексации, то скорее всего увидите, что никакого 600 кратного замедления при переходе от 10000 к 1000000 записей не наблюдается, даже если в это время немного покликать мышкой. При B-tree индексе замедление должно быть где-то в районе 2, но зависит от индекса. Даже если индекса нет то будет примерно 100 кратное замедление, а у Вас 600. Быстро кликали мышкой наверное.

Но с другой стороны замедление больше чем на два порядка это конечно же не тормоза, обещанных мной тормозов добиться не удалось. Подумаешь, на 20 день система работает всего в 600 раз медленнее чем в первый и это не проблема, все нормально.

ЛП

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

Обратил. Но потом прочитал Вашу фразу:
ЛП> миллисекунды - это в пределах погрешности измерений.
https://www.sql.ru/forum/actualthread.aspx?tid=351165&pg=4#3311801
и решил что обсуждать величины, которые по словам самого автора эксперимента с большим запасом в пределах погрешности измерений, бессмысленно.

О видимом на глаз приросте времени поиска на сотнях файлов начали говорить Вы, я такого не говорил. Ну если очень хотите, то считайте что я тоже в это время еще и "По интернету ползал, диск смотрел, почту читал..." ((С) ЛП).

А вот как это выглядит на графике, горизонтальная ось в логарифмическом масштабе по основанию 10. B-tree индекс, который якобы используется в NTFS, дает логарифмическое время поиска, поэтому график должен был бы быть близким к прямой. Но что вышло то вышло.

К сообщению приложен файл. Размер - 0Kb
27 окт 06, 01:58    [3317987]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
ЛП
Guest
2 c127
Непонятно зачем публиковать данные эксперимента, а потом на следующий день самому же на протяжении трех постов доказывать что он некорректен.


Следующий день - это сегодня, с127. Если у Вас проблемы с восприятием времени, то сходите к доктору :)

Теперь к данным эксперимента.
Почему ж он некорректен, простите? Вполне корректен. Все ж зависит от того, что пытались выяснить в ходе эксперимента :)
Я сопстна пытался выяснить - правда ли, что миллион файлов нельзя хранить в одной директории (как утверждали Вы), правда ли, что ограничения системы наступают уже на сотнях файлов (как утверждали Вы), правда ли, что при поиске будет большой тормоз (как утверждали Вы), правда ли, что тормоза будут заметны на глаз (как утверждали опять-таки Вы)
Выяснил. Все, что утверждали Вы - неправда. Миллион файлов хранить можно, на сотнях файлов ограничений нет, на глаз тормоза не заменты, большого тормоза нет ни на сотнях файлов, ни на миллионе.
Ну и так как выяснилось, что все, что утверждали Вы, является неправдой, то Вы - лжец. Эксперимент более чем корректен.

Характер зависимости времени поиска от кол-ва файлов я не особо старался определить, и с этой точки зрения готов признать, что эксперимент совсем не корректен. Но уж тем более я не предполагал, что по шести точкам с погрешностью плюс-минус десять тысяч процентов кто-то попробует графики рисовать :). Если бы старался или предполагал, то провел бы немножно другой эксперимент, по-крайней мере с бОльшим количеством точек, и соответственно меньшим шагом.

Кстате, вот результаты (время поиска, кол-во файлов):
4,69E-05	1
4,79E-05	2
6,15E-05	4
6,35E-05	8
2,93E-05	16
4,88E-05	32
6,15E-05	64
4,69E-05	128
4,69E-05	256
6,15E-05	512
4,69E-05	1024
7,81E-05	2048
6,35E-05	4096
6,15E-05	8192
6,35E-05	16384
1,25E-04	32768
7,91E-05	65536
7,81E-05	131072
0,0000625	262144
5,09E-03	524288
1,16E-02	1048576
Тест практически такой же, только открытие файла и чтение из него одного байта я убрал, оставив сопстна его поиск. Т.е. в процедуре TestSeek теперь такой кусок кода:
        tStart = Timer
            Dir strFileName
        tEnd = Timer
Ну и основная тестовая процедура по степеням двойки идет, а не по степеням десятки.

Вам так нравится рисовать графики по чужим данным? Сделайте одолжение, нарисуйте еще один :)
Проблема сразу очень хорошо обрисовывается, что в общем-то и не удивительно. Как с этой проблемой побороться я уже говорил - перенастроить MFT на большее кол-во файлов. Ну и мышкой не кликать, разумеется :).
Полчаса не кликать мышкой я могу, но вот переформатировать винт, уж извините, я не буду.

О видимом на глаз приросте времени поиска на сотнях файлов ачали говорить Вы, я такого не говорил.

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

ЛП

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

Обратил. Но потом прочитал Вашу фразу:

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

Если сначала опубликовали, потом обратили, потом прочитали, то значит не обратили внимание раньше (до того, как опубликовали). И, стало быть, таки обладаете умением замечать лишь то, что Вам хочеццо замечать.

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

Как не крути, а в итоге Вы по уши в говне :).
27 окт 06, 04:15    [3318048]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
ChA
Member

Откуда: Москва
Сообщений: 11405
c127
Да признайте Вы, что ЛП в данном вопросе прав, и дайте этому топику благополучно "утонуть". Все ошибаются, заблуждаются или что-то меняется в мире, ну какой Вам смысл так упорствовать, не медаль же, в конце концов, зарабатываете. Ну что Вы, право, как мазохист какой...

P.S. Впрочем, дело, разумеется, Ваше, это было всего лишь мнение стороннего наблюдателя.
27 окт 06, 06:07    [3318083]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
ЛП
Guest
дык ведь и я про то же

впрочем, уже пишу новые данные для красявыхх графикофф с127 :)
27 окт 06, 06:12    [3318089]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
DocAl
Member

Откуда: Оккупирую западный берег
Сообщений: 10472
Если несложно, график опубликуйте в .gif или .png, jpeg для этого не очень подходит.( Заранее спасибо.)
27 окт 06, 10:30    [3318718]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
-
Guest
Приходится признать, что в споре c127 и ЛП победил с127.
См. график

К сообщению приложен файл. Размер - 0Kb
27 окт 06, 16:08    [3322073]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
ЛП
Guest
Приходится признать, что в споре c127 и ЛП победил с127.

Да что Вы говорите

См. график

На Вашем графике аж целый кусок логарифма из трех точек, соответственно на логарифмической шкале аж целый кусок прямой опять-таки из трех точек :)

Могу выложить результат того же самого, но с 1000 замеров.

К сообщению приложен файл. Размер - 0Kb
27 окт 06, 16:27    [3322254]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5 6 7   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить