게시물을 제출할 때 배열이 너무 크면 다음과 같은 문제가 발생할 수 있습니다.
<code>Unknown: Input variables exceeded 1000. To increase the limit change max_input_vars</code>
해결책: php.ini를 열고 매개변수를 수정합니다.
max_input_vars = 1000;
기본값 1000을 더 큰 값으로 변경합니다.
간단한 질문처럼 들리네요. 하지만 게시물 요청 사용자를 수신하고 서버 환경이 다양하다면 서비스를 사용하는 모든 사람이 이 매개변수를 변경하도록 할 수는 없습니다.
그래서 먼저 json_encode와 base64로 post 배열을 처리했습니다. 매개변수로 봉인되어 있었는데, 서버가 이 배열을 파싱하는 데 0.3초가 걸렸습니다. 이전보다 비용이 100배 더 들었습니다. 이것은 여전히 부적절하다고 느껴집니다. 그리고 memory_limit가 너무 작게 설정되면 메모리 부족 메시지가 표시됩니다.
두 옵션 모두 단점이 있습니다.
당신이라면 이 문제를 어떻게 해결하시겠습니까?
게시물을 제출할 때 배열이 너무 크면 다음과 같은 문제가 발생할 수 있습니다.
<code>Unknown: Input variables exceeded 1000. To increase the limit change max_input_vars</code>
해결책: php.ini를 열고 매개변수를 수정합니다.
max_input_vars = 1000;
기본값 1000을 더 큰 값으로 변경하세요.
간단한 질문처럼 들리네요. 하지만 게시물 요청 사용자를 수신하고 서버 환경이 다양하다면 서비스를 사용하는 모든 사람이 이 매개변수를 변경하도록 할 수는 없습니다.
그래서 먼저 json_encode와 base64로 post 배열을 처리했습니다. 매개변수로 봉인되어 있었지만 서버가 이러한 배열을 구문 분석하는 데 0.3초가 걸렸습니다. 이전보다 비용이 100배 더 들었습니다. 이것은 여전히 부적절하다고 느껴집니다. 그리고 memory_limit가 너무 작게 설정되면 메모리 부족 메시지가 표시됩니다.
두 옵션 모두 단점이 있습니다.
당신이라면 이 문제를 어떻게 해결하시겠습니까?
저는 두 번째 옵션인 json 전송을 선택합니다.
우선 json 파싱이 포스트 파싱보다 0.3초 느리다는 것을 어떻게 계산했는지 모르겠습니다. 즉, 포스트 파싱에 걸리는 시간을 어떻게 알 수 있나요?
두 번째로, 양식 데이터에 비해 json 형식은 사용자 정의가 더 용이하고 목록, 개체 등에 대한 지원이 더 좋습니다. 이러한 기능을 잘 활용하면 전송되는 데이터의 크기를 크게 줄일 수 있습니다.