как оптимизировать время загрузки сайта в ruby?

Question

Я новичок, который создает легкий сайт для демонстрации фотографий, написанный на php-фреймворке cake с помощью RoR. я планирую использовать эффекты из библиотеки scriptalicious, а также jquery для отображения фотографий и эффектов перехода.

Поскольку сайт будет очень насыщен фотографиями, какие программные шаги я могу предпринять, чтобы гарантировать быструю загрузку всех фотографий и других страниц?

Answer 1

мне кажется, ты немного все путаешь.ror смешивается с php /cake?

итак, о производительности.в основном это зависит от того, сколько, по вашему мнению, у вас будет пользователей, кто эти пользователи и чем они занимаются.10 в час или 100 в секунду?долго ли они смотрят на изображение или быстро перескакивают со страницы на страницу?

вот несколько советов, которые не слишком техничны.никакой оптимизации конфигурации сервера, никакого memcached и так далее.начните думать о производительности со здравым смыслом - это не святой грааль!

• ваш сайт / приложение слишком медленное? чаще всего это не так.никогда не помешает ускорить процесс, но часто люди заботятся о производительности слишком много.всегда помни:дело не в том, чтобы быть быстрым, а в том, чтобы быть достаточно быстро.никто не замечает нескольких лишних миллисекунд.ускорение в 50% заметно, если вашей странице требуется секунда для загрузки, но в основном не имеет значения, если это занимает всего 100 мс.

• чтобы узнать, работает ли ваш сайт медленно, эталонный показатель IT.есть много способов сделать это, один из них автоматизирован, например ab (бенчмарк Apache).он имитирует множество пользователей, подключающихся к вашему сайту, и дает вам краткую информацию о том, сколько времени потребовалось для ответа.другой - это:используй это.и не в локальной сети!если вы чувствуете, что это должно замедлиться, тогда сделайте что-нибудь.

• демонстрация фотографий сильно зависит от изображений.изображения большие.поэтому убедитесь, что на вашем сервере достаточно пропускная способность чтобы доставить их быстро.

• если вы масштабируете изображения (это очень вероятно), не изменяйте размер изображения при каждом запросе страницы, Кэш масштабированное изображение!кешируйте и миниатюры тоже.кэшируйте все.обработка и доставка статического файла намного дешевле, чем постоянно выполнять всю обработку.

• подумайте о качестве изображения.является ли быстрая доставка более важной, чем высокое качество изображения?поиграйте с размер изображения - лучшее сжатие означает меньший размер файла, более низкое качество и более быструю доставку.

• подумайте о удобство использования.если страницы с эскизами нет, людям приходится последовательно перемещаться по вашей библиотеке, просматривая множество фотографий, которые они не хотят видеть.если они уже видят изображение, они могут сразу перейти к тем, которые имеют значение (снижая использование пропускной способности и количество запросов в секунду).подумайте о flickr:размер показанных изображений ...они похожи на почтовые марки - шириной в 500 пикселей, и люди все равно счастливы.если им нужна увеличенная версия, они все равно нажимают на ссылку "все размеры".

• трюки, уловки, уловки:ранее, когда пользователи работали с режимами, иногда передавались изображения с низким разрешением / высокой степенью сжатия, так что через короткий промежуток времени пользователь получал что-то новое.только после загрузки первого изображения запускается увеличенная версия.это больше не распространено, потому что сегодня у большинства пользователей есть широкополосный доступ, поэтому отправка дополнительного изображения - это просто дополнительная нагрузка.

• подумайте о аудитория.будут ли они заходить на ваш сайт с помощью 14,4 тыс. модемов или широкополосного доступа?используются ли они для замедления загрузки сайтов (вероятно, фотографы используют)?проверьте свою статистику, чтобы узнать о них больше.

• ваш серверный скриптовый язык скорее всего, это не ваша проблема.php не очень быстр, ruby не очень быстр - по сравнению, скажем, с c, java или ocaml.фреймворки работают медленнее, чем оптимизированный вручную код.отладьте свой код, чтобы увидеть, где находятся медленные части.мое предположение?изменение размера изображения и доступ к базе данных.это не изменится при переходе на другой язык или оптимизации вашего кода.

что касается скорости работы веб-сайтов

здесь замешано множество факторов.вот некоторые из них:

1. обработка на стороне сервера:быстро ли ваше приложение, быстро ли ваше оборудование?

2. Доставка:как быстро передаются запросы и файлы от клиента к серверу и наоборот?(в зависимости от пропускной способности)

3. рендеринг на стороне клиента:насколько быстр их браузер, сколько работы еще предстоит проделать?

4. запросы пользователя:нужна ли клиенту вообще скорость?иногда медленные страницы не являются проблемой, напримересли они проводят там долгое время, не щелкая мышью.подумайте о сайтах для флеш-игр:если вы потратите час на флеш-игру, вы, вероятно, даже не заметите, загрузится ли страница через 3 или 5 секунд.

воспринимаемая скорость - сочетание всех четырех параметров - является важным показателем.

если вы убедились, что действительно работаете слишком медленно, обязательно оптимизируйте нужную часть.оптимизация серверных скриптов бесполезна, если сервер работает достаточно быстро, но для отображения страницы в браузере требуется целая вечность.нет необходимости оптимизировать время рендеринга, если ваша пропускная способность перегружена.

что касается оптимизации

производительность является неотъемлемой частью при создании приложения.если вам действительно нужно что-то быстрое, вы должны планировать скорость с самого начала.если он не рассчитан на скорость, эффективная оптимизация часто невозможна.

