Ver Mensaje Individual
  #4 (permalink)  
Antiguo 04/11/2003, 12:23
GreenEyed
 
Fecha de Ingreso: octubre-2003
Mensajes: 3.578
Antigüedad: 21 años, 2 meses
Puntos: 51
Hola,
Asi por puntos...:
.- Dividir las peticiones en servlets diferentes no implica un gran beneficio en rendimiento y si implica una carga importante en cuanto a mantenimiento. Los contenedores de servlets crean varias instancias de cada uno de ellos para servir las diferentes peticiones concurrentemente, asi que al fin y al cabo no ganas mucho. De hecho usar UN solo servlet se usa mucho y se conoce como la tecnica de "servlet controlador".
.- Crear una conexion en el init de un servlet y cerrarla en el destroy está totalmente desrecomendado. Ten en cuenta que el destroy lo puede llamar el contenedor CUANDO QUIERA y asi tendras abiertas siempre (4*20) 80 conexiones a BDD que ademas se reutilizaran dentro de un mismo servlet, por lo que habras de sincronizar el acceso a esa conexion en cada servlet... Yo te recomendaria usar un pool de conexiones.
.- En este tipo de aplicaciones, el motor de BDD no es lo de menos, si no que es muy muy importante. Seguramente sera el cuello de botella de tu aplicacion y tendras que optimizar el esquema de la BDD muy cuidadosamente (indices, etc...) y calibrar adecuadamente el numero de conexiones que tengas abiertas para no sobrecargarla.
.- Si el problema más importante que crees que te vas a encontrar es mucho tráfico, más que necesidad de evolucionar, flexibilidad, etc.. mis consejos serían: Mantén tu diseño sencillo y facil de depurar/controlar; especial cuidado en cuanto a la sincronización y el acceso a las conexiones de BDD y a la gestión y liberación de objetos; optimiza el accesso a la BDD y prevee un buen sistema de trazas por si las cosas van mal.
Al menos, eso es lo que a mi me ha ayudado en sistemas asi.
Suerte.
__________________
Para obtener respuestas, pregunta de forma inteligente o si no, pregunta lo que quieras que yo contestaré lo que me dé la gana.