Я думаю, что вы все немного путаете. или смешивать с php / торт?
Итак, о производительности. в основном это зависит от того, сколько пользователей вы думаете, кто эти пользователи и что они делают. 10 в час или 100 в секунду? они долго смотрят на изображение или быстро переходят от страницы к странице?
Вот несколько советов, которые не слишком технически. нет оптимизации конфигурации сервера, нет memcached и так далее. начните думать о производительности со здравым смыслом - это не Святой Грааль!
Ваш сайт / приложение работает слишком медленно? чаще всего это не так. это никогда не повредит ускорению, но часто люди заботятся о производительности слишком много . всегда помните: дело не в том, чтобы быть быстрым, а в том, чтобы быть достаточно быстрым . никто не замечает каких-то дополнительных миллисекунд. ускорение на 50% заметно, если вашей странице требуется секунда для загрузки, но в основном не имеет значения, если на это уходит всего 100 мс.
, чтобы узнать, работает ли ваш сайт медленно, тест . Есть много методов, один из которых автоматизирован, например ab (тест Apache). он моделирует множество пользователей, подключающихся к вашему сайту, и дает вам хорошее резюме, сколько времени потребовалось, чтобы ответить. другой: используйте это. а не в локальной сети! если вы чувствуете, что это медленно, то сделайте что-нибудь.
фото витрина сильно зависит от изображений. изображения большие. поэтому убедитесь, что на вашем сервере достаточно пропускной способности для их быстрой доставки.
если вы масштабируете изображения (это очень вероятно), не изменяйте размер изображения при каждом запросе страницы, кэшируйте масштабированное изображение! кэшировать эскизы тоже. кэшировать все обработка и доставка статического файла намного дешевле, чем постоянная обработка.
подумайте о качестве изображения. Быстрая доставка важнее, чем высокое качество изображения? поиграйте с размером изображения - лучшее сжатие означает меньший размер файла, низкое качество и более быструю доставку.
подумайте о удобстве использования . если нет страницы с миниатюрами, люди должны последовательно перемещаться по вашей библиотеке, просматривая множество фотографий, которые они не хотят видеть. если они уже видят изображение, они могут сразу перейти к тем, которые имеют значение (снижение пропускной способности и количества запросов в секунду). Подумайте о flickr: размер показанных изображений ... они как штампы - 500 пикселей в ширину, и люди все еще счастливы. если им нужна увеличенная версия, они все равно нажимают ссылку «все размеры».
хитрости, хитрости, хитрости : раньше, когда пользователи переключались с режимами, иногда передавались изображения с низким разрешением / высокой степенью сжатия, поэтому у пользователя было что-то за короткое время. только после загрузки первого изображения старшая версия запускается. это больше не распространено, потому что сегодня большинство пользователей имеют широкополосный доступ, поэтому отправка дополнительного изображения - это просто дополнительная нагрузка.
подумайте о аудитории . они собираются посетить ваш сайт с 14.4k модемами или широкополосным? они используются для медленной загрузки сайтов (вероятно, фотографы)? проверьте статистику, чтобы узнать о них.
ваш язык сценариев бэкэнда , скорее всего, не ваша проблема. php не очень быстрый, ruby не очень быстрый - по сравнению, скажем, c или java или ocaml. фреймворки работают медленнее, чем оптимизированный вручную код. отладьте свой код, чтобы увидеть, где медленные части. моя догадка? изменение размера изображения и доступ к базе данных. это не изменится при переключении на другой язык или при оптимизации вашего кода.
относительно скорости сайтов
Есть много факторов. некоторые из них:
обработка на стороне сервера: ваше приложение быстро, ваше оборудование быстро?
доставка: как быстро запросы и файлы передаются от клиента к серверу и наоборот? (в зависимости от пропускной способности)
рендеринг на стороне клиента: как быстро работает их браузер, сколько работы нужно сделать?
Привычки пользователя: нужна ли клиенту скорость? иногда медленные страницы не являются проблемой, например, если они проводят там долгое время, не щелкая вокруг. Подумайте о сайтах флеш-игр: если вы потратите час на флеш-игру, вы, вероятно, даже не заметите, если страница загрузится через 3 или 5 секунд.
воспринимаемая скорость - смесь всех четырех - является важной метрикой.
если вы подтвердили, что вы действительно слишком медлительны, обязательно оптимизируйте правильную часть. Оптимизация сценариев на стороне сервера бесполезна, если сервер достаточно быстрый, но для отображения страницы в браузере требуется много времени. нет необходимости оптимизировать время рендеринга, если ваша пропускная способность засорена.
относительно оптимизации
производительность является неотъемлемой частью при создании приложения. если вам действительно нужно что-то быстрое, вы должны планировать скорость с самого начала. если он не рассчитан на скорость, эффективная оптимизация часто невозможна.
это не всегда так для веб-приложений, потому что они легко масштабируются по горизонтали, что означает: бросьте в это аппаратное обеспечение.
все вещи стоят денег, и если деньги важны для вас (или вашего босса), не забывайте об этом. Сколько стоят две недели оптимизации приложения? скажем, оптимизация стоит вам (или вашему боссу) X € (я европеец) в зарплате. Теперь подумайте о покупке другого сервера: это стоит Y € (включая установку). если Y
случайные модные слова
И последнее, но не менее важное: я буду подбрасывать вам случайные (неупорядоченные) модные слова, может быть, есть что-то, что могло бы помочь. просто Google, это должно помочь ...
сети доставки контента, (intel) твердотельные накопители, спрайты (объединение изображений для сохранения запросов), сжатие страниц (gzip, deflate), memcached, APC (кэш байт-кода для PHP), минимизация и объединение нескольких файлов CSS и JS, в сознании обработка кодов состояния HTTP (без изменений), разделение статического и динамического содержимого (разные серверы и домены), пошаговая загрузка через AJAX (сначала важное содержимое), ...
Теперь у меня нет идей.
редактирование / обновление
вещи / техники, которые я забыл:
реализовать индикатор выполнения или нечто подобное, чтобы пользователи, по крайней мере, чувствовали, что что-то происходит. Вы не можете использовать индикаторы выполнения, работая только с javascript, но, по крайней мере, показывать анимированные песочные часы или часы. если вы используете вспышку, вы можете показать реальный индикатор выполнения.
вы можете пропустить полную перезагрузку страницы, работая с AJAX или flash - просто загрузите нужные данные. Вы часто видите это реализованным в галереях изображений. просто загрузите изображение и описание.
предварительная загрузка: если пользователи просматривают одно изображение в течение продолжительного периода времени, вы уже можете начать загрузку следующего изображения, поэтому оно кэшируется в браузере, если пользователь продолжает.
отказ от ответственности
я никогда не реализовывал приложения, критичные к производительности (за 2 исключениями), поэтому большая часть того, что я написал выше, - это спекуляция и опыт других. сегодня вы читаете истории об успешных стартапах и о том, как они справились (с точки зрения производительности) с переходом от 100 до миллиарда пользователей в день, и как они использовали изощренные приемы, чтобы постоянно решать все эти проблемы.
но это случится с тобой? возможно нет. все говорят об этом, почти никто в действительности не нуждается в этом (но я признаю, это все еще приятно знать) .
мой жизненный опыт (да, я люблю писать длинные ответы):
однажды я занимался частями веб-сайта с несколькими тысячами уникальных посетителей в день, питаясь от cms (typo3) и работая на одном выделенном самп-сервере (вспомните об использованных десятилетних серверах Solaris, не ГГц !). Вы можете искать квартиры, и форма говорит вам, сколько результатов вы получите (например, 20-40 м²: 400 обращений, 30-60 м²: 600 обращений), перезагрузив iframe ON-CLICK . это было очень, очень медленно (но пользователи все еще использовали это). постоянно 100% нагрузка. это была моя работа, чтобы решить эту проблему.
что я сделал? Во-первых, выясните, почему это было так медленно. Мое первое предположение было верным, запрос на нажатие также использовал typo3 (без кэширования, конечно). Заменив это единственное действие пользовательским скриптом, который просто запрашивал базу данных напрямую, минуя typo3, проблема была решена. нагрузка снизилась почти до нуля. заняло у меня около 2 часов.
другой проект имел около 1500 уникальных посетителей в день, отображая данные, хранящиеся в базе данных oracle с миллионами строк и сложными объединениями, которые выполнялись вечно (= несколько секунд). У меня не было большого опыта в оптимизации оракула, но я знал: база данных обновлялась только один или два раза в неделю. мое решение: я просто кэшировал содержимое, записав HTML в файловую систему. после обновления (среди ночи) я очистил кеш и начал его перестраивать. Итак, вместо дорогих запросов у меня были только дешевые чтения файловой системы. проблема решена.
оба примера научили меня, что производительность в веб-разработке , а не ракетостроение. В большинстве случаев решение простое. и: есть другие части, которые являются более важными в 99% случаев: стоимость разработчика и безопасность .