Base 64 인코딩과 이미지 파일 로드
그래서 저는 php에서 이미지를 sql 데이터베이스에서 가져와 base64로 인코딩해야 하는 작업을 하고 있습니다.이러한 이미지를 표시하는 속도가 매우 중요하기 때문에 데이터베이스 데이터를 이미지 파일로 변환한 다음 브라우저에 로드하는 것이 더 빠를지 아니면 원시 base64 데이터를 에코하여 다음을 사용할 수 있는지 알아보고 있습니다.
<img src="data:image/jpeg;base64,/9j/4AAQ..." />
FireFox 및 기타 Gecko 브라우저에서 지원됩니다.
요약하자면, 실제 이미지 파일이나 base64 코드를 전송하는 것이 더 빠를까요?Ajax를 사용하여 이미지를 로드할 때 http 요청이 더 적게 필요합니까?
이미지는 총 100픽셀 이하입니다.
- Base64 인코딩은 파일을 더 크게 만들어 전송 속도를 늦춥니다.
- 페이지에 이미지를 포함시킴으로써, 그것은 매번 다운로드 되어야 합니다.외부 이미지는 일반적으로 한 번만 다운로드되고 브라우저에 의해 캐시됩니다.
- 일부 브라우저와 호환되지 않습니다.
저는 여러분 중 누구에게도 동의하지 않습니다.점점 더 많은 이미지를 로드해야 하는 경우가 있습니다.모든 페이지에 3개의 이미지가 있는 것은 아닙니다.사실 저는 200개 이상의 이미지를 로드해야 하는 사이트에서 일하고 있습니다.100,000명의 사용자가 매우 로드된 사이트에서 200개의 이미지를 요청할 때 발생하는 작업입니다.이미지를 반환하는 서버의 디스크가 접혀야 합니다.더 나쁜 것은 base64가 있는 서버 대신 서버에 많은 요청을 해야 한다는 것입니다.썸네일이 많은 경우 데이터베이스에 미리 저장된 base64 표현을 선호합니다.저는 http://www.stoimen.com/2009/04/23/when-you-should-use-base64-for-images/ 에서 해결책과 강력한 논쟁을 발견했습니다.그 남자는 정말로 그 사건에 연루되어 있고 몇 가지 테스트를 했습니다.저는 감명을 받았고 시험도 치렀습니다.현실은 말 그대로입니다.한 페이지에 로드된 이미지가 너무 많은 경우 서버에서 한 번 응답하는 것이 매우 유용합니다.
이미지가 수정되지 않을 경우 이미지를 다시 생성하는 이유가정하면, 1000개의 다른 조건을 기준으로 1000개의 가능한 이미지가 표시되더라도, 저는 여전히 디스크의 1000개의 이미지가 더 낫다고 생각합니다.디스크 기반 이미지는 브라우저에서 캐시할 수 있으며 대역폭 등을 절약할 수 있습니다.
그것은 매우 빠르고 쉬운 해결책입니다.이미지 크기가 약 33% 증가하지만 base64를 사용하면 http 요청 수가 상당히 줄어듭니다.
Google 이미지와 Yahoo 이미지는 base64를 사용하며 이미지를 인라인으로 제공합니다.소스 코드를 확인하면 볼 수 있습니다.
물론 이러한 접근 방식에는 단점이 있지만, 저는 이점이 비용보다 크다고 생각합니다.제가 찾은 단점은 느린 장치에 있습니다.예를 들어, iPhone 3GS에서 Google 이미지가 제공하는 이미지는 서버에서 gzip 형식으로 제공되며 브라우저에서 압축을 풀어야 하기 때문에 렌더링 속도가 매우 느립니다.따라서 고객이 느린 장치를 가지고 있다면 이미지를 렌더링할 때 약간의 어려움을 겪을 것입니다.
첫 번째 질문에 답하기 위해 96ppi의 JPEG 이미지 400x300px를 측정하는 테스트를 실행했습니다.
base64ImageData.Length
177732
bitmap.Length
129882
저는 아이콘(10x10 픽셀 정도)에 base64 이미지를 한두 번 사용한 적이 있습니다.
Base64 이미지 전문가:
- 압축 - 단일 파일이 있습니다.또한 파일이 압축된 경우 base64 이미지는 일반 이미지와 거의 같은 크기로 압축됩니다.
- 페이지는 단일 요청으로 검색됩니다.
Base64 영상은 다음과 같습니다.
- 현실적으로 이미지가 포함된 모든 페이지에서 스크립트 엔진(예: PHP)을 사용해야 합니다.
- 이미지가 변경되면 캐시된 모든 페이지를 다시 캐시해야 합니다.
- 이미지가 인라인이므로 CDN 또는 정적 콘텐츠 웹 서버를 사용할 수 없습니다.
일반 이미지 전문가:
- 만약 당신이 SPDY 프로토콜을 사용한다면, 적어도 이론적으로, 페이지 + 이미지 + CSS 또한 단일 요청으로 로드될 것입니다.
- 브라우저에서 내용이 캐시되도록 이미지에 만료 기간을 설정할 수 있습니다.
하지 마data://
IE7 이하에서 작동합니다.
이미지가 요청되면 파일 시스템에 저장한 다음 그 이후로 이미지를 제공할 수 있습니다.데이터베이스의 이미지 데이터가 변경되면 파일을 삭제합니다.img.domain.com 과 같은 다른 도메인에서도 서비스를 제공할 수 있습니다.PHP를 시작할 필요 없이 웹 서버에서 마지막으로 수정된 태그 또는 전자 태그의 모든 이점을 무료로 얻을 수 있습니다.
Apache를 사용하는 경우:
# If the file doesn't exist:
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^/(image123).jpg$ makeimage.php?image=$1
일반적으로 base64 인코딩을 사용하면 바이트 크기가 약 1/3 증가합니다.따라서 데이터베이스에서 서버로 1/3바이트를 이동한 다음 유선을 통해 동일한 1/3바이트를 브라우저로 이동해야 합니다.
물론 이미지의 크기가 커질수록 언급된 오버헤드도 비례적으로 증가합니다.
그렇긴 하지만, 파일을 DB에서 바이트 표현으로 변경하여 전송하는 것이 좋다고 생각합니다.
OP 질문에 답변합니다.웹 서버를 통해 직접 디스크를 통해 정적 파일로 사용할 수 있습니다.웹 서버에 의한 메모리 캐싱에 이상적으로 적합한 100px입니다.거의 모든 웹 서버에 대한 정보, 캐싱 전략, 구성, 사용 방법 등이 너무 많습니다.
실제로 - 사용자 환경(이미지 속도) 측면에서 가장 좋은 옵션은 CDN 지원 개체 저장소를 사용하는 것입니다.기간
정적 스토리지로 "DB"를 선택하는 것은 모든 오버헤드 처리, DB에 대한 부담, 재정 및 기술 부채 측면에서 비용이 많이 듭니다.
몇 가지, 몇 가지 대답에서.
Google 이미지와 Yahoo 이미지는 base64를 사용하며 이미지를 인라인으로 제공합니다.소스 코드를 확인하면 볼 수 있습니다.
아니요, 절대 그렇지 않아요.이미지는 대부분 정적 파일 "웹 서버"에서 제공됩니다. 특히 gstatic.com : 예: https://ssl.gstatic.com/gb/images/p1_2446527d.png
압축 - 단일 파일이 있습니다.또한 파일이 압축된 경우 base64 이미지는 일반 이미지와 거의 같은 크기로 압축됩니다.
그렇다면 실제로는 아무런 이점도 없고 압축에 필요한 처리 기능도 전혀 없습니까?
페이지는 단일 요청으로 검색됩니다.다시 한 번 더 큰 로드가 아닌 여러 개의 병렬 요청이 발생합니다.
100,000명의 사용자가 매우 로드된 사이트에서 200개의 이미지를 요청할 때 발생하는 작업입니다.이미지를 반환하는 서버의 디스크가 접혀야 합니다.동일한 양의 데이터를 계속 보내지만 연결 시간이 길며 데이터베이스에 스트레스를 줍니다.두 번째로 공장 현장에서 동시 접속자가 100,000명이 될 확률은...설령 그렇다 하더라도, 이 모든 것을 하나의 서버에서 실행하고 있다면 어리석은 관리자입니다.
이진 블롭 또는 base64와 같은 이미지를 DB에 저장함으로써 DB에 막대한 오버헤드를 추가할 수 있습니다.RAM의 양과 양이 많거나 DB를 통한 쿼리가 디스크에서 삭제됩니다.또한 RAM이 제한되지 않은 경우 RAM 디스크에서 빈 이미지를 제공하는 것이 가장 빠르고 가벼운 부하가 될 수 있습니다. 즉, 하위 도메인에 구성된 최적화된 전용 경량 웹 서버 정적 파일 및 캐싱을 통해 하는 것이 이상적입니다.
미래 계획?지금까지는 확장만 가능하며 DB 확장은 비용이 많이 듭니다(상대적으로).다시 말씀하시는 디스크는 "sp"입니다.
이러한 경우, 100,000명의 동시 사용자에게 100개의 이미지를 제공하는 경우 이미지를 제공하는 것이 CDN Object 저장소의 도메인이어야 합니다.
가장 빠른 속도를 원한다면 업로드/수정할 때 디스크에 기록하고 웹 서버가 정적 파일을 제공하도록 해야 합니다.Rojoca의 제안은 php의 호출을 최소화하기 때문에 좋습니다.다른 도메인에서 서비스를 제공하는 추가적인 이점은 (대부분의) 브라우저가 요청을 동시에 실행한다는 것입니다.
이 모든 것을 제외하고 데이터를 쿼리할 때 마지막으로 수정되었는지 확인한 다음 디스크에 기록하고 거기서 서비스를 제공합니다.데이터를 불필요하게 전송하지 않도록 If-Modified-Since 헤더를 준수해야 합니다.
디스크나 다른 캐시에 쓸 수 없는 경우에는 데이터베이스에 이진 데이터로 저장하고 스트리밍하는 것이 가장 빠릅니다.이때 버퍼 크기를 조정하면 도움이 됩니다.
언급URL : https://stackoverflow.com/questions/522897/base-64-encode-vs-loading-an-image-file
'programing' 카테고리의 다른 글
telerik asp.net mvc 그리드에 매개 변수 전달 (0) | 2023.08.25 |
---|---|
단순 getColumnName(0) 호출이 잘못된 열 인덱스를 던집니다. getValidColumnIndex (0) | 2023.08.25 |
평균 가중 가격을 찾기 위한 쿼리 (0) | 2023.08.25 |
Rails: 다른 컨트롤러에서 .js.erb를 렌더링하시겠습니까? (0) | 2023.08.25 |
코드 점화기에서 아약스 호출에서 게시물이 왔는지 확인하는 방법은 무엇입니까? (0) | 2023.08.25 |