SASGIS

Веб-картография и навигация

HTTP-сервер-обменник для тайлового кеша

программа для загрузки и просмотра спутниковых снимков Земли, Луны, Марса предоставленных сервисами Google Maps и Космоснимки. Возможность работы с GPS приёмником.

Модератор: Tolik

Re: HTTP-сервер-обменник для тайлового кеша

Сообщение Alexander » 19 дек 2008, 16:41

svp писал(а):А как быть, если кто-то залил на сервер сначала новую версию тайлов, а потом кто-то другой залил на то же место старую? Получится же пятно с неадекватными датами тайлов. Откуда серверу знать, когда реально были загружены тайлы?


На стороне сервера никак никогда не отследить (если нет закономерности в каких то свойствах картики (но если необходимо анализировать изображение сервер будет сильно загружен)). Это можно решить на стороне клиента, но в любом варианте криворукие или недоброжелательные пользователи смогут испортить это, чтобы вы не придумали.
Alexander
Соображающий
 
Сообщения: 78
Зарегистрирован: 14 июл 2008, 09:09
Благодарил (а): 0 раз.
Поблагодарили: 0 раз.

Re: HTTP-сервер-обменник для тайлового кеша

Сообщение Parasite » 19 дек 2008, 17:23

svp писал(а):С учётом всех требований сервер без беркли сделать не удастся.

Почему?
The only difference between me and a mad man is that I am not mad. /Salvador Dali/
Изображение
Аватара пользователя
Parasite
Администратор
 
Сообщения: 5646
Зарегистрирован: 23 окт 2008, 17:38
Благодарил (а): 124 раз.
Поблагодарили: 512 раз.

Re: HTTP-сервер-обменник для тайлового кеша

Сообщение Parasite » 19 дек 2008, 17:27

Alexander писал(а):Всё-таки легче добавить хэш-сумму и знать размер тайлов.

А размер зачем? Если он изменится - изменится и хэш.
The only difference between me and a mad man is that I am not mad. /Salvador Dali/
Изображение
Аватара пользователя
Parasite
Администратор
 
Сообщения: 5646
Зарегистрирован: 23 окт 2008, 17:38
Благодарил (а): 124 раз.
Поблагодарили: 512 раз.

Re: HTTP-сервер-обменник для тайлового кеша

Сообщение Parasite » 19 дек 2008, 17:34

Alexander писал(а):Два инта сравнить быстрее чем 16байт, например по этому.

При среднестатистической скорости скачки тайлов - это абсолютно некритично.

Alexander писал(а):Если в системе дата неправильная то пользователь сам виновать, также как если у него часовой пояс неправильно прописан ))

То есть для корректной работы с данным приложением я (именно я, а не машина) должен буду безусловно держать в уме необходимость синхронизированного времени? Что за чушь! Да я лучше с гугля тогда склею - БЕЗ дополнительной нагрузки на моск...:)
The only difference between me and a mad man is that I am not mad. /Salvador Dali/
Изображение
Аватара пользователя
Parasite
Администратор
 
Сообщения: 5646
Зарегистрирован: 23 окт 2008, 17:38
Благодарил (а): 124 раз.
Поблагодарили: 512 раз.

Re: HTTP-сервер-обменник для тайлового кеша

Сообщение Parasite » 19 дек 2008, 17:36

svp писал(а):А как быть, если кто-то залил на сервер сначала новую версию тайлов, а потом кто-то другой залил на то же место старую? Получится же пятно с неадекватными датами тайлов. Откуда серверу знать, когда реально были загружены тайлы?

Передать УРЛ на сервер, откуда по факту был скачан тайл (там кроме всего прочего будет и гуглеверсия).
The only difference between me and a mad man is that I am not mad. /Salvador Dali/
Изображение
Аватара пользователя
Parasite
Администратор
 
Сообщения: 5646
Зарегистрирован: 23 окт 2008, 17:38
Благодарил (а): 124 раз.
Поблагодарили: 512 раз.

Re: HTTP-сервер-обменник для тайлового кеша

Сообщение Parasite » 19 дек 2008, 17:39

Alexander писал(а):чем длинее хэш, тем меньше коллизий (на MD5 например вполне сканает).

Это крайне медленный и крайне ресурсоемкий алгоритм. Нагрузку на сервер во многопользовательском режиме представляем, да?
The only difference between me and a mad man is that I am not mad. /Salvador Dali/
Изображение
Аватара пользователя
Parasite
Администратор
 
Сообщения: 5646
Зарегистрирован: 23 окт 2008, 17:38
Благодарил (а): 124 раз.
Поблагодарили: 512 раз.

Re: HTTP-сервер-обменник для тайлового кеша

Сообщение Alexander » 19 дек 2008, 20:06

Parasite писал(а):
Alexander писал(а):Два инта сравнить быстрее чем 16байт, например по этому.

При среднестатистической скорости скачки тайлов - это абсолютно некритично.

Alexander писал(а):Если в системе дата неправильная то пользователь сам виновать, также как если у него часовой пояс неправильно прописан ))

