안녕하십니까. 좋은아빠되기입니다.
아마존 라이트 세일 5달러 짜리 끊어서 이용중입니다.
근데.. 누적 트래픽 확인하는곳을 모르겠네요...
제가 신 메뉴얼 길치 인가요? ㅋㅋㅋ
관리화면에서 - 지표 라는데 들어가니깐.
이렇게 나오기는 하는데....
저 MB라는 것도... Mbps 인지.. MByte 단위 같기도 하고(설명서 어디선가 얼핏본 기억이... 아닐지도 몰라요 ㅎㅎ)
어떻게 누적 트래픽을 나타내주는곳이 없다면
단위라도 정확하게 알아야..
2T 트래픽을 다 써먹을 궁리를 할텐데요 ㅎㅎㅎ
도움 부탁 드립니다.
하나만더 여쭙겠습니다.
제가 정학하게 본건지 모르겠지만...
이번달까지 사용량이라고해서
17.00 / 20,000 이라고 되어 있는데..
20,000
즉 2만이라는 숫자의 의미를잘 모르겠네요.
저게 MB단위로고해도.. 20,000MB는 20G가 되는데...
저게 신청 날짜와 남은 날짜때문에 저런식으로 표기가 된건지..
아님 또 제가 뭘 이해를 잘못하는건지..ㅎㅎㅎ
조언 부탁 드립니다.
그런데 이미지주소는 아직 적용 못하셨나 보네요. 불과 제가 1시간 전에 문제풀이에 등장하는 이미지 주소를 보니 캐시에 대응하지 못하는 문제를 아직 안고치셨더라구요.
제가 볼때 문제풀이에 들어간 이미지가 제법이라 여기서 사용되는 트래픽이 상당해 보입니다.
아마 절감이 꽤 될 것 같네요. 많이 사용되는 파일들이 캐시되어 안정화되려면 몇일 더 걸릴텐데 벌써 저정도 트래픽을 소화한다면 앞으로 큰 비용 절감이 기대됩니다.
CPU 쓸일이 전혀 없는 작업이라서요.
그런데 월 5불짜리 이정도 해주면 충분하죠. 저는 그냥 놀으라고 두고 있습니다.
음.. 제가 확인한바로는...
data/ 폴더 이하는 다 정상적으로 걸려 있던데요...
혹 어디를 말씀 하시는지 모르겠습닏.
아직 XE 쪽은 연결은 안했구요... 이건 모듈 만들어야 한다고 하셨고.
제가 날코딩한쪽은 모두 걸어둔 것은 아니지만.
말씀 하신 문제 풀이에 사용하는 부분은 모두 작업 마쳤습니다. 아마도 3-4시쯤 작업완료 된것 같은데.
혹시 누락 된곳 있으면 지적 부탁 드립니다.
data/ 이하 폴더만 걸어 놨습니다.
ps : 캐시 말씀 하셨군요..
파일명 뒤에...?숫자 붙는거 말씀이죠? ㅎㅎㅎ
그거는 파일이 수정될때마다 뒤에 판올림 번호 ?1 ?2 ?3 이런식으로 수작업으로 붙일수 있습니다.
현재 기능으로도 되구요.
?$mtime 같은것도 작동할수 있게 함수는다 만들어 놨습니다만..
매번 불필요하게 읽는감도 있고(DB 저장을 안해요 ㅎㅎㅎ)
(이미지 파일 요청 있을때마다.. 갱신하는거라서... DB랑 연동할려니깐 그것도 귀찮고 ㅎㅎㅎ)
그래서 일단 꺼놨습니다.
아마도 이거 말씀 하시는거 같네요. ㅎㅎ
수정이 되어야 붙어요 ?
//img.domain.com/cbt/data/bb/bb20180304/bb20180304m2.gif
이렇게 보여서 아직 적용 안하신거로 생각했네요.
수정될때 부터 된다면 문제는 없습니다.
하지만 아예 적용을 안하신다면 지난번 오랜 토론을 했던 문제를 그대로 가지고 시작하셨나 해서 좀 주제넘는 참견을 하게 되었네요.
아닙니다. ㅎㅎㅎ 그리 말씀 하시면 제가 더... ㅎㅎㅎ
앞서 말씀 해주신 변경되었을때 캐시 갱신을 위해서
변경시에 제가 수작업으로 파일명뒤에 ?숫자를 적는다고 했는데요.
토론때 나왔던 $mtime=$filetime("이미지파일명");
이미지파일명?$mtime 기능은 이미 만들어 두었습니다.
다만 이게...현재는
DB에는 이미지 파일명만 저장되어 있는 상태구요.
화면에 뿌려질때 PHP에서 매번 문제가 보여질때마다
$mtime=$filetime("이미지파일명");
이미지파일명?$mtime
이렇게 연산되는 불합리한 구조를 가지고 있습니다.
그거 연산에 얼마 CPU안먹는다고 말씀들 하시겠지만.
한푼이라도 아껴보고자 ㅎㅎㅎ
나중에 저걸 그냥 DB에 이미지 파일명 저장된걸
다 갈아 엎어서 자동으로 붙여 버리는걸 만들까도 생각중이고
(아마도 이게 지금 되었는지 궁금해 하시는것 같네요..)
다른 방식으로 어떻게 될수 있는게 있나 싶어서 약깐 고민중입니다.
토론때 나왔던 캐시 갱신 문제는 현재로써는 수작업이 더 편하고.
불필요하게 파일명 뒤에 숫자를 붙여서 전송량만 늘리는건가? 하는 생각도 하고
(사실 얼마 안되지만요)
아직은 생각중에 있습니다. ㅎㅎㅎ
ps : 파일명 수정이 있는 경우는 극히 드문 현상입니다.
성수기 기준으로 2-7일에 파일 1개정도.
비수기에 1달에 1개 수준입니다. ㅎㅎㅎ
아직 망설이고 있네요.
1. 수동으로 할것이냐.
2. 현재 만들어둔 어설픈 기능을 달것이냐..
3. 제대로 DB에 박아 넣을 것이냐..
4. 아님 다른 방식이 있느냐...
아직은 망설이는 중입니다.
주관적인 생각이겠지만 좀 예민하신 부분이..... 물론 이 부분 충분히 다른 반론으로 이야기 해주실 거 예상하고 있습니다.
제 개인적인 생각으로 그냥 받아주셔도 좋을 것 같습니다. 같은 문제로 함께 문제점과 그리고 대응법 등을 이야기했던 대화자 중의 한 사람이니까요.
처음 의문을 가지시고 질문을 하셨던 부분은 캐시를 사용함에 있어 제약을 받는 대표적인 문제입니다. 성능을 위해서 어쩔수 없는 선택을 하게 되었던 것이고 이로 인해 사용자들이 새로고침을 강력하게 하거나 혹은 사용자들에게 다른 주소로 다시 파일명을 고쳐 업로드해서 제공하거나 했던 것이구요.
그런데 이것은 굉장히 불합리하고 불편한 일이기 때문에 캐시부분에서만 ?1234 와 같은 것을 인식하여 새로운 파일로 인식하게 하는 방법이 표준적인 방법으로 제시되어 지금 널리 사용되고 있습니다.
굉장히 많은 곳에서 업로드된 파일명과 상관없이 2차 가공을 통해 ?1234가 붙도록 해서 하고 있습니다. 이로 인한 자원의 손실이요? 글쎄요. 저는 없다고 봅니다.
운영이야 운영자가 선택하는 것이고 하지만 저는 리소스손실 없이 방문자,운영자 모두 제일 좋은 방법인 방식을 일부러 회피하시는 듯 하다는 생각이 들었습니다.
입장 차이가 존재하는 부분에 제가 생각하는 방향의 의견을 전달해 드리다보니 다소 불쾌감이 드실 수 있다는 생각이 드네요.
2. 현재 만들어둔 어설픈 기능을 달것이냐..
추천 드립니다. 어설프다는 것은 동의하지는 않지많요. 많은 CMS에서도 회원을 특정하거나 하는 파일에 업로드시 회원번호로 픽스된 파일명으로 업로드가 되고 후처리로 타임스탬프를 붙여주는 replace 를 통해 방문자들에게 계속 갱신된 것을 즉시 적용되도록 하고 있습니다.
아참, 저희것 처음에 제가 한번 구글검색으로 한번 직접 해보려고 일부러 우분투 16.04 를 설치해서 시작했는데요. ssh에서 18.04로 그냥 업그레이드 해도 다른거 건드릴 필요 없이 사용 가능한가요??
브라우저 서버 상관없이 새로운 주소의 파일은 새롭게 다운로드 해서 캐시유지기간 까지 가지고 있다가 갱신합니다.
특정 페이지에서 abc.jpg 파일을 보여주는 코드가 있어 브라우저에서 abc.jpg 를 다운받았습니다. 서버에서 캐시만료를 1개월로 해서 브라우저는 저 파일을 1개월 동안 서버에 요청하지 않고 페이지가 열릴때마다 브라우저가 단말기의 파일을 보여줍니다.
자 그런데 지금 작성자가 파일명을 변경했다고 하셨습니다.
abc.jpg?1234
그럼 이전 파일은 잊으세요. 브라우저에서 계속 가지고 있는건 상관 없습니다.
왜냐면 바뀐파일(abc.jpg?1234)은 다시 브라우저에서 다운받고 화면에 뿌리니까요.
캐시를 자꾸 파일과 파일이 연관된다고 생각하시는 오류를 범하고 계십니다.
캐시때문에 갱신이 안되는 문제..
사실 다른 파일인데 파일명이 같은 파일이 같은 파일로 인식되어 이것을 파일명을 다르게 보여주어 해결하는 것 입니다.
캐시 기술이 일반화 되기 전에는 파일명이 같아도 매번 서버에서 받아갔기 때문에 항상 변경된 파일이 적용된거라 문제가 없었던 것 뿐입니다.
모두 별개의 파일입니다.
향후 기술이 좀더 발전하고 하드웨어 성능이 월등해지면 내려받은 파일들의 연관성 등을 분석해 대체된 파일인지 등까지 분석해 캐시만료 전에 파일들을 미리 삭제하는 방법도 나올 수 있겠지만 단말기의 저장공간 등의 가격 등을 볼때 지금 방식이 오래 유지될 가능성이 높지 않을까요? 그리고 대체인지 추가인지 확인할 방법이 없어 현실적로는 특수한 옵션으로 정해주기 전에는 브라우저 스스로 정할 수 없구요.