на самом деле это не всегда верно для веб-приложений, потому что они легко масштабируются по горизонтали, что означает:бросьте в него железо.
все стоит денег, и если деньги важны для вас (или вашего босса), не забывайте об этом.сколько стоят две недели оптимизации приложения?скажем, оптимизация обходится вам (или вашему боссу) в X евро зарплаты (я европеец).теперь подумайте о покупке другого сервера:это стоит Y € (включая настройку).если Y < Икс, просто купи сервер, и все будет в порядке.

случайные модные словечки

и последнее, но не менее важное: я подброшу вам несколько случайных (неупорядоченных) модных словечек, может быть, есть что-то, что могло бы помочь.просто погуглите, это должно помочь ...

сети доставки контента, твердотельные накопители Intel, спрайты (объединение изображений для сохранения запросов), сжатие страниц (gzip, deflate), memcached, APC (кэш байт-кода для PHP), сокращение и объединение нескольких CSS и JS файлов, сознательная обработка кодов состояния HTTP (без изменений), разделение статического и динамического контента (разные серверы и домены), пошаговая загрузка через AJAX (сначала важный контент), ...

теперь у меня закончились идеи.

редактировать/обновлять

вещи / техники, которые я забыл:

• внедрите индикатор выполнения или что-то подобное, чтобы пользователи, по крайней мере, чувствовали, что что-то происходит.вы не можете использовать индикаторы выполнения, если работаете только с javascript, но, по крайней мере, показываете какие-то анимированные песочные часы.если вы используете flash, вы можете показать реальный индикатор выполнения.

• вы можете пропустить полную перезагрузку страницы, работая с AJAX или flash - просто загрузите нужные вам данные.вы часто видите это реализованным в галереях изображений flash.просто загрузите изображение и описание.

• предварительная загрузка:если пользователи просматривают одно изображение в течение длительного периода времени, вы уже можете начать загрузку следующего изображения, поэтому оно кэшируется браузером, если пользователь продолжит.

Отказ от ответственности

я никогда не внедрял приложения, критичные к производительности (за двумя исключениями), поэтому большая часть того, что я написал выше, является предположениями и опытом других.сегодня вы прочтете истории об успешных стартапах и о том, как они справлялись (с точки зрения производительности) с охватом от 100 до миллиона пользователей в день, и как они постоянно использовали хитрые приемы для решения всех этих проблем.
но случится ли это с тобой?скорее всего, нет.все говорят об этом, но на самом деле это почти никому не нужно (но я признаю, что все равно приятно это знать).

мой реальный опыт (да, мне нравится писать длинные ответы):

однажды я создавал части веб-сайта с несколькими тысячами уникальных посетителей в день, работающего на cms (typo3) и работающего на одном выделенном samp-сервере (вспомните подержанные серверы solaris десятилетней давности, не ГГц!).вы можете выполнить поиск по квартирам, и форма сообщит вам, сколько результатов вы получите (например20-40м2:400 просмотров, 30-60 м2:600 просмотров) путем перезагрузки iframe НАЖАТЬ КНОПКУ ВКЛ..это было очень, очень медленно (но пользователи все равно им пользовались).постоянно загружается на 100%.решить эту проблему было моей работой.
что я такого сделал?во-первых, выясните, почему это было так медленно.мое первое предположение было верным, запрос по щелчку мыши также использовался typo3 (без кэширования, конечно).заменив это единственное действие пользовательским скриптом, который просто запрашивал базу данных напрямую, минуя typo3, проблема была решена.нагрузка снизилась почти до нуля.это заняло у меня около 2 часов.

у другого проекта было около 1500 уникальных посетителей в день, и он отображал данные сервера с помощью базы данных Oracle с миллионами строк и сложными соединениями, выполнение которых занимало целую вечность (= несколько секунд).у меня не было большого опыта в оптимизации oracle, но я знал:база данных обновлялась только один или два раза в неделю.мое решение:я просто кэшировал содержимое, записав html-код в файловую систему.после обновления (посреди ночи) я очистил кэш и начал его перестраивать.итак, вместо дорогостоящих запросов у меня было просто дешевое чтение файловой системы.проблема решена.

оба примера научили меня тому, что производительность в веб-разработке нет ракетостроение.в большинстве случаев решение простое.и:есть другие детали, которые в 99% случаев намного важнее: стоимость разработчика и Безопасность.

Answer 2

Вопрос довольно расплывчатый.Большая часть времени, затрачиваемого на создание страницы, обычно приходится на получение статического контента.Вот несколько практических правил для ускорения загрузки независимо от языка или фреймворка:

1. Установите Подключаемый модуль YSlow для firefox
2. Используйте CSS-спрайты
3. Имейте легкий http-сервер для статического контента, nginx или световой день
4. Обслуживайте статический контент в другом домене или поддомене, это позволяет выполнять больше одновременных http-запросов
5. Минимизировать javascript и css
6. Кэшируйте страницы как можно больше
7. Держите количество http-запросов на низком уровне
8. Бежать png сокрушить или jpegtran на ваших изображениях

Естественно, это только верхушка айсберга.Это хорошие первые шаги.

Answer 3

Сократите количество библиотек, вы уверены, что хотите использовать jquery + scriptalicious.Придерживайтесь простых вещей, не ищите сложных анимаций.

Быстрая загрузка => Кэширование, страницы с фотографиями - хорошие кандидаты для кэширования.

Если вас беспокоит ощущение скорости работы пользователя, вы можете захотеть предварительно загрузить изображения в фоновом режиме в ожидании действий пользователя, но подумайте, что это может увеличить нагрузку на ваш сервер.Делайте это только в том случае, если у вас хорошая пропускная способность.

Если вы можете создать главную страницу thumbs, которая довольно статична, скажем, меняется два раза в день, вы можете использовать технику sprite для уменьшения задержки при загрузке большого количества thumbs, см.:

http://websitetips.com/articles/css/sprites/