Alexander писал(а):Выходит вы не прочитали топик полностью? Я написал что собираюсь делать и когда, не претендавал на скриптовую серверную часть никогда.
Прочитать-то прочитал, но явные минусы сразу лезут в глаза (и не мне одному - тут ранее намекали на некоторую "избыточность" варианта с сокетами, например). За кои минусы тут и обсуждаем.
Впрочем, нравится - делайте, это ж я еще вчера сказал. Хоть какая-то подвижка на этом направлении все же лучше, чем вообще никакой...
Alexander писал(а):я собираюсь написать серверную часть к своей программе, на сокетах. Меня интересует скорость для 1-3 соединений, а не ультрамногопользовательность.
Многопользовательскость в своем принципе не может быть "ультра". Это как беременность: нельзя быть "немножко беременным". Либо решение позволяет параллельную работу себя любимого на много фронтов, либо работает сугубо в сингл-мод и никак иначе. Число параллельных потоков и лимитейшны оборудования и сервера - это уже техническая подробность (понятно, что чем больше одновременно подключенных клиентов - тем больше проблем, но это уже совершенно другой вопрос, мало относящийся к собственно идее приложения).
Alexander писал(а):Общая скорость (Загрузка в память + хэширование) выходит всего в 3 раза больше на моей машине, так файл 75Мб всего за 1,5 секунды хэшируется (при второй попытке всего за 715 мс). Если бы вы добавили хоть маломальское кэширование (если такое возможно на скриптах) то времени бы затратилось куда меньше чем 2 минуты.
В моем примере
специально был отход от кэширования, чтобы мерять не сферического коня в вакууме - но реальную, приближенную к текущей ситуацию на конфигурации, приближенной к серверной. Я даже специально предварительно сбросил системный кэш, чтобы он не влиял на чистоту эксперимента - если бы мне был нужен "сферический конь", то я бы прохэшировал ту или иную часть RАМа или поток определенной длины из /dev/rnd. И в любом случае скорость MD5 была бы В РАЗЫ медленнее CRC - о чем и разговор.
Я еще раз повторяю, что
никто на стороне среднестатистического хостера не будет постоянно держать Вашу глобальную базу в памяти, всегда предоставляя Вам исключительно хорошо прокэшированные данные. Опять же, при размере базы >512Мб прокэшировать ее так или иначе становится затруднительным по техническим соображениям, более того - тайлы теоретически могут класться\браться с любого отдельно взятого места базы рандомно, а не по порядку. В итоге при большой базе (либо маленькой памяти) получаем постоянное пережевывание оной еще и механизмом кэширования на фоне до упора занятой памяти + нагрузку самого решения и всей серверной обвязки + необходимость хоть какой-то работы и соседних задач и процессов.
Впрочем, создайте более-менее большой контейнер ТруКрипта (одним файлом например, 4Гб - это будет аналог совсем небольшой "базы", которая может быть создана юзерами даже за сутки), и попробуйте а)прокэшировать его весь в память б)активно поработать в multi-user конфиге, одновременно выполняя какие-то второстепенные действия на той же машине (либо желаем dedicated server?), причем работа должна вестись через сокеты прогой, написанной на дельфях (сомневаюсь, что оный дельфи чем-то особым выделяется при разработке server-side вообще, и при работе с сетью в частности - это изначально "виндузявый недоПаскаль для начинающих" без какой-то особой ориентации и оптимизации в сторону сетевых решений). Посмотрите за общую производительность такой конфигурации в течении более-менее долгого времени. Удачи.
PS: предлагаю прекратить этот спор ни о чем. Нравится Ваш вариант - делайте, кто ж против-то, сорцы есть в паблике. От любых опытов MD5 само по себе не станет быстрее, прекомпиленная серверная часть не станет гибче (особенно с закр.кодом), а прекэшируемая база рано или поздно перестанет влазить в локальный RAM, насколько бы этот RAM ни был бы велик. Смею предположить, что в скором времени этот вариант окажется очередным тупиковым, ибо каждый раз изобретать новый велосипед решения общеизвестных граблей - несколько затруднительно и накладно по времени. Минусы же предложения очевидны (и должны будут быть так или иначе решены\обойдены) - а откровенных плюсов своего решения по сравнению с
уже существующим Вы пока еще так и не обозначили.
Если же просто хочется тематических экспериментов - то удачи.
Обоснования повышенной ресурсоемкости решения - где? На это никто почему-то до сих пор не ответил. Просто потому что "программеру так захотелося"? Так его право, конечно, хай делает (как я и сказал ранее) - но лично я например такое решение качать, разворачивать и использовать не вижу практического смысла - с гугла и так всё качается безо всяких MD5, баз и вот прямо щас.