2010-01-05 11 views
16

¿Hay alternativas a PHP que funcionen más rápido y que tengan el mismo conjunto de características (como compatibilidad con RDBMS comunes, Curl, Regex, etc.)?¿Alternativas PHP?

¿Qué hay de la codificación de sitios web en C? ¿Cómo funciona eso? ¿Es esa plataforma independiente y funciona en cada servidor?

+7

Quizás deba indicar qué problemas tiene (si corresponde) con PHP – Rad

+1

Por lo general, el cuello de botella está en espera de la base de datos. Haga un perfil de su aplicación/sitio también para ver qué lo detiene. –

+0

Debería indicar qué problemas tiene con PHP. Y mire qué técnicas agnósticas de lenguaje se usan para mejorar el rendimiento de la aplicación web: http://developer.yahoo.com/performance/ – igouy

Respuesta

8

"¿Hay alternativas a PHP" - Sí

"... que llevan a cabo más rápido ..." - Sí

"... el mismo conjunto de características ..." - No, eso haría que PHP sea redundante.

Hace una pregunta muy amplia. Hay muchos idiomas que admiten todo tipo de DBMS, PCRE y otras cosas también.

"¿Qué pasa con la codificación de sitios web en C? ¿Cómo funciona eso? ¿Es independiente de esa plataforma y funciona en cada servidor?"

  • No, no es una plataforma independiente.

Es bastante difícil indicarle una dirección específica basada en una pregunta tan amplia.

Es posible que desee leer esto:

http://benchmarksgame.alioth.debian.org/

Pero tenga en cuenta que la mayor parte del costo del software radica en el desarrollo - El hardware es barato - así que la posibilidad de aplicar algo de la mitad de las líneas de código se ser enormemente más beneficioso para la mayoría de las personas que duplicar el rendimiento.

También existen limitaciones y/o ventajas menos obvias al utilizar idiomas específicos, p. Ej.

http://www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_switched_back_to_p_1.html

C.

+11

Urk, odio ese artículo. "7 razones por las que vuelvo a PHP" se presenta constantemente como un tipo de ataque a Rails, cuando no lo es, es una demostración de la ignorancia del autor. Sus primeras palabras son "Pasé dos años tratando de hacer que Rails hiciera algo que no estaba destinado a hacer ...". El resto del artículo podría ser reemplazado por "... así que soy un poco idiota por perder 2 años". – meagar

+1

"Es posible que desee leer esto", particularmente "Rendimiento general: PHP rara vez es el cuello de botella (diapositivas HTML)" http://talks.php.net/show/drupal08/7 :-) – igouy

+2

Downvoted su "No, no es plataforma independiente "respuesta, porque eso depende principalmente de ** cómo ** se integra con el servidor HTTP. – magnus

17

Tu pregunta es amplia.

  • PHP se puede hacer rápido y escalable (Flickr, Facebook y más sitios corren PHP)

  • algo similar en fin son webframeworks como Ruby on Rails, Django, Ascensor, ... (que pueden escala, también, véase, por ejemplo Twitter)

  • Una breve introducción en CGI en C: http://www.cs.tut.fi/~jkorpela/forms/cgic.html

+0

Corrección muy leve: * las aplicaciones * compilar en PHP se pueden hacer rápidamente, esto es cierto, pero el lenguaje en sí mismo, por naturaleza, no puede hacerse "rápido", o al menos no en el sentido de que los idiomas del sistema (C, C++, Go, etc.) son rápidos. El lenguaje en sí mismo se basa en tiempos de ejecución escritos en un lenguaje de sistema y/o servicios externos (DBMS, etc.) también (en su mayor parte) escritos en un lenguaje de sistema, para cualquier cosa de importancia crítica. –

6

PHP se conecta directamente en Apache.

C no lo hace. Para conectar C con Apache, tendrá que usar alguna implementación CGI segura/rápida en lugar de la CGI estándar.

C - como lenguaje - es mucho trabajo para construir sitios web.

Mira los marcos web en Python.

Mire Ruby on Rails.

+2

Realmente no respondió la pregunta y cierta información es incorrecta. C * does * se integra directamente con Apache a través de los módulos de Apache. Por ejemplo, mod_rewrite, mod_env, etc., etc. C * también * integra ** indirectamente ** para CGI/FastCGI/SCGI/etc como usted mencionó. – magnus

