Re: FW: very off topic marketing question
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jonathan,
On 3/20/2009 7:53 PM, Jonathan Mast wrote:
Meh. Most Java webapps aren't multithreaded anyway in the sense that
each request lives in its own little world and usually runs start to
finish with no other threading involved.
Just this week I added threading to a component of my web-app. I had some
what dreaded it, but found that it took me only a half-hour and about 10
extra lines of code, here's a synopsis:
Thread t = new Thread(new Runnable() {
public void run() {
...blast()
}
}, Blast Thread);
t.start();
Where blast() iterates thru several thousand records, which are sent to a
third-party site for processing. The third-party site allows no more than 5
connections per second, so I just call Thread.sleep(1000) on every 5th
record.
It is very simple, very elegant and very fast now that some much load has
been moved off the main http thread.
I would argue that, architecturally, this kind of work doesn't belong in
the request processing portion of the application. I generally do this
kind of thing with cron jobs. Otherwise, you can have HTTP requests
kicking-off lots of long-running processes. That may be possible in
Java, but I'm not sure it's always advisable.
On the other hand, a background thread (in the same JVM) that serially
processes some jobs scheduled by request processors (say, like sending
an email message) is often a good idea. Just as long as you don't run
new Thread().start() during request handling, which is a bit scary.
My question is: how would this be accomplished in PHP? Would I need to
recompile the whole php server with a special thread package or what?
I have no idea. I wasn't saying that you can do that in PHP (or, at
least, you can't fire-off background threads during request
processing)... I was saying that you shouldn't do that in /any/
language, so the fact that PHP can't do it isn't really that relevant.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAknI+3sACgkQ9CaO5/Lv0PD+nwCgsCnQrQmKxAZQEN3wVap5Knxz
zr0AoLKsUjDYMvCWQMxRb2Pe8ib/r88L
=O3Ls
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: FW: very off topic marketing question
I would argue that, architecturally, this kind of work doesn't belong in
the request processing portion of the application. I generally do this
kind of thing with cron jobs. Otherwise, you can have HTTP requests
kicking-off lots of long-running processes. That may be possible in
Java, but I'm not sure it's always advisable.
True, in general, but not just any HTTP request can spawn this thread. The
component is invoked via a GUI that is secured, so only someone with the
appropriate credentials can start the blast. Furthermore the component has
additional sanity-checks just in case someone tries spawning multiple
threads (which would break the constraint on per second requests).
Also the processing this thread does is episodic, not regular, so if I
couldn't invoke it via the management GUI, then i'd have to log into the
server and execute a bash scriptor some other one-off kludge thats slap-dash
and hard to maintain :-(
On Tue, Mar 24, 2009 at 11:25 AM, Christopher Schultz
ch...@christopherschultz.net wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jonathan,
On 3/20/2009 7:53 PM, Jonathan Mast wrote:
Meh. Most Java webapps aren't multithreaded anyway in the sense that
each request lives in its own little world and usually runs start to
finish with no other threading involved.
Just this week I added threading to a component of my web-app. I had
some
what dreaded it, but found that it took me only a half-hour and about 10
extra lines of code, here's a synopsis:
Thread t = new Thread(new Runnable() {
public void run() {
...blast()
}
}, Blast Thread);
t.start();
Where blast() iterates thru several thousand records, which are sent to a
third-party site for processing. The third-party site allows no more
than 5
connections per second, so I just call Thread.sleep(1000) on every 5th
record.
It is very simple, very elegant and very fast now that some much load has
been moved off the main http thread.
I would argue that, architecturally, this kind of work doesn't belong in
the request processing portion of the application. I generally do this
kind of thing with cron jobs. Otherwise, you can have HTTP requests
kicking-off lots of long-running processes. That may be possible in
Java, but I'm not sure it's always advisable.
On the other hand, a background thread (in the same JVM) that serially
processes some jobs scheduled by request processors (say, like sending
an email message) is often a good idea. Just as long as you don't run
new Thread().start() during request handling, which is a bit scary.
My question is: how would this be accomplished in PHP? Would I need to
recompile the whole php server with a special thread package or what?
I have no idea. I wasn't saying that you can do that in PHP (or, at
least, you can't fire-off background threads during request
processing)... I was saying that you shouldn't do that in /any/
language, so the fact that PHP can't do it isn't really that relevant.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAknI+3sACgkQ9CaO5/Lv0PD+nwCgsCnQrQmKxAZQEN3wVap5Knxz
zr0AoLKsUjDYMvCWQMxRb2Pe8ib/r88L
=O3Ls
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
FW: very off topic marketing question
Number of users is not the only one thing, you need to think about, when you are choosing technology. PHP is a _scripting_ language with out of _static typization_, multi-threading, full OOP support and its API is pretty weak too. Also it is _not_ designed for servlet ideology: each request runs script from the very beginning. You can use fast_cgi, but sometimes it is painfull procedure too. But it is fast and easy-to-use. Apache + PHP may run on P-166/64 RAM/FreeBSD serving phorum for ~ 100 users with out of troubles. Programs are small too, like in all scripting languages. If you are going to move to php, be ready to: 1) loose tools like log4j. 2) meet API, 10% of which uses OOP and exceptions, and 90% is procedure / errors based. 3) you would not have namespaces. 4) because of dynamic typization, you would be able to find some types of errors only in runtime. 5) no multithreading etc... -Original Message- From: Jason Pyeron [mailto:jpye...@pdinc.us] Sent: Friday, March 20, 2009 6:04 PM To: 'Tomcat Users List' Subject: very off topic marketing question I have a client that is confused why we are giving them a J2EE product and they are concerned with performance and scalability. (IE/Tomcat 5.5/struts 2.1/hibernate 3.x/oracle 10g) Note the system will never see more than 50 users/sessions with 7500 hits per day on a lan. As such we don't see any relevance as to the performance and scalability issues for either PHP or J2EE. They have quoted to us: PHP by itself is very fast. Much faster than ASP or JSP running on the same type of server. This is because it has very little overhead compared to its competitors and it pre-compiles all of its code before it runs each script How would others respond to this? -Jason -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: FW: very off topic marketing question
Just ask them to google for security-issues linked to PHP and issues linked to any servlet-container (aka Tomcat). If they want it more specific, ask them to read through some relevant mailing-list-archives such as full-disclosure. OK, that's not about performance, but we f.e. do not use PHP due to it's security-footprint. Sure, if one know his ways arround in PHP and know the sources of every module used in PHP and has checked them for any security-concern, it may work - however: I've never met such a person... Rgds Gregor -- just because your paranoid, doesn't mean they're not after you... gpgp-fp: 79A84FA526807026795E4209D3B3FE028B3170B2 gpgp-key available @ http://pgpkeys.pca.dfn.de:11371 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: FW: very off topic marketing question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ilya, Don't get me wrong... I loves me some Java. But... On 3/20/2009 11:55 AM, Ilya Kazakevich wrote: If you are going to move to php, be ready to: 1) loose tools like log4j. log4p? 2) meet API, 10% of which uses OOP and exceptions, and 90% is procedure / errors based. This does really suck. It's going back and using C when you've become sooo used to exceptions. 3) you would not have namespaces. Meh. I suppose on a large (huge?) project this could be a problem. You can always namespace your files by using subdirectories. Oh, wait. You weren't suggesting that you use objects in PHP were you? Ha ha ha ha. Oh, maybe you were. Sorry. 4) because of dynamic typization, you would be able to find some types of errors only in runtime. Java is not safe from runtime errors; they're just (mostly) not the kinds of errors that can be prevented using static type-checking. I've come-around on this one: static typing is just one way of doing things. Ruby's mix-ins are very attractive for those of us who have had trouble breaking-into a class hierarchy. :) 5) no multithreading Meh. Most Java webapps aren't multithreaded anyway in the sense that each request lives in its own little world and usually runs start to finish with no other threading involved. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAknEAZ0ACgkQ9CaO5/Lv0PA66ACfYgElGkBrKzxS2Lp9ABhW9ZZU UDgAn0eFpdBXzUCcda4G2LOE5733XSgL =X7eW -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: FW: very off topic marketing question
Meh. Most Java webapps aren't multithreaded anyway in the sense that
each request lives in its own little world and usually runs start to
finish with no other threading involved.
Just this week I added threading to a component of my web-app. I had some
what dreaded it, but found that it took me only a half-hour and about 10
extra lines of code, here's a synopsis:
Thread t = new Thread(new Runnable() {
public void run() {
...blast()
}
}, Blast Thread);
t.start();
Where blast() iterates thru several thousand records, which are sent to a
third-party site for processing. The third-party site allows no more than 5
connections per second, so I just call Thread.sleep(1000) on every 5th
record.
It is very simple, very elegant and very fast now that some much load has
been moved off the main http thread.
My question is: how would this be accomplished in PHP? Would I need to
recompile the whole php server with a special thread package or what?
On Fri, Mar 20, 2009 at 4:50 PM, Christopher Schultz
ch...@christopherschultz.net wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ilya,
Don't get me wrong... I loves me some Java. But...
On 3/20/2009 11:55 AM, Ilya Kazakevich wrote:
If you are going to move to php, be ready to:
1) loose tools like log4j.
log4p?
2) meet API, 10% of which uses OOP and exceptions, and 90% is procedure /
errors based.
This does really suck. It's going back and using C when you've become
sooo used to exceptions.
3) you would not have namespaces.
Meh. I suppose on a large (huge?) project this could be a problem. You
can always namespace your files by using subdirectories. Oh, wait. You
weren't suggesting that you use objects in PHP were you? Ha ha ha ha.
Oh, maybe you were. Sorry.
4) because of dynamic typization, you would be able to find some types of
errors only in runtime.
Java is not safe from runtime errors; they're just (mostly) not the
kinds of errors that can be prevented using static type-checking. I've
come-around on this one: static typing is just one way of doing things.
Ruby's mix-ins are very attractive for those of us who have had trouble
breaking-into a class hierarchy. :)
5) no multithreading
Meh. Most Java webapps aren't multithreaded anyway in the sense that
each request lives in its own little world and usually runs start to
finish with no other threading involved.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAknEAZ0ACgkQ9CaO5/Lv0PA66ACfYgElGkBrKzxS2Lp9ABhW9ZZU
UDgAn0eFpdBXzUCcda4G2LOE5733XSgL
=X7eW
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
