Самый быстрый удаленный X из Windows
Нет никакого требования для MySQL, который будет установлен на CentOS 6.
При принятии "использования только Основные пакеты" означают выбор "Основного Сервера" или "Минимальный", когда Вы сделали установку, это было втянуто как зависимость для core группа. core включает постфикс, который зависит от mysql-libs который является тем, что обеспечивает/usr/lib/mysql/libmysqlclient.so.16.
Опции инсталляции "Значения по умолчанию" CentOS 6 могут представлять интерес для Вас.
Я думаю, что состояние для максимальной пропускной способности является NX, программой сжатия протокола X11. Это должно работать хорошо относительно задержки также. Попытайтесь использовать клиент Windows NX и свободный сервер NX на Linux.
Если возможно, используйте прямое соединение TCP вместо SSH. Конечно, это только жизнеспособно в управляемой среде без забот безопасности.
Я думаю в большинстве установок, виртуальная машина, работающая локально, даст Вам лучшую задержку. Еще лучше выполните Emacs и Eclipse в соответствии с Windows; заставьте их отредактировать удаленные файлы, или (для еще лучших результатов) заставляют их отредактировать локальные файлы, которые Вы затем синхронизируете с Унисоном или через систему управления версиями.
Windows Remote Desktop работает просто великолепно - пока Вы выполняете xrdp на поле Linux (и по моему опыту, это является значительно менее раздражающим и более быстро реагирующим, чем VNC).
xrdp выполняет X-сервер на поле Linux и затем сцепляет это до RDP.
На самом деле, даже при том, что у меня обычно есть Linux на обоих концах этого провода, я обычно предпочитаю rdesktop xrdp по VNC каждый раз, когда простая передача X11 оказывается слишком вялой. VNC является просто французским акронимом для, "не работает очень хорошо".
На самом деле я был в шоке чтобы обнаружить, что Mobaxterm сверхбыстрый.
Я разработчик программного обеспечения и использую среду IDE под названием Qt Creator. Известно, что Qt Creator работает очень, очень быстро, но Putty + Xming работали с ним слишком медленно, поэтому я отказался от использования его через удаленный xserver. В конце концов Mobaxterm поразил меня своей скоростью. Попытайся.
Я согласен, что Mobaxterm быстро пересылает x. Затем я узнаю, что он использует ssh на основе cygwin, но он все еще быстрее, чем мой cygwin/ssh. Изучив отладочную информацию, я обнаружил, что секрет Mobaxterm заключается в использовании aes128 -ctr , а не более распространенного aes256 -cbc шифра, используйте hmac -sha1 и включить сжатие по умолчанию.
В Cygwin
ssh -m hmac-sha1 -c aes128-ctr -C
должен дать вам производительность, близкую к mobaxterm. Если вы все еще считаете, что mobaxterm быстрее, вы можете напрямую использовать _ssh.exe,который вы можете найти в корне вашего mobaxterm.
Некоторые блоги/ответы предлагали такие шифры, как arcfour или blowfish . Они должны быть немного лучше, чем aes128 -ctr(для старых процессоров ), но они устарели и не обязательно доступны на всех платформах. Вы можете просмотреть все поддерживаемые шифры и Mac от
ssh -Q cipher
ssh -Q mac
Этот эталонный тест показывает, что aes128 -gcm должен обеспечить наилучшую производительность на современном ЦП.
Обновление:
Некоторые предлагают отказаться от сжатия. Я бы предположил, что -C все еще помогает, если только ваше испытание не окажется иным, даже если вы считаете, что ваша сеть идеальна. Поскольку объем передаваемых данных очень велик, а степень сжатия впечатляет, т.е.
debug1: compress outgoing: raw data 603154, compressed 141717, factor 0.23
debug1: compress incoming: raw data 67841628, compressed 641357, factor 0.01
На самом деле, я пробовал x переадресацию как с прямым tcp, так и с ssh со сжатием и соответствующим шифром по внутреннему LAN-соединению со скоростью 100 Мбит/с с задержкой <1 мс. Вариант ssh явно быстрее.