Servidor web de alto rendimiento sin interactividad con la base de datos.

Servidor web de alto rendimiento sin interactividad con la base de datos.

Me estoy preparando para configurar un servidor que será responsable de rastrear datos estadísticos de una fuente de tráfico de gran volumen. Manejará solicitudes a aproximadamente 6-7 mil/hora en promedio, todas las cuales son GET pequeños. Todo lo que necesito es una configuración de servidor simple que pueda procesar los parámetros de la solicitud de obtención y escribirlos en un archivo CSV.

Lo primero que pensé fue usar lighttpd+fastcgi+php, ya que es una configuración con la que ya estoy familiarizado. Pero, dado que no puedo tomar este tipo de decisiones de rendimiento todos los días, me gustaría explorar otras opciones y ver si podría haber algo aún mejor para este propósito.

Respuesta1

Quiere realizar entre 6 y 7 millones de operaciones de escritura en un archivo CSV porhora?

En serio, una base de datos es una mejor idea. Una base de datos está diseñada para manejar escrituras simultáneas y se puede escalar verticalmente (máquina más grande, discos más rápidos) u horizontalmente (carga distribuida en varios servidores). Escribir en un único archivo CSV (ocualquierfile) requiere algún tipo de bloqueo para manejar problemas de concurrencia y escala mal a medida que aumentan la carga de E/S y la concurrencia.

Para solucionar esto, probablemente terminará implementando sus propias capas de almacenamiento en caché y buffer, luego comenzará a dividir la carga entre varios archivos, etc., etc. Utilice algún tipo de base de datos desde el principio y ahórrese muchos dolores de cabeza.

Respuesta2

Dado que vas a realizar alrededor de 2000 solicitudes/seg o 500 µs/solicitud enPROMEDIO(es decir, picos mucho más altos), los CSV probablemente no se puedan usar debido a entradas bloqueadas en escrituras simultáneas, ya que nada garantiza escrituras atómicas en sus archivos.

Una idea serían archivos por proceso/por escritor que se recopilan más adelante; otra idea sería utilizar una base de datos muy ajustada para grandes cantidades de escrituras. También puede echar un vistazo a las colas de mensajes o los protocolos de comunicación grupal (por ejemplo,Desparramar), pero no sé si aguantarán esa cantidad de volumen.

Hagas lo que hagas, presenta algunas ideas rápidas y compáralas. El hardware actual puede hacer maravillas con el rendimiento, optimizándolo sólo cuando sea necesario. En cuanto a PHP, asegúrese de tener instalado un caché de código de operación (p. ej.APC), de lo contrario estará quemando muchos ciclos en una recompilación innecesaria de los scripts.

También hay que tener en cuenta cómo se ve el crecimiento del servicio: no tiene mucho sentido aspirar a una solución que se verá superada en unos meses.

Respuesta3

¿Qué tipo de parámetros se pasan a través de la solicitud GET? ¿Es necesario que esté en CSV/Base de datos en tiempo real? ¿O cree que podría crear un archivo HTML ficticio (o PHP) y simplemente usar los registros web para analizarlos y volcarlos en un CSV más adelante como un trabajo por lotes? (Está bien... esto suena complicado... pero es fácil de manejar)...

Respuesta4

Echaría un vistazo a la edición web del servidor 2008 y usaría ADO.net para escribir en el archivo CSV. No debería tener problemas de rendimiento ya que ado.net almacenará en búfer las escrituras.

información relacionada