Современных - нет. Раньше были поделки на три панели, насколько они актуальны сейчас - не знаю.
Но вы бы пояснили задачу, возможно то, что вы делаете, нужно делать с другим подходом.
partyzanx, БД занимает ровно столько, как вы ее настроите.
Ну и в принципе. не делайте тогда ничего, ибо чтобы вы не сделали - все будет занимать память.
Saboteur
@saboteur_kiev Куратор тега Компьютерные сети
Владислав Лысков, Нигде не слышал ни в одном договоре о пинге. В лучшем случае "скорость ДО xx mbit"
И да, провайдер отвечает только за себя, остальная задержка за пределами его собственной сети - не его проблема.
* Если хотите, считайте столько, сколько надо. Опять же, неизвестно сколько там расчетов. Надеюсь, вы догадываетесь, что эксель считает ГОРАЗДО медленнее базы данных? Сколько там тех строк посчитать
* Храните данные за каждый месяц и пересчитывайте помесячно, нет проблем выбрать строки только за один месяц. В базе данных есть индексы.
* Делайте несколько таблиц, никто не мешает создавать вам отдельные таблицы на каждый месяц. Даже автоматически.
* Эксель в принципе нельзя сравнивать по быстродействию с базой данных. И если у вас не тормозит эксель, то база данных будет работать еще быстрее.
Saboteur
@saboteur_kiev Куратор тега Компьютерные сети
Евгений Лернер, если вы знаете, где находится сервер, и есть возможность в том же датацентре арендовать виртуальную машину, то можно через нее ходить на сервер с минимальной задержкой.
Saboteur
@saboteur_kiev Куратор тега Компьютерные сети
Евгений Лернер, На маленьких расстояниях (в пределах города, например), основная задержка - обработка пакетов на свичах.
Пакет нужно прочитать, разобрать, понять куда его дальше роутить, отправить в нужный канал. В зависимости от оборудования провайдера это может занять от наносекунд до миллисекунд.
На больших расстояниях (между странами и тем более между континентами), основная задержка - транспортировка пакета, ибо там может быть десятки миллисекунд и задержка на маршрутизаторах становится незначительной по сравнению с транспортной, но это обычно последняя миля пользователя.
В случае использования медленного транспортного протокола (модем, блутус, docsis старых версий, радиоезернет на 20-30 км), задержка на передачу в общем случае всегда будет основным моментом.
Еще момент - непонятно что такое "хотелось бы веб сервер поближе".
У вас будет только один клиент - вы? Тогда ставьте сервер на свой локальный комп и все.
Saboteur
@saboteur_kiev Куратор тега Компьютерные сети
Вот меня интересует как кол-во промежуточных серверов зависит от расстояния и какую задержку они вносят
Никак. У провайдера могут быть сложные пути создания своей инфраструктуры, особенно в условиях городской застройки и развития.
Маленькая частная домашняя сеть, которую изначально разводили на коленке, может развиться в уверенного провайдера. А коммутационные колодцы могли быть, например, приватизированы другой компанией, и чтобы проложить кабель из дома в соседний дом, придется или платить аренду за использование подземного пространства, или пойти назад, где свой кабель давно лежит и обойти квартал.
А потом несколько маленьких провайдеров выкупает крупный монополист, и где-то перекладывает, где-то оставляет как есть.
Промежуточные сервера вносят РАЗНУЮ задержку.
Еще раз повторю - команды tracert и traceroute покажут текущий маршрут, чтобы понять сколько хопов и какая задержка. А вот почему она такая, вы не узнаете, поскольку это внутренняя техническая информация провайдера, и о том как настроены эти промежуточные хопы и какую задачу выполняют клиентам рассказывать не будут.
Saboteur
@saboteur_kiev Куратор тега Компьютерные сети
Евгений Лернер, нет таких данных как 1000 км.
Это же живая инфраструктура, которую строили надежно или на соплях.
Между провайдерами различные соединения с разными договорами по скорости и стоимости. Твой пакет может прийти по разному маршруту в разное время дня суток из-за стоимости.
в общем случае домашний пользователь.
Есть его комп, есть роутер в квартире - вот один кабель, один хоп до роутера, скажем 5 метров
потом езернет до роутера провайдера в подъезде, второй хоп, скажем 20 метров
от роутера провайдера идет оптикой, например несколько километров до серверной провайдера, третий хоп
Потом у самого провайдера может быть внутри несколько разных роутеров, которые врубаются в роутер отвечающий за внешние аплинки, четвертый хоп , скажем 2 метра
Потом до другого провайдера оптика, например 20 километров.
Потом у другого провайдера оптика внутренние маршрутизации по его серверной, пару метров
Потом у другого провайдера оптика еще одна внутренняя маршрутизации по его серверной, пару метров
Потом у другого провайдера оптика до какого-то дома, 1 км
Потом у другого провайдера езернет внутри дома до квартиры, 20м
Потом у другого провайдера езернет внутри квартиры до чужого компа.
Вот и приехали от одного пользователя до другого, это хорошо если пользователи в одном городе у разных провайдеров. А если в разных странах, а если там через 3-4 промежуточных провайдера...
Юзай команды tracert или traceroute чтобы посмотреть маршрут.
если jar, то по идее только jre (если им только запускать, то только runtime)
ну и на шарпе - это если под винду, то в общем случае совместимость между библиотеками довольно высокая.
А если под линукс, то шарповские библиотеки ж копируются те же самые.
А вот с нативными shared libary под линукс, там glibc и зависимости меняются и это гемор, да.
Поэтому хороший выход - jre и jar, тем более что их можно одним пакетом через jlink организовать.
Вот ознакомьтесь с тем, что в Линуксе между версиями несовместимость может оказаться гораздо больше, чем в Windows, и если исполняемый файл собран с shared library для другой версии линукса, значит не поддерживается.
Для этого собственно java распространяется в .jar файлах, чтобы как можно меньше зависеть от архитектуры и ее версиях, и зависеть только от версии java
Сделать файл так, чтобы "у других работало" невозможно, если не перечислить этих других и не соблюсти требования этих "других"
Но вы бы пояснили задачу, возможно то, что вы делаете, нужно делать с другим подходом.