Производительность CVS
.md обозначает уценку и генерируется внизу вашей страницы github как html.
Типичный синтаксис включает в себя:
Will become a heading
==============
Will become a sub heading
--------------
*This will be Italic*
**This will be Bold**
- This will be a list item
- This will be a list item
Add a indent and this will end up as code
Для более подробной информации: http://daringfireball.net/projects/markdown/
3 ответа
CVS будет работать медленнее со временем из-за многократного использования.
- Когда вы извлекаете весь проект, сервер потребуется создать каждый каталог (даже если вы его уже удалили - очистка каталогов после извлечения скрывает это от вас).
- Когда вы извлекаете, каждый файл открывается и проверяется, это может быть очень медленным, если у вас есть сотни / тысячи файлов.
- Ситуация становится еще хуже, если вы не пытаетесь извлечь ГОЛОВУ магистрали, так как содержимое необходимо реконструировать перед отправкой его клиенту.
Если после всего этого, если вы хотите повысить производительность передачи данных между сервером и клиентом, тогда вы можете (в зависимости от типа контента) использовать параметр -z для сжатия. Я считаю, что -z6 лучше всего, но в зависимости от характера ваших файлов вы можете захотеть больше / меньше сжатия.
-z GZIPLEVEL
Устанавливает уровень сжатия при обмене данными с сервером. Аргумент GZIPLEVEL должен быть числом от 1 до 9. Уровень 1 - минимальное сжатие (очень быстрое, но не сильно сжимается); Уровень 9 - это максимальное сжатие (использует много процессорного времени, но сжимает данные). Уровень 9 полезен только при очень медленных сетевых подключениях. Большинство людей считают, что наиболее полезными являются уровни от 3 до 5.
Пробел между -z и его аргументом необязателен.
Проблемы с производительностью обычно связаны с вводом-выводом. (Если только вы не видите, что ваш процессор загружен на 100%). Я бы рекомендовал попытаться разместить репозиторий на более быстром массиве дисков (RAID 10 и / или диски с более высоким числом оборотов в минуту), чтобы увидеть, повысит ли это вашу производительность. Если вы обращаетесь к репозиторию через Интернет, то это, скорее всего, проблема с пропускной способностью, хотя в зависимости от того, какой объем данных вы говорите, даже простое соединение DSL должно справиться с этим.
cvs сам по себе не может сжать afaik, но если использовать ssh для транспорта, ssh может это сделать (и, думаю, по умолчанию). Это поможет при медленном соединении. править: на самом деле cvs получил опции -z (как ssh получил -C)
Шифрование не используется для повышения производительности. Использование ssh также сделает шифрование, но это не для производительности, а для безопасности.
Где бы ни находился репозиторий, доступ к диску для репозитория и временных файлов будет влиять на производительность. Это в сочетании с памятью. При оформлении cvs создаст то, что будет отправлено клиенту (в виде временных файлов). Это вызывало много дискового доступа и в некоторых случаях использование памяти (особенно при работе с большими двоичными файлами).