Как вырасти от единственной установки сервера
То, что Вы хотите сделать, действительно не, повторно управляют. Расширение широковещательного домена по WAN не является хорошей идеей.
Существует 2 способа сделать это. Если у Вас есть ссылка уровня 2 между Вами сайт, просто используйте переключатель. Но поскольку Вы говорите о маршрутизаторе, я предполагаю, что Ваш сайт соединен с уровнем 3, таким образом, можно использовать L2TP, чтобы сделать Уровень 2 по Уровню 3 (4 на самом деле).
Смотрите к:
http://blog.dest-unreach.be/2009/05/05/ethernet-over-ip-l2tp-on-cisco
http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/l2tpv325.html
http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6549/ps6587/prod_white_paper0900aecd8066d3f5.html
Купите некоторые аппаратные средства, но поместите их в свою тестовую лабораторию не в дата-центре. Затем подчеркните свое приложение на различных аппаратных средствах / комбинации программного обеспечения, пока Вы не находите разумный, который сделает то, что Вы хотите.
Конечно, необходимо будет спроектировать что-то, что может создать поддельный трафик против подобной производству базы данных, выполняющей тестовую копию приложения. Но кто сказал, что это будет легко.
Если Вы не делаете этого и просто делаете некоторый материал в производстве, Вы понятия не имеете, собирается ли это работать или нет, и Вы, возможно, потратили МНОГО технических вещей реализации усилия как кэши (который будет идти с их справедливой долей ошибок!) на чем-то, что не помогает.
Тест, тест и тест больше. Не бросайте изменения аппаратных средств/программного обеспечения в производство, пока у Вас нет хороших данных о производительности, показывающих, что это, вероятно, значительно улучшит вопросы. Техническое усилие является дорогим, тестовые аппаратные средства не (особенно).
Memcached является всего одной опцией, и Вы не должны, вероятно, рассматривать это, пока у Вас нет кэширования базы данных, работающего оптимально. Это означает помещать его на специализированное (64-разрядный, конечно) поле с разумной суммой RAM (не 4G - ноутбуки имеют это в наше время; 32G определенно доступно), и настройка его соответственно.
Вы не упомянули, насколько большой Ваша база данных, но если это будет вообще выполнимо, то Вы захотите попытаться получить его полностью в поршне (или по крайней мере горячие биты). Получение Вашей базы данных полностью в поршне сделает чтение, операции IO исчезают полностью и следовательно прекращают быть узким местом.
Представьте свои запросы базы данных. Существуют инструменты, живущие для того, чтобы сделать это - необходимо смочь моделировать производственную загрузку в тестовой среде. Прием должен избежать медленных запросов и гарантировать, что часто выполняемые быстры.
Если Ваши проблемы производительности связаны с синхронизациями IO, потому что Вы просто делаете слишком много транзакций для базы данных, удостоверяетесь использование RAID-контроллера с аварийным батарейным питанием, который ведет себя право (говорите поставщиком о них). Они дают намного больше операций записи IO, чем безбатарейный поддерживаемый один (потому что данные только должны добраться до кэша, прежде чем ОС получит подтверждение). С другой стороны, если Ваши данные не имеют значения так очень, рассмотрите ослабление параметров длительности базы данных (innodb синхронизация на фиксации).
-
132G isn' t ужасно доступный, когда you' ре, арендующее аппаратные средства. И аренда аппаратных средств обычно более экономична, когда у Вас только есть одно или два поля. – Frank Farmer 8 March 2010 в 09:33
-
2MarkR / Frank, можно ли больше предлагать понимание на основе графиков, которые я отправил выше? Моя последняя кавычка для дополнительной RAM была ~ £ 50/GB/month! – Jon M 9 March 2010 в 11:20
Путем изучения кэширующихся решений, как многие другие предположили здесь, можно ожидать заканчивать приблизительно с 10% загрузки, которую Вы имеете сегодня, возможно, меньше.
Однако это зависит от того, какие сервисы Вы работаете на своей машине. Можно сделать много с memcached без очень большого количества RAM.
Необходимо попытаться представить, какие запросы базы данных берут самое длинное, или при помощи журнала медленного запроса MySQL (или при помощи эквивалента для базы данных), или при помощи инструмента, такого как mytop. Кроме того, MySQL EXPLAIN SELECT синтаксис может быть полезным.
Кэширование результатов нескольких выбранных запросов MySQL (даже в течение только короткого промежутка времени) может действительно улучшить Вашу производительность много.
-
1Спасибо Vegard. Да, я регулярно консультируюсь с журналом медленного запроса и объясняю команду на моих запросах. Сервер в значительной степени просто выполняет апачские экземпляры и MySQL, но мы действительно делаем несколько вещей как видео преобразование также, который я в процессе перемещения в облачный сервер. – 7 March 2010 в 23:33
-
2Если Ваша проблема действительно исчерпывает апачские потоки, можно довольно тривиально снять некоторую загрузку путем установки nginx (или другой легкий обратный прокси) перед апачем. Nginx может затем обслуживать статическое содержание и принять задачу кормления с ложечки медленных клиентских байтов, освободив апача, чтобы сделать то, что он действительно должен: действуйте как контейнер приложения PHP. Для большего количества полного обзора этого понятия см.: modperlbook.org/html/… – Frank Farmer 8 March 2010 в 09:13
-
3Спасибо Frank, это, конечно, кажется разумным, I' ve переместился так, как я могу на Amazon S3, первоначально это был просто UGC, но я теперь пытаюсь поставить все графические элементы и элементы CSS там также. I' m уверенный существует некоторая тонкая настройка Apache и MySQL, которая будет сделана. – Jon M 8 March 2010 в 13:32
Я делаю большую производительность и масштабирую горизонтально работу и что я обнаружил, то, что:
Каждая загрузка приложения уникальна
Универсальные ответы те, которые добавляют больше поршня, получите другой сервер, сделайте y, попробуйте x, часто уроки в разочаровании и уезжают к замысловатым установкам.
Измерьте правильные вещи
Одна из самых сложных задач находится в определении, какие сравнительные тесты важны. Это часто требует шага назад, и необходимо поместить себя в обувь своего клиента. Иногда, упрощенный дизайн сайта изменяется и средние огромные преимущества для посетителя веб-сайта. Поэтому мне нравятся инструменты как YSlow! которые фокусируются больше на опыте конечного пользователя, а не уровне сервера. После того как Вы решаете то, что правильный сравнительный тест для Вашего сайта, затем можно начать настраиваться. Сравнительные тесты могут быть общим временем загрузки страницы, общим размером страницы, эффективностью кэша, задержкой сайта, и т.д. Необходимо выбрать тот, который имеет смысл для приложения.
Основные детали
Один Вы отслеживаете правильные сравнительные тесты, запускаетесь на очень низком уровне. Мне нравится использовать sysstat. Можно получить богатство информации от sysstat и помочь Вам дразнить независимо, какая система может ограничивать полную производительность приложения. Обычно я кипячу проблемы производительности в:
- сетевой стек
- стопка памяти
- диск io
- прикладной уровень
- слой OS
Используя sysstat и другие инструменты, можно начать крохоборствовать и находить систему, которая ограничивает производительность.
Например, я видел, что высоко загруженные серверы перестали работать из-за того, как их приложение было настроено. Плохое кэширование, отсутствие истекает, заголовки на статическом содержании, с помощью HTTP по сравнению с файлом включают, и т.д. все способствовали низкой производительности приложений. Фиксация этих проблем приложения не потребовала никаких изменений аппаратной конфигурации. В других случаях я видел диски, истраченные несмотря на тонны кэширования. Перемещение в более быстрые диски устранило проблему.
Промывка и повторение
Часто во время настройки приложения, Вы откупорите одно узкое место, чтобы только найти другой. Поэтому я рекомендую пытаться контролировать независимо от того, что это - Вы, настраиваются.
Например, скажите, что Вы устраняете дисковую IO проблему, но Ваше приложение является все еще медленным. Можно думать, что Вы потратили впустую свои усилия, но что, происходят, у Вас есть простой удар другого узкого места. Путем контроля диска IO тщательно, можно быть уверены, что Вы улучшаете диск IO, даже если Ваши мониторы производительности важного приложения не изменяются.
Получите правильные инструменты
Удостоверьтесь, что Вы используете правильные инструменты для задания. При контроле, тестируя, сравнивая, представляя, и другие методы оптимизации у всех есть множество инструментов. Найдите инструмент что лучшие соответствия Ваша ситуация лучше всего.
Эмпирические правила
В то время как каждое приложение уникально, я действительно нахожу некоторые стандартные начальные точки:
- базы данных памяти любят память
- диск io что-либо кроме набега 10 может уничтожить производительность базы данных
- неправильная оптимизация - большие значения не переводят в большую производительность
- приложение - обвинение сервера для плохого дизайна приложения
Ваши следующие шаги
Если Вы не находите свое узкое место, добавляя, что сервер не может помочь многому. Для решения диска IO, Вам, возможно, понадобятся другой сервер или SAN. Если у Вас будет узкое место поршня, то другой сервер решит проблему только, в которой он добавляет больше RAM. Довольно дорогостоящее перемещение по сравнению только с добавлением большего количества RAM к Вашему существующему серверу.
Быстрое исправление
Развернитесь. Я должен был сделать это, когда кажется, что стек приложений является проблемой. В основном нагрузка на ЦП, RAM и диск IO (RAID 10, 15K SCSI или SSD). Пойдите крупные на аппаратных средствах и затем начните настраиваться. Это сохраняет Вас на плаву, пока Вы не решаете проблемы.
Я сказал бы, что следующий шаг должен кэшироваться (кэширование данных и/или страница, кэширующаяся в зависимости от Вашей функциональности). Если memcached кажется слишком сложным, можно запустить с простых решений для кэширования данных как ГРУШЕВЫЙ Кэш, Облегченный, который требует просто строк кода пары, но мог иметь огромное значение. Страница (или части страницы) кэширование поддерживается движком шаблонов Присяжного острослова, например.
После того как кэширование больше не сокращает его, затем можно увеличить сумму сервера, поскольку нет ничего иного оставленного.
-
1Спасибо за Ваш совет Serg, I' m уже кэширующийся к HTML в различных местах и используют некоторые ночные запросы базы данных для заполнения нескольких " быстрый lookup" таблицы. – 7 March 2010 в 23:03
Если у Вас будет достаточно свободной RAM, то memcached поможет Вам даже на том же поле. Попытайтесь кэшировать несколько самых тяжелых запросов и видеть то, что произойдет. Кроме того, Apache слишком тяжел, используйте nginx или lighttpd вместо этого (с приложением PHP, работающим через FastCGI, см. php-fpm).
-
1Если у Вас есть достаточно свободной RAM, и mysql не спешащий запросы чтения ответа, Вы don' t имеют mysql настроенное право. используйте поршень для базы данных вместо этого. MySQL' s кэширование будет совершенно очевидно для приложения, не представит ошибки и никогда не возвращать устаревшие данные. – MarkR 8 March 2010 в 00:38
-
2Кэш запроса mysql, для многих рабочих нагрузок, делаемых недействительным слишком настойчиво для стоения. Обновление одной строки на таблице делает недействительным каждый запрос против той таблицы. – Frank Farmer 8 March 2010 в 09:31
Начните кэшироваться, но проигнорируйте MySQL в настоящий момент. Seriouosly.
Правило должно быть - останавливают запрос КАК МОЖНО РАНЬШЕ. Так, обратное или надлежащее кэширование уровня Apache прокси собирается получить Вас лучшие результаты, затем sql результат уровня, кэширующийся В РАМКАХ приложения, затем sql кэширование уровня ;)
Чем ранее Вы останавливаете запрос, тем менее служебный Вы имеете. Уровень выходного кэша - даже PHP не должен работать, так сказать.