Ето ни: Бележки за живота на планетата Земя - официален трейлър | Apple TV

Потребителите се оплакаха няколко пъти, че са видели странен набор от розови или зелени ивици на нашата уеб страница. Първоначално мислех, че има обриви от прекъсвания на видеокартата, но след това някой ми изпрати екранна снимка от браузъра си (IE8). По-късно видях същото нещо, но с малко по-различни цветове в Chrome. Потребителите са изпитали това на своите iPad и iPhone (iOS Safari). Тъй като оптимизирах сайта за кеширане на изображения, лошото изображение остава, докато не изчистите кеша, така че след като го направите, то се решава от само себе си. Предполагам, че предаването на изображението се прекъсва в средата на потока и след това остава по този начин, но не мога да разбера за живота си. Ето какво съм проверил:

Дължината на заглавката се изпраща и предаването изглежда добре (пример за wget по-долу):

wget http://www.superiorlivestock.com/templates/sla2/images/wallbg2.jpg --2012-04-05 08:46:00-- http://www.superiorlivestock.com/templates/sla2/images/wallbg2.jpg Resolving www.superiorlivestock.com (www.superiorlivestock.com)... [ip redacted] Connecting to www.superiorlivestock.com (www.superiorlivestock.com)|[ip redacted]|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 45926 (45K) [image/jpeg] Saving to: `wallbg2.jpg' 

Изображенията не се обслужват gzipped (apache conf по-долу):

SetOutputFilter DEFLATE SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip dont-vary 

Сайтът е www.superiorlivestock.com и ето пример за лошото зареждане на страницата:

Има ли нещо очевидно, че липсва? Запазвам ли по някакъв начин изображенията си в грешен формат?

Първото нещо, което забелязах, когато разгледах страницата ви в Firebug, е, че някои от вашите изображения (по-специално това, което toomanyairmiles вече публикува екранна снимка и това друго) са просто огромен - първият е 4.2 мегабайта!

Когато за първи път заредих страницата, огромното изображение беше повредено, повече или по-малко като на екранната снимка на toomanyairmiles. Когато презаредих изображението, то се изтегли правилно. Любопитното е обаче, че и в двата случая файлът с изображения, който получих, беше с дължина 4 362 346 байта; просто в неработещата версия след 3 903 489 байта правилните данни за изображението спряха и бяха заменени с нещо друго (което, уви, изглеждаше точно като случайни байтове - или компресирани данни в JPEG изображение - в шестнадесетичен редактор).

Както и да е, подозирам, че презаписването на тези няколко огромни изображения с по-разумен размер трябва поне да накара проблема да се появи много по-рядко, дори ако всъщност няма да отстрани основната причина за повредата на данните. Като бонус вашият уебсайт също ще се зареди по-бързо.

  • Син на ... ние имаме система за потребителите да създават миниатюри на изображенията, които те постоянно забравят да използват.
  • А, потребители. :) Може да помислите дали има някакъв начин да направите автоматично генерирането на миниатюри.
  • Най-хубавото е, че лицето, което доставя изображенията, понякога ни ги дава с вграден ICC профил, който е повреден. Така че в крайна сметка има проблеми в целия процес. Благодаря за вниманието, допуснах класическата грешка, като предположих, че проблемът на потребителя е „отстранен“ и продължих напред.
  • Прегледах и одитирах всички тези изображения, цели начални страници се зареждат за около 636kb сега, 58k след първоначалното кеширане на изображения.
  • Не съм получавал оплаквания, откакто променихме това, така че това може би е проблемът. Благодаря за вашата помощ!

Изглежда, че не сте единственият, който има такива проблеми, погледнете тук и тук, има някои предложения за поправки в тези теми - изключихте ли ги вече?

Намирате ли се в среда с много уеб сървъри? Може ли един от сървърите в пула да има повредено копие на изображението?

Интересното е, че не се ограничава до фоновото изображение и корупцията засяга изтегленото изображение, което предполага, че наистина може да има проблем с файла, а не със сървъра - как запазвате изображенията?

  • Всичко това се обслужва от една VMware VM, която изпълнява Debian 6 (Squeeze). Запазваме изображенията в мрежата, като използваме настройките, посочени в тази екранна снимка: superiorlivestock.com/settings.png Това ли е проблемът, трябва ли да бъдат запазени като прогресивни?
  • @NateDSaint тези настройки изглеждат добре, каква е зададената разделителна способност, как да качите файловете на сървъра?
  • Разделителната способност е каквато трябва да бъде за това изображение, ние запазваме за мрежата, така че нямаме крайни пиксели на инч, а просто запазваме до каквото е пикселното количество. (в моя пример по-горе, 465x700). Получаваме файлове на сървъра по различни начини, включително FTP и пускане на файлове в споделяне на samba. Странното е, че изображенията не винаги се зареждат по този начин, ако опресните, то има тенденция да се поправя и ние използваме само едно хранилище за данни.
  • @NateDSaint Да, разбирам какво имаш предвид, наистина е много странно - помогна ли някоя от идеите в тези други теми?
  • 1 @NateDSaint Поставих сигнал за миграция, това е просто случай на изчакване на администраторите да наваксат.

е работил за вас: Charles Robertson | Искате ли да се свържете с нас?