питон лаг CGI Аякса

им с помощью питона скрипт для отображения текста на экране с помощью AJAX, но это лага, а иногда даже не работает ..питон лаг CGI Аякса

вот питон скрипт

#!/usr/bin/env python 
import cgi, cgitb 
form = cgi.FieldStorage() 
q = form.getvalue('q') 
print "Content-Type: text/html\n" 
print q

и HTML

<!DOCTYPE html> 
<html> 
<head> 
    <script type="text/javascript"> 
     function show(str){ 
      var xmlhttp; 
      if (str.length == 0){ 
       document.getElementById("hint").innerHTML = ""; 
       return; 
      } 
      if(window.XMLHttpRequest){ 
       xmlhttp=new XMLHttpRequest(); 
      } 
      else{ 
       xmlhttp=new ActiveXObject("Microsoft.XMLHTTP"); 
      } 
      xmlhttp.onreadystatechange=function(){ 
       if (xmlhttp.readyState==4 && xmlhttp.status==200){ 
        document.getElementById("hint").innerHTML=xmlhttp.responseText; 
       } 
      } 
      xmlhttp.open("GET","../cgi-bin/ajax_test.py?q="+str,true); 
      xmlhttp.send(); 
     } 
    </script> 
</head> 
<body> 
    <form action=""> 
     <input type="text" id="txt1" onkeyup="show(this.value)" /> 
    </form> 
    <span id="hint"></span> 
</body>

это вина моего кода в? или это потому, что cgi/python работает медленно?

источник

2012-06-04 ehsangh

Вы наблюдаете какие-либо задержки при повторном вызове 'ajax_test.py' непосредственно в браузере? – georg

@ thg435 Не могу сказать. Кажется, это делается сразу после того, как страница загружена, но я не могу быть уверен. – ehsangh

Хотя ваш пример отлично подходит для меня на локальном сервере Apache Apache, я бы предположил, что использование CGI python в качестве внутреннего решения для обслуживания вызовов ajax было бы крайне неэффективным. Сама природа CGI означает, что каждый отдельный запрос должен порождать процесс этого сценария python.

http://en.wikipedia.org/wiki/Common_Gateway_Interface

Вызов команды обычно означает вызов вновь созданного процесса на сервере. Запуск процесса может потреблять гораздо больше времени и памяти, чем фактическая работа по генерации вывода, особенно , когда программа все еще нуждается в интерпретации или компиляции. Если часто вызывается команда , полученная рабочая нагрузка может быстро перегрузить веб-сервер.
Накладные расходы, связанные с интерпретацией, могут быть уменьшены с использованием скомпилированных программ CGI, таких как C/C++, а не с использованием Perl или других языков сценариев. Накладные расходы, связанные с созданием процесса , могут быть уменьшены с помощью таких решений, как FastCGI, или , выполняющих код приложения полностью на веб-сервере с использованием модулей расширения , таких как mod_php.

В то время как он может функционировать нормально, на месте, только когда вы проводите тесты, это будет значительно больше влиять, когда вы сделаете это публичным обращением, с несколькими клиентами, подключающимися.

wsgi (или, по крайней мере, fastcgi) - далеко превосходящий подход к сценариям старой школы CGI. Вы можете использовать mod_wsgi, если используете apache. Существует также uwsgi, gunicorn, и многие другие подходы я уверен. В конечном итоге идея состоит в том, что вместо того, чтобы иметь отдельный сценарий, который вызывается для каждого запроса, у вас есть постоянный процесс, который выполняется, принимает запросы и выполняет функции.

В эти дни я думаю, что люди просто используют CGI-модуль python в качестве учебного шага для написания веб-кода на стороне сервера через python. Возможно, вам захочется рассмотреть возможность перехода к структуре.

источник

2012-06-04 21:51:52 jdi

При использовании python как cgi, для каждого запроса необходимо запустить новый python iterpreter для обработки запроса, который, естественно, включает некоторые накладные расходы для создания процесса.

Поскольку вы отправляете новый запрос для каждого события keyup, в фоновом режиме может быть запущено много процессов. Вероятно, было бы лучше поймать событие change вместо этого или отправить запрос только при нажатии на возврат.

Другое, тогда было бы лучше использовать wsgi вместо cgi для запуска вашего скрипта, поскольку это позволяет избежать перезапуска интерпретатора по каждому запросу.

источник

2012-06-04 21:56:55 mata

Это хорошее предложение об управлении при отправке запроса ajax. Я бы предположил, возможно, используя задержку (в отличие от возврата), туда, где она будет срабатывать только после того, как она не изменилась за N миллисекунд. Я делаю это в некоторых своих собственных графических интерфейсах для полей, генерирующих триггеры. – jdi

Цель состоит в том, чтобы использовать скрипт для поиска базы данных sqlite и отображения предложений. Похоже, wsgi - это путь. Благодарю вас обоих за вашу помощь. – ehsangh

питон лаг CGI Аякса

ответ

Смежные вопросы