8

Perl (CGI)

Python

RoR (carriles en Rubí)

ASP (No es la mejor opción)

Bastante seguro de si vas a codificar un sitio web en C su va a codificar tu propio servidor web también así me mantendría alejado de eso.

RoR sería una buena opción. Pero solo depende de tus preferencias personales. Tiendo a quedarme con php ya que sé cómo hacer prácticamente todo en PHP.

1

Si su problema es una página web o una aplicación web que parece demasiado lento, el cambio de idioma es probable que no vale la pena el esfuerzo. Hay formas mucho más eficientes de acelerar las cosas. Uno de ellos sería el almacenamiento en caché de código para evitar la sobrecarga de una nueva compilación de sus scripts PHP en cada solicitud de página. Ver por ejemplo http://en.wikipedia.org/wiki/PHP_accelerator. Personalmente he usado XCache con gran efecto.

Existen muchas otras razones para que los sitios web rindan más lento de lo que podrían, muchos de los cuales no están relacionados con el idioma subyacente. YSlow (http://developer.yahoo.com/yslow/) es una herramienta indispensable para encontrar su cuello de botella. Para dar un solo ejemplo, la combinación de múltiples archivos CSS o JS incluidos desde una página HTML en un único archivo puede mejorar drásticamente los tiempos de respuesta.

Por lo tanto, en conclusión: en la mayoría de los casos, el idioma subyacente no es el culpable. Habiendo dicho todo eso, sí, hay idiomas más rápidos. Ver las otras respuestas anteriores :)

+1

Sí. Echa un vistazo a HipHop PHP, compila PHP en código C para un 50% de aumento en el rendimiento. – Rolf

9

Si te gusta Javascript se puede usar en el lado del servidor con Node.js

3

¿Qué pasa con los sitios web de codificación en C? ¿Cómo funciona eso? ¿Es esa plataforma independiente y funciona en cada servidor?

Escribir código independiente de la plataforma en C es bastante posible. (PHP está escrito en C, y hay una cantidad ridícula de programas y bibliotecas multiplataforma escritos en C, como PostgreSQL y MySQL, Boost y Poco C++).

plataforma de escritura independiente aplicaciones web, por otro lado, depende principalmente de cómo se integre con el servidor HTTP. Por ejemplo, si escribe una aplicación C que integra directamente con el servidor HTTP a través de un módulo compilado (para Apache o IIS), terminará con menos código portátil, por ejemplo, escribiendo un módulo IIS en C o Delphi (que he visto hacer, y que eBay originalmente hizo) significa que no solo está bloqueado en Windows sino que también está bloqueado en IIS en Windows. La situación es similar cuando se escriben módulos Apache en C.

Pero si escribe una aplicación web en C que integra a través de un estándar común con el servidor HTTP, entonces sí, puede tener un código bastante portátil (aunque el código tiene que ser compilado en cada plataforma). Por ejemplo, puede usar CGI para comunicarse con el servidor HTTP usando variables de entorno, o puede usar los estándares relacionados, FastCGI y SCGI. De nuevo, he visto esto hecho en aplicaciones prácticas y comerciales (tanto para buenos efectos como para mal efecto).

El debate sobre las aplicaciones web nativas (por ejemplo, escritas en C, C++ y similares) frente a las aplicaciones web interpretadas (PHP, Perl, etc.) suele centrarse en tres áreas.

  • Código de rendimiento. A menos que esté escrito por un mono con muerte cerebral que no consiguió el trabajo para escribir las cookies de la fortuna, el código C siempre superará a PHP. Sin embargo, el cuello de botella en su aplicación puede no estar relacionado con la velocidad y el consumo de memoria del código, sino más bien con las rutinas de entrada/salida.
  • Productividad del desarrollador. A menos que utilice un buen marco de trabajo (y parte de su pregunta fue sobre conjuntos de características de otros idiomas) va a escribir un montón de caldera, un código repetitivo. Por ejemplo, decodificar URL codificadas por porcentaje, analizar datos HTTP POST, etc. Existen marcos para esto en C y C++ (ver CppCMS).
  • Portabilidad, como usted ha mencionado. Si no está seguro de escribir una aplicación web en C, me quedaría con CGI o SCGI.