Buenas,

Tenemos un cliente que viene de utilizar HP-UX con PostgreSQL con aparentemente una interfaz en PHP y MySQL (?), ahora bien, la empresa de hosting donde trabajo brinda interpretes para varios lenguajes (ASP, .NET, Perl, PHP y RoR entre otros), pero no JAVA, lenguaje con el cual labura todo el sistema administrativo del cliente (es un banquito). Todavia desconozco si quieren renovar y transferir la licencia de HP-UX al housing, pero en el caso de que no sea asi (lo mas posible):

Si bien se algo de programacion en Java, nunca llegue a hacer funcionar un Apache Tomcat (aunque intente hace un año aproximadamente), asi que no se que tan estable se encontrara hoy en dia para hacer un deployment sobre algun UNIX/Linux. De todas formas mi pregunta apuntaba un poco tambien a si era una alternativa viable utilizar OpenSolaris y Sun Java System Web Server (que tambien soporta PHP por fastCGI) con el UNIX/Linux de turno.

Muchas gracias por la ayuda.

Tomcat es un fierro, muchísimas empresas lo tienen en producción sin problemas.
Sun Java System Web Server nisiquiera sé lo que es.

Sun Java System Web Server esta basado Glassfish una version vieja igual si bien recuerdo.

Si van a hacer PHP en el mismo application server que van a correr java, yo usaria Resin + Quercus y no tomcat.
http://www.caucho.com/

Por otro lado, si tienen un hosting y tienen ubuntu server o debian, tomcat es parte "soportada" de los repositorios lo que implica que casi que te olvidas del mantenimiento que le tenes que dar.

Igual todavia no entiendo para que quieren correr php en un servidor java a menos que sea para escalar mejor, pero por lo que decis no son muy grandes asi que no se si eso es porque lo hacen.

O por ahi no entendi un joraca de lo que estas diciendo porque no le encuentro mucho sentido

caucho

A mi tampoco me quedo claro, por un lado comentas que la interfaz es PHP, pero mas adelante comentas que el sistemita administrativo esta en Java.

Contanos un poco como viene esta mezcla, asi te podemos dar un par de tips mas.

A nivel productivo, tomcat esta super maduro, es super escalable, y a mi personalmente me gusta mas que el SWS de Sun, y he visto con mis propios ojos aplicaciones criticas en produccion con clusters de tomcats para empresas desubicadamente grandes como Ford, Electronic Arts, Endesa, Sony, Nike, etc.

Si entendi bien lo que planteaste, y son dos sistemas separados, podes migrar la parte PHP a un caucho, y la parte Java a un tomcat o jboss.

Disculpen, pero ni siquiera el cliente lo tiene claro, (todavia no concretamos la entrevista con su equipo de programadores), como consecuencia, nosotros tampoco terminamos de comprender todavia que es lo que quiere.

Al parecer la interfaz web "del portal" funciona en PHP y MySQL, y cuando se ingresan datos privados, los mismos ya pasan a un sitio con IP con SSL que funciona en Java.

Mi consulta se resume a que servidor web me recomiendan usar como interprete de PHP y Java (o por separado), pero en particular para con Java: Apache Tomcat, RHEL con JBoss (tenemos licencia de RHEL), u OpenSolaris con Sun Java System Web Server.

La idea seria utilizar un sistema operativo como RHEL (en el caso de que usemos JBoss), OpenSolaris (en el caso de que hagamos uso de Sun Java System Web Server, con posibilidad de migrar a Solaris 10 algun dia), HP-UX si el cliente renueva su licencia, o algun FreeBSD o Debian Etch con Apache Tomcat.

Nuevamente, gracias por adelantado.

Tb, a menos que uses el jboss que se baja de jboss.org, tenes que pagar una subscripcion de soporte para usar el jboss-eap que el "soportado".
O usar tomcat 5.5 desde los repositorios de rhel que viene incluido con la distribuicion.

Es claro que sin la info (que todavia no tenes) es practicamente imposible darte una buena recomendacion. Avisa cuando hables con la gente aunque sea para ver qué es lo que estan haciendo.

Podes usar un Apache HTTPd + mod_worker + mod_fastCGI + PHP + mod_proxy(o mod_proxy_ajp) + mod_rewrite + Tomcat

De esa forma podes tener bajo el mismo dominio PHP (via fastCGI) y java (usando un proxy apuntado localmente o a otra maquina).

Digo de usar el mod_worker + fastCGI y no el mod_prefork + mod_php para que no levante en cada thread que va para el tomcat los 8MB (minimo) que necesita php.

Con el mod_proxy + mod_rewrite mapeas los paths (todo un subpath o usando una expresion regular) que necesites para que vayan al tomcat.

pero el mod_php porque iria para el tomcat? el mod_php directamente ejecutaria el PHP, y se supone que php corre mejor como modulo que como cgi, y si de php hay requests para la aplicacion en java, esos requests irian primero al apache y de ahi al tomcat

lo que iria al tomcat, es lo que detectaria el apache que lo mandaria con mod_proxy, pero PHP quedaria dentro del mod_php

te consulto de curioso y para ver donde me equivoco

Antes que anda esto que pongo a continuación es valido para linux.

A pesar que digan que si, PHP no es thread safe. El core si, pero algunas librerías no lo son. Por eso las distros de linux cuando uno activa el mod_php no te deja elegir otro MPM que no sea el prefork (una proceso de apache forkeado por cada request).

Cuando cargas PHP en Apache como modulo (mod_php) y prefork, cada proceso que corras lo hace levantando el interprete PHP, que a su vez carga todas las librerias de PHP que esten en el php.ini (que no es poca memoria).

Una vez que se usa (un request), el proceso no se mata porque es muy costoso crearlo y tirarlo todo el tiempo. O sea, despues del request PHP, te piden una imagen , un CSS, un js o un request al tomcat (via el mod_proxy) y esa memoria (estamos hablando de 8MB minimo) sigue estando en cada proceso.

Ponele que empieces a tener varios requests, la memoria se va a los caños.

Usando mpm-worker + fastCGI (si, es un poco mas lento) vos tenes N procesos y M threads por proceso. Ninguno carga PHP con lo que podes servir 10 o 15 veces mas requests con la misma memoria. El FastCGI carga y queda en memoria un pool de instancias PHP que hacen falta y despacha cuando es necesario.

excelente la explicacion, me sirvio de mucho, gracias

Gracias por las respuestas. Como el cliente ya abono en parte voy a empezar a hacer las pruebas por mi mismo, aunque todavia no tengamos en claro como es su sistema.

Primero voy intentar JBoss sobre RHEL, pero lei que JBoss no era gratuito, asi que vamos a ver que pasa.
En segunda instancia, y mas que nada por curiosidad, voy a probar OpenSolaris con Sun Java System Web Server.
Y finalmente, el deployment que probablemente utilicemos, un Debian Etch con Apache Tomcat.

no, el jboss que bajas jboss.org es gratuito, pero no es soportado.