У меня есть веб-приложение (.NET, обслуживаемое iis6), которое предоставляет конечным пользователям данные почти в реальном времени. Наши серверы находятся в центре обработки данных в Северной Америке, но наши австралийские пользователи испытывают неприемлемую производительность (неудивительно). Учитывая, что у нас нет неограниченных ресурсов, каковы некоторые стратегии повышения производительности в Aus?
Размещение веб-сервера / сервера приложений в Австралии - очевидный ответ, но нам также потребуется репликация наших dbs (быстро приближающихся к 100 ГБ), и, учитывая, что репликация должна происходить почти в реальном времени (до минуты будет нормально), что звучит как дорогое занятие. Использование CDN поможет для статического контента.
Есть ли какие-то другие стратегии, на которые мне следует обратить внимание, чтобы исправить ситуацию?
Если ваши данные хранятся в СУБД и в основном предназначены только для чтения, лучшим вариантом может быть установка ведомого устройства базы данных и внешнего интерфейса только для чтения в Австралии - вы должны иметь возможность поддерживать репликацию почти в реальном времени (± 1 с задержкой до 5 минут) довольно надежно с этой конфигурацией, если в вашей базе данных не происходят постоянно огромные изменения. Вы никогда не говорили, как часто у вас происходят изменения в БД / насколько велики эти наборы изменений, но обычно репликация БД может выполняться по относительно тонким каналам после того, как начальная синхронизация завершена.
Это то, с чем вам, вероятно, следует сначала поиграть в тестовой лаборатории (используя брандмауэр, формирующий трафик, чтобы ввести ограничения задержки и / или полосы пропускания, чтобы увидеть, каковы ваши минимальные требования для успешной репликации). Вы, вероятно, также захотите отправить в основном обновленную БД и позволить ей «догнать» синхронизацию после ее установки в Австралии, чтобы минимизировать начальное время запуска ...
Вы также можете подумать о том, чтобы приложение отправляло обновления своей БД для всех языковых стандартов (при условии, что «обновляющий» аспект приложения находится только в одном месте), а затем помещал доступный только для чтения сегмент приложения в локальный Экземпляр БД.
Это зависит от количества пользователей и степени вашего контроля над настройкой их клиентов, но вы можете рассмотреть что-то вроде MS Terminal Services, Citrix или что-то подобное в среде Linux.
Если данные, отображаемые в каждом веб-запросе, невелики, перемещение данных может не быть реальной проблемой.
Возможно, HTML-код, возвращаемый вашим приложением, слишком раздут. Если вы можете уменьшить размер html, ваши пользователи сочтут его более приемлемым.
Вы также можете переместить свой сервер (ы) в Калифорнию. Хорошее компромиссное место для обслуживания США и Австралии.