То есть для корректной работы с данным приложением я (именно я, а не машина) должен буду безусловно держать в уме необходимость синхронизированного времени? Что за чушь! Да я лучше с гугля тогда склею - БЕЗ дополнительной нагрузки на моск...:)


Моск тут не при чём, просто если у пользователя дата на месяц назад отмотана, то он просто увидит не самые свежие тайлы, если у него примерно правильное время +- час, то всё будет отлично.

Parasite писал(а):Передать УРЛ на сервер, откуда по факту был скачан тайл (там кроме всего прочего будет и гуглеверсия).


Ага, если версия у всех стоит 99, то что в этом дельного?

Parasite писал(а):
Alexander писал(а):чем длинее хэш, тем меньше коллизий (на MD5 например вполне сканает).

Это крайне медленный и крайне ресурсоемкий алгоритм. Нагрузку на сервер во многопользовательском режиме представляем, да?


Вполне представляю, а какой у Вас предполагается канал? Может 100Гбит/с, или 1Тбит/с? Тогда наверное не хватит сервера. Если полагать что канал порядка 1Гбит/с то вполне хватит, правда будет нагружен прилично, но это уже проблема хостера. Если домашний комп под сервак, то скорости порядка 100Мбит/с. И его тоже хватит.
Я же предложил наименее подверженный коллизиям алгоритм хэширования для своего очень малого размера (16байт). Можно броситься в крайность и использовать CRC первых 512 байт, на ваше усмотрение.

Parasite писал(а):
Alexander писал(а):Всё-таки легче добавить хэш-сумму и знать размер тайлов.

А размер зачем? Если он изменится - изменится и хэш.


Вы так уверены? Ваша фраза неверна, скажу точнее существует достаточно большое множество картинок разного объёма с одинаковым хэшем. Вероятность подобной коллизии для тайла гугла по определённому месту стремится к 0, но это не оправдание сказанному. =)
Alexander
Соображающий
 
Сообщения: 78
Зарегистрирован: 14 июл 2008, 09:09
Благодарил (а): 0 раз.
Поблагодарили: 0 раз.

Re: HTTP-сервер-обменник для тайлового кеша

Сообщение Parasite » 21 дек 2008, 20:11

Alexander писал(а):Моск тут не при чём, просто если у пользователя дата на месяц назад отмотана, то он просто увидит не самые свежие тайлы, если у него примерно правильное время +- час, то всё будет отлично.

У меня в частности (и в масштабах страны - вообще) сейчас 2551 год. На всех компьютерах (в масштабах страны!) в том числе. Что увижу _я_ при заходе в базу? Правильно, устаревшие на ~500 лет тайлы. Бугога. :(

Alexander писал(а):Ага, если версия у всех стоит 99, то что в этом дельного?

А кто сказал, что "версия у всех стоит 99" - это правильно? На гугле стоит НЕ 99я версия, и этим все сказано.

Alexander писал(а):Вполне представляю, а какой у Вас предполагается канал? Может 100Гбит/с, или 1Тбит/с?

Просьба не обсуждать в ветках меня - но сабж. Спасибо.
Десяток параллельных клиентов с приличным каналом вполне поставят на колени это решение. Про сотню уж и подавно молчу.
PS: у меня - оптика до кластера.

Alexander писал(а):правда будет нагружен прилично, но это уже проблема хостера.

На самом деле, это проблема _решения_. Любой вменяемый хостер пошлет в дупу неоптимизированный проект на скриптах, систематически кладущий ему сервер в DDOS. И будет прав.

Alexander писал(а):Если домашний комп под сервак, то скорости порядка 100Мбит/с. И его тоже хватит.

MD5 от 10Кб блока данных будет высчитываться около секунды, если я его правильно помню. Если подключились сто клиентов и все активно клеят карты (читай - активно запрашивают рандомные тайлы с базы), то - ......

Alexander писал(а):Я же предложил наименее подверженный коллизиям алгоритм хэширования для своего очень малого размера (16байт). Можно броситься в крайность и использовать CRC первых 512 байт, на ваше усмотрение.

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

Alexander писал(а):Вы так уверены? Ваша фраза неверна, скажу точнее существует достаточно большое множество картинок разного объёма с одинаковым хэшем.

Вероятность одинакового МД5 хэша при разных входных данных (помноженную на вероятность не именно ЭТОГО хэша вообще в базе, а именно этого хэша на именно этот "столбец тайлов по версиям" - сами просчитаете? Мне, если честно - лень. :)
The only difference between me and a mad man is that I am not mad. /Salvador Dali/
Изображение
Аватара пользователя
Parasite
Администратор
 
Сообщения: 5646
Зарегистрирован: 23 окт 2008, 17:38
Благодарил (а): 124 раз.
Поблагодарили: 512 раз.

Re: HTTP-сервер-обменник для тайлового кеша

Сообщение Alexander » 22 дек 2008, 14:52

Parasite писал(а):MD5 от 10Кб блока данных будет высчитываться около секунды, если я его правильно помню. Если подключились сто клиентов и все активно клеят карты (читай - активно запрашивают рандомные тайлы с базы), то - ......


У меня в программе сейчас вычисляется полный MD5 тайла перед тем как тот добавляется в кэш, скорость скачивания от 100Кб/с до 150Кб/с, операционка(Vista) с моей программой создаёт нагрузку на процессор в среднем 2% (среднее по диаграмме), сама программа менее 1%. Если посмотреть на алгоритм MD5 хэширования, то станет понятно что для хэширования нужно произвеси порядка 560 примитивных операций (которые занимаю <= 4 тактов процессора) на каждые 64байта, пусть будет 36 тактов на 1 байт, тогда более 50 Мбайт/с может хэшировать средний проц для ПК (При 100% загрузке). А MD5 10Кб/с может любой калькулятор сейчас =)
Как это делается на скриптах я не знаю, может и не так эффективно.

Parasite писал(а):Просьба не обсуждать в ветках меня - но сабж. Спасибо.


Хорошо. )

Parasite писал(а):У меня в частности (и в масштабах страны - вообще) сейчас 2551 год.


Увидите последние тайлы.

Parasite писал(а):Те первые байты, в которых большей частью стандартный и неизменный жпег-заголовок? Нет, спасибо, не подходит.


Мне кажется заголовок меньше.

Parasite писал(а):Вероятность одинакового МД5 хэша при разных входных данных (помноженную на вероятность не именно ЭТОГО хэша вообще в базе, а именно этого хэша на именно этот "столбец тайлов по версиям" - сами просчитаете? Мне, если честно - лень.


Вы же отказались от MD5, дак зачем такая статистика теперь.

Parasite писал(а):Десяток параллельных клиентов с приличным каналом вполне поставят на колени это решение. Про сотню уж и подавно молчу.


И все они одновременно будут закачивать тайлы на сервер? Здорово конечно, но когда такой найти можно будет )

П.С. зачем так привязываться к алгоритму кэширования, есть более интересные проблемы при реализации.
Alexander
Соображающий
 
Сообщения: 78
Зарегистрирован: 14 июл 2008, 09:09
Благодарил (а): 0 раз.
Поблагодарили: 0 раз.

Re: HTTP-сервер-обменник для тайлового кеша

Сообщение Parasite » 22 дек 2008, 15:27

Alexander писал(а):для хэширования нужно произвеси порядка 560 примитивных операций (которые занимаю <= 4 тактов процессора) на каждые 64байта, пусть будет 36 тактов на 1 байт, тогда более 50 Мбайт/с может хэшировать средний проц для ПК (При 100% загрузке). А MD5 10Кб/с может любой калькулятор сейчас =)

Я не говорил что не может. Я говорил, что медленно (по сравнению почти со всеми другими).

PS: цикл с вычислением MD5 от 32х байт на Перле занимал ~150 пересчетов/сек на Пне4 2.4ГГц (стандартным {Digest::MD5} без специального распараллеливания на физ.процессоры\ядра). Это собственно "в уме" - без каких-то дисковых операций, баз и прочих вводов-выводов - и от исходных 32х байт, в которых изменялись только младшие разряды сообразно с циклом.
При организации веб-сервера выбор будет крайне "богат": либо ПХП (там эта операция еще немного медленнее), либо Перл, либо (для мазохистов) - ASP.

PPS: так чем же плох "стандартный" и быстрый CRC? Мало разрядов? Тогда CRC32...?

Alexander писал(а):
Parasite писал(а):У меня в частности (и в масштабах страны - вообще) сейчас 2551 год.

Увидите последние тайлы.

...зато мои - никто не увидит еще как минимум 5 веков. :)

Alexander писал(а):
Parasite писал(а):Те первые байты, в которых большей частью стандартный и неизменный жпег-заголовок? Нет, спасибо, не подходит.

Мне кажется заголовок меньше.

Мне кажется я сказал "большей частью" (куска файла от начала и до указанной длины).

Alexander писал(а):
Parasite писал(а):Десяток параллельных клиентов с приличным каналом вполне поставят на колени это решение. Про сотню уж и подавно молчу.

И все они одновременно будут закачивать тайлы на сервер? Здорово конечно, но когда такой найти можно будет )

Что-то мне подсказывает, что при выпуске новой версии САСа ее скачают и начнут пробовать намного больше 100 человек (практически одновременно). И даже намного больше нескольких тысяч и десятков тысяч. Напоровшись же на 503 Service unavailable - скажут "Ффу, какая лажа!" и откатятся на предыдущую версию (в лучшем случае).

Alexander писал(а):П.С. зачем так привязываться к алгоритму кэширования, есть более интересные проблемы при реализации.

Есть вопрос требующий обсуждения, у кого-то есть что-то сказать == обсуждаем. Предлагайте другие вопросы - обсудим и их, народ подтянется. :)
The only difference between me and a mad man is that I am not mad. /Salvador Dali/
Изображение
Аватара пользователя
Parasite
Администратор
 
Сообщения: 5646
Зарегистрирован: 23 окт 2008, 17:38
Благодарил (а): 124 раз.
Поблагодарили: 512 раз.

Пред.След.

Вернуться в SAS.Планета

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 10

cron