During our searches for better ways to scale drupal, we stumbled upon Caucho Resin, a Java servlet container that provides a native Java based PHP5 interpreter. Resin can run as a replacement for Apache or lighttpd, or can work in cooperation with an httpd server.
Caucho provides a Java-based PHP interpreter. What does that mean? Well, unlike Apache, which uses an embedded PHP interpreter called mod_php, or LightHTTPD which uses fastcgi, Resin is running as a drop in replacement for the server, so there is no external module. PHP runs as a Java servlet inside of a Resin container, and for the first time seems to deliver consistent, working, multi-threaded PHP (there is experimental support for multithreaded php - read this and this to become instantly knowledgable - bear in mind that "global" and thread and session specific tend to be totally different concepts in Java and PHP, for example there is no way to be "global" in the servlet spec, only global to the servlet instance inside of the application server, so multi-threading gets complicated really quickly. When you run php in Java, how do statics behave for example?).
The interpreter only has to be started once, as opposed to a new interpreter for each request as you would with a web server (either mod_php or fcgi), which provides a shorter round trip, less memory consumption, and in theory, insanely fast performance.
Jonathan and I have been watching for this technology for a long time, and I think we've finally found it!
So, to give you an idea of what kind of performance, Caucho's site claims 4x improvements over standard mod_php with many applications, including Drupal.
So, we decided to use some of the machines in our lab to try this out. Seems like a good idea, no?
Well, I'll be damned if they weren't correct. Here are the results:
Preliminarily, and we would appreciate it if we could get some external verification, it looks like Resin is performing almost 3.5 to 4 times faster for a stock Drupal install than apache with no caching enabled and the same hardware.
We ran our own benchmarks against the following hardware:
We benchmarked three different configurations on the same hardware and against the same database using stock configurations for all software.
The configurations:
The test case consisted of running multiple requests to our test server with the path '?q=node/1' as a logged in user (PHPSESSID cookie set) using Jakarta JMeter. For each of five different concurrent thread counts (1, 2, 5, 10, and 20, respectively), we sampled the total number of requests per second driven by each of the test cases.
The only downside we've seen so far: Configuration of rewrite rules is difficult, which means that clean URLs in Drupal will be problematic. We might need a Drupal bounty for this one.
More information on this is to come. We're definitely going to be doing further investigation, and have already been in touch with the deveopers. We'll be talking more extensively with Caucho and asking them how they did it, why it works, and what kinds of drawbacks we might be looking at.
This looks promising, folks. Stay tuned.
aaron's blog
Comments
Hrmmm...
The first thing that came to mind was WOW! Then a few more thoughts passed through my mind...
The web server is rarely the performance issue for Drupal in my experience. On average it's DB that can't handle the requests. I see the benefit for a system that has issues on the front tier but let's find a killer solution for the backend....PLEASE!
I'm still working on a few ideas and will post them soon.
Cheers,
-p
backend solutions
I have three backend solutions I'm pending introducting for the Drupal community. In fact, I have one hardware, one software, and one hybrid based on cluster that we've been working intensively with.
More to come on the backend once we get the number together and find the time to run the benchmarks in a semi-defensible fashion.
The master slave split for reads and writes was introduced on the Drupal infrastructure list, and you should totally help contibute to that cause I know you're a rocking good coder, and we need help getting that rolled out to Drupal.org.
Ping me if you have time.
Best,
Jonathan
It's faster by design.
Quercus compiles PHP files to JVM class files, which are then able to benefit from the JVM's JIT compiler and optimizer. The PHP applications run in the context of a servlet, so it can also exploit any number of Java caching libraries.
I wonder if we could get this running on Terracotta for easy clustering?
Wow Ben...
The response among the folks still hanging out in the shop at 9pm was, "Oh my god, that would be so damn cool. He's right."
While the response below to test with opcache has been mentioned to me in IRC as well as now on the site (and I'll shortly respond), the fact is that we also did this without using any JAVA cache mechanisms either, so in fact this is a 1-1 comparison.
This is stock config to stock config. We definitely need to test cache against cache. The fact of the matter is that if we wanted to test cache mechanisms we'd need a lot more article space.
There are a ton of permutations on this idea. From the php side, you have benchmarks for APC, eAccelerator, and Zend Performance Suite at a minimum.
From the Java cache side, we have at least ehcache. Oh, and did I mention that there are some inherent potential benefits to using JDBC? And of course the fact that Java has some insane n-tier support tools that php has no equivalent for like SwarmCache , WhirlyCache and TerraCotta above. Resin supports load balancing too.
And of course everyone would benefit from different databases, and at least memcached in the mix. Oh, and eliminating the MySQL bottleneck. Or at least putting it on another machine.
Turns out this load testing this is complicated. So when you're doing results-based load testing for publication, my philosophy is to keep the tests as simple and straight forward as possible, to encourage people to test the results (hey, it's less work!).
And there's that little problem: we have to make a living! Which is why we called this out as a community issue, because we'd like to see some other people helping out with this.
I'd love to publish more, but this is exciting stuff. I think we can continue down the path of testing this solution...
One thing that we would really like to see if a servlet filter that handles the rewrite stuff, because there's a question of performance impact. If you put that code into the Drupal framework, you also run into performance questions. But you can cache the dataset in both cases, so which is faster? It's really a matter of what works, and what's actually available, not so much a question of apples-to-apples (or apples-to-oranges!) comparison.
What we're saying is this is a different approach. This is something that very few people have actually benchmarked before, and even fewer have publicized it. We know it's worth investigation by the Drupal community, and personally I think this is the future direction of PHP. But that's just an opinion.
Let's continue the conversation!
Jonathan
move rewrite rules
it makes decent sense to optionally perform the url rewrite rules in drupal since all non apache sites will benefit.
Indeed
Indeed Moshe.
I think the larger question is whether it would make more sense to perform the functions in php (at the Drupal level) or to write the rewrite filters in Java make make it more "compatable with the php version" - without changes I mean.
These are questions worth talking to the developers of the php interpreter about, IMHO.
Jonathan
I find it important to call
I find it important to call out (briefly) the specific issue around mod_rewrite compatibility that is breaking our head at the moment.
Drupal's .htaccess indicates that the rewrite engine should check for a directory or file that matches the request URI first. Barring that, it routes all traffic through index.php.
The last step is trivial in web.xml under resin. It's the first two that are issues. The webapp doesn't care whether the file exists; I believe that it's processed at a later time. However, one could conceivably write a servlet filter that handles this or redirects to the Quercus servlet if it doesn't match the first two cases.
More on this later, but I'm open to other suggestions.
mod_proxy_balancer?
why not take a hint from the rails community and use apache on the front end (no php) and mod_proxy_balancer? you could build out a fast lightweight apache reverse proxy on port 80 and connect it to x amount of instances of this running on the localhost port 1180 or something...
then you would get the performance improvement and you could run the .htaccess rules in the apache instance...
worth a shot so you don't have to change drupal.
Steve, you've got a good
Steve, you've got a good point.. If there are technologies that will allow this functionality without changing drupal and without hampering performance, then it might be worth looking at.
I'm concerned that dropping in apache again will cause another bottleneck.. It's not exactly what one might consider lightweight.
Still, I'd be interested in seeing results from a test like this. Good call!
Believe me!
I will definitely be trying this out, but I don't know which of my clients I want to make the first victim of this kind of test.
I also know that Quercus runs Drupal core without a problem, but how many Drupal developers confine themselves to Drupal core? It would be helpful to get a wiki page online somewhere so people can find information about particular modules' compatibility.
PHP cache?
I wonder what the results would look like if you'd use a PHP opcode cache such as APC.
And the answer is...
42.
Wait, no.
You're right. BUT, I wanted this to be a 1-1 test, and Aaron and I discussed this.
There are two basic things to consider.
First, every php opcache solution has a major drawback. If you use eAccelerator, it segafults under heavy load. If you use APC, it also segfaults under heavy load, but apparently due to it's lowmem problems (different reasons, same broken stuff). Zend works really well, but can also segfault, but it also costs thousands of dollars and isn't use for the majority of Drupal websites.
The second consideration is that we didn't use JAVA cache or opcache equivalent. Java kind of opcaches itself by nature, because it's architected differently than php (everything is in memory, servlets run a finite number of instances, etc). This is an Apples-to-Apples comparison, by the truest sense (see my extended comment above).
So, if you want, we can run these same numbers opcache (which one?) to java cache (turn on extended cache in java, probably ehcache, though I'm not sure it can be used in this case - have to experiment).
There's a LOT we can test. This is a starting point. I'm really interested to see if we can overcome the mod_rewrite clean urls drawback, because ultimately, that's the main problem that's holding us back from production implementation and testing.
Those numbers are also without any drupal cache on. I haven't seen a 2G p4 hyperthreaded (non dual-core) machine push 1400 requests per minute without extensive tuning before.
I think it would be worth it to find out if we can match that number with tuning, and run as close to an Apples-to-Apples comparison as possible.
Next step would be tune both environments and see how they perform against one another, but that's not as good an objective test as this one, because tuning is different for each platform.
Let's go there. I'm even willing to give you (Gerhard) access to a/the box if you want to help us run tests. I would be honored if you of all people jumped in on this.
My 2c.
Jonathan
a new interpreter for each request?
> The interpreter only has to be started once, as opposed to a new
> interpreter for each request as you would with a web server (either
> mod_php or fcgi)
i think that mod_php (on an apache with mpm_worker or mpm_winnt) can reuse the already running php interpreter just fine. been using mpm_winnt for quite some time without problems.
> which provides a shorter round trip, less memory consumption, and in
> theory, insanely fast performance.
without the additional load of a java servlet engine :)
Interpreter Re-Use
Alex,
I believe the mpm_worker and mpm_winnt do not re-use the interpreter. For one, it goes against the architecture of PHP itself, talked about by Rasmus himself also, of a "sandbox".
The mpm_worker and mpm_winnt help solve the issue of the "web-server" accepting requests, not "php" accepting requests. Those are 2 different issues, as even the web-server itself is architectured differently than php (multi-threaded vs. interpreted). I peaked into the mpm_winnt.c code and this seems to be true, however i hate to be naive and talk out of my butt :), so i'll dive in deeper for a more definitive answer and post later.
a new interpreter for each request?
> The interpreter only has to be started once, as opposed to a new
> interpreter for each request as you would with a web server (either
> mod_php or fcgi)
fcgi processes are longer living and do not get created each request.
Would be nice to see lighttpd and fcgi compared as well.
Couldn't Resin URL rewrite tags be used like lighttpd url.rewrite-final rules for drupal clean urls?
Part of the reason for wanting to compare to APC and eAccelerator is that we have these in production now.
good stuff guys.
Who are you?
The cat wanted me to ask: who are you?
I agree with you about lighttpd and fcgi as a basis of comparison - it's purely a question of time.
I do think it might be. There is some discussion in this thread on multiple approaches to this problem.
Well, in terms of bringing this to production, I think it needs more testing. Earnest is publishing an article on Drupal unit testing later today ... and you can imagine why I think we need unit tests (in addition to what I've said before about continuous integration and test driven Drupal... in light of this post, you can start to see why unit tests are critical).
Imagine if you could simply put your module code into production and run tests against it to test viability, regardless of it's deployment mechanism - that's something a solid test driven engineering platform automatically buys you.
Native PHP compilers
I blogged about Caucho Resin some time ago, then again after your benchmark.
We really need to compare with op-code caches, as painful as they are.
Another interesting direction is native PHP compilers. I guess you cannot go faster than that. For example PHP compiler by Roadsend. It is now open source, but requires Scheme, only works for PHP 4, and no 64-bit. There is also phc, but that is still a long way.
lighttpd/fastcgi info missing
You did comparisons with Apache/mod_php, but not lighttpd/fastcgi. fastcgi+APC yielded huge performance improvements for me over apache/mod_php, and my numbers are nearly as good as the Resin ones.
Secondly, what about compatibility with binary modules? What about GD, the most common requirement for PHP? Even Drupal needs it for the stats tracking to show images. What about zlib for zip file management. This list could go on and on.
Donald
Quercus supports GD,
Quercus supports GD, FYI..
From their site:
Quercus implements a growing list of PHP extensions (i.e. APC, iconv, GD, gettext, JSON, MySQL, Oracle, PDF, Postgres, etc.).
yawn
Not comparing against PHP with opcode caching on makes this article only amount to misleading propaganda.
Riiight...
Yea, because you know that's totally why we did the work - not because it's interesting or anything.
What part of "this is neat, let's put some energy into this" is unclear about this article?
Go flame bait somewhere else, or read my comment above, or better yet, replicate and put your time and money where your rather large and inconsiderate mouth is and post results yourself with opcache enabled.
Sorry, parent is right.
The Java interpreter has a built-in opcode cache.
The only fair comparison would be to enable opcode caching for Apache/mod_php(?) and use those results to judge which solution is worth putting our weight behind. They both need work.
Welcome
Welcome to the once-so-despised world of java. ;) I was wondering if your results couldn't be even more dramatic with a little bit of optimization: did you use a client JVM or a server one? (java -server). Were you running on java 5 or java 6? Newer JVMs have a lot of improvements over the (pretty good, nonetheless) version 5. How much heap did you allocate? It can be fun enabling the garbage collection log and see what percentage of time the JVM is spending doing blocking collections. Did you experiment with a couple of variants in the gc algorithm? Maybe enabling concurrent and parallel collections? :) Regarding your rewrite problem, couldn't this help? http://tuckey.org/urlrewrite/
And also don't underestimate the potential benefits you would have from using the huge number of libraries available in java. I guess next time I will check you will have been sucked in the Spring + Hibernate craze and stopped doing actual work just to evaluate which stack is better (as any other java guy does most of his time! :) ).
once so despised ?
once so despised ? those of us who despised java not (only) because of lousy performance still do so passionately ;-)) - if you dont like clothes tight around the crotch, and tried ie. lisp, you know how using java would feel ;-)))
as a language, java is IMHO a catastrophe, and even it being a "lightning fast" catastrophe changes nothing ;-)))
just my 10 dollars (it used to be 2 cents, but as we all know, dollar is falling even faster then java runs ;-)
Possibly not the forum for
Possibly not the forum for it here, but would love to get your feedback on why you think Java is so lousy. We've done a considerable amount with the language, and there are a lot of advances that certain IoC frameworks offer, and aspectJ makes things leaps and bounds more mantainable than many other languages.
Speed is not the primary constraint here, and most people are aware of that fact. PHP is fast to start up, but that startup takes time, and it happens on every request. Java takes a bit to kick off, but once it's running it maintains a steady hum. By moving the startup overhead to where it belongs, per-request overhead is significantly minimized.
(For the record.. I used autolisp back in the day, and I shudder to think about it).
db connections
Out of curiosity, how many db connections were pooled using the Resin approach? I'm not a PHP guru, although I use many PHP apps, I'm curious as to how the connection pooling alone would benefit.
Caucho is an interesting player in the Java market. They've done things like having a native linux server too; don't know if it still exists though.
I noticed on their list that they support Joomla, which happens to be the CMS that I use most of the time. I agree that the url rewrite might be a tricky issue but if that gets worked out, wow. How cool would it be to integrate a PHP app with some java stuff that is already out there?
Quercus overview and getting started guide
http://www.caucho.com/resin-3.1/doc/quercus-overview.xtp
says:
"Because Quercus compiles PHP to Java code, PHP scripts get the opcode caching of APC for free. At this time, performance of Quercus is roughtly comparable with performance of mod_php with APC, i.e. it is significantly faster (3-5 times) than mod_php running by itself."
yea, read that
Right, and the point is that you can then add Java cache, and gain access to (and this is as important) proven enterprise technology architectures with Java technology (for example, Resin's built in clustering, and JDBC, not to mention that Drupal can now be used as a frontend for Hybernate and Spring and other interesting agile java bits - in the same application context.).
Free Platform Performance Improvements..
Hi,
Interesting article. I was wondering what JVM and Resin server you were using? As the open source Resin server is not the same as the commercial version which has JNI version of IO sockets which is what makes Resin so fast.
You should consider testing on BEA JRocket JVM which is usually 2x faster than Sun JVM for server apps. Check out the Java Spec benchmarks to get a performance idea, its quite a dramatic difference. JRocket is now free for commercial use - thanks BEA! Possibly you may now see an 8x performance with Java on PHP if you run your test again.
Jrocket also has some nice performance monitoring apps built into the JVM which could monitor and measure the PHP code performance in more detail.
I looked into what the best free open source J2EE servlet engines to run this and from what i can read its Suns new open source Glassfish server which is the new reference implementation for J2EE. Started in 2005 and they seem to put alot of effort into it.
I dont have any experience with Glassfish yet, but it has favorable reviews compared to JBoss.. its interesting because its really Tomcat with an addon called Grizzly which handles scalable NIO socket much better. At first i looked at replacing the slower Open Source Resin with scalable Jetty web server but then i read that the Jetty dev team is looking into supporting Grizzly so hence i read more about it and find out about Glassfish.. There not that much difference between Tomcat and Jetty these days.. Though i wouldnt mind Jetty as there is no need to run a full J2EE container.
When i get some time I would like to do a test with all this to see how well it all runs..
Thanks for all the info
Carlo
Tried it but did not work ...
I tried it with the following configuration:
Windows XP SP2
and the latest stable software:
MySQL 5.0.45
MySQL Connector/J 5.0.7
Drupal 5.2 - customized version - runs fine with Apache
Caucho Resin 3.1.2
Java SE 6 update 2
I also did stop Apache for this test just to make sure there can be no "interference" at all.
I in the resin configuration I modified the following entry:
from
to
I started resin with
java -jar resin-3.1.2/lib/resin.jar -root-directory C:\
I don't know if it's the absolutely best configuration but other simple php pages that I put to the drupal directory started to work.
But when I tried to browse drupal, I realized that the MySQL JDBC driver was not installed, so I downloaded and unpacked that and did
the configuration according to:
http://www.caucho.com/resin-3.1/doc/db-thirdparty.xtp
but resin does not care about the CLASSPATH environment variable, so I needed to enter the following
line in the appropriate section in the beginning of resin.conf:
That was still not enough because then this JDBC driver started to trace like hell and according to
http://forums.mysql.com/read.php?39,43767,43800#msg-43800 it seemed that the debug version of the JDBC
driver is found by resin rather than the normal one, so I needed to rename debug\mysql-connector-java-5.0.7-bin-g.jar to some other file extension.
Then, with this tracing problem solved, I browsed my drupal site and resin gave the following error:
[15:42:02.946] java.sql.SQLException: Table 'sessions' was not locked with LOCK TABLES
[15:42:02.946] at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:946)
[15:42:02.946] at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:2985)
[15:42:02.946] at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1631)
[15:42:02.946] at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:1723)
[15:42:02.946] at com.mysql.jdbc.Connection.execSQL(Connection.java:3250)
[15:42:02.946] at com.mysql.jdbc.Connection.execSQL(Connection.java:3179)
[15:42:02.946] at com.mysql.jdbc.Statement.execute(Statement.java:714)
[15:42:02.946] at com.mysql.jdbc.jdbc2.optional.StatementWrapper.execute(StatementWrapper.java:658)
[15:42:02.946] at com.caucho.sql.UserStatement.execute(UserStatement.java:177)
[15:42:02.946] at com.caucho.quercus.lib.db.JdbcConnectionResource.realQuery(JdbcConnectionResource.java:566)
[15:42:02.946] at com.caucho.quercus.lib.db.Mysqli.query(Mysqli.java:536)
[15:42:02.946] at com.caucho.quercus.lib.db.MysqliModule.query(MysqliModule.java:885)
[15:42:02.946] at com.caucho.quercus.lib.db.MysqliModule.mysqli_query(MysqliModule.java:869)
[15:42:02.946] at sun.reflect.GeneratedMethodAccessor27.invoke(Unknown Source)
[15:42:02.946] at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
[15:42:02.946] at java.lang.reflect.Method.invoke(Unknown Source)
[15:42:02.946] at com.caucho.quercus.module.StaticFunction.invoke(StaticFunction.java:105)
[15:42:02.946] at com.caucho.quercus.env.JavaInvoker.call(JavaInvoker.java:613)
[15:42:02.946] at com.caucho.quercus.env.JavaInvoker.call(JavaInvoker.java:486)
[15:42:02.946] at com.caucho.quercus.env.JavaInvoker.call(JavaInvoker.java:472)
[15:42:02.946] at com.caucho.quercus.env.JavaInvoker.callCopy(JavaInvoker.java:481)
[15:42:02.946] at com.caucho.quercus.expr.FunctionExpr.evalImpl(FunctionExpr.java:180)
[15:42:02.946] at com.caucho.quercus.expr.FunctionExpr.evalCopy(FunctionExpr.java:150)
[15:42:02.946] at com.caucho.quercus.expr.AssignExpr.eval(AssignExpr.java:77)
[15:42:02.946] at com.caucho.quercus.program.ExprStatement.execute(ExprStatement.java:64)
[15:42:02.946] at com.caucho.quercus.program.BlockStatement.execute(BlockStatement.java:99)
[15:42:02.946] at com.caucho.quercus.program.Function.callImpl(Function.java:334)
[15:42:02.946] at com.caucho.quercus.program.Function.call(Function.java:274)
[15:42:02.946] at com.caucho.quercus.expr.FunctionExpr.evalImpl(FunctionExpr.java:182)
[15:42:02.946] at com.caucho.quercus.expr.FunctionExpr.eval(FunctionExpr.java:126)
[15:42:02.946] at com.caucho.quercus.program.ReturnStatement.execute(ReturnStatement.java:68)
[15:42:02.946] at com.caucho.quercus.program.BlockStatement.execute(BlockStatement.java:99)
[15:42:02.946] at com.caucho.quercus.program.Function.callImpl(Function.java:334)
[15:42:02.946] at com.caucho.quercus.program.Function.callCopy(Function.java:279)
[15:42:02.946] at com.caucho.quercus.expr.FunctionExpr.evalImpl(FunctionExpr.java:180)
[15:42:02.946] at com.caucho.quercus.expr.FunctionExpr.evalCopy(FunctionExpr.java:150)
[15:42:02.946] at com.caucho.quercus.expr.AssignExpr.eval(AssignExpr.java:77)
[15:42:02.946] at com.caucho.quercus.program.ExprStatement.execute(ExprStatement.java:64)
[15:42:02.946] at com.caucho.quercus.program.BlockStatement.execute(BlockStatement.java:99)
[15:42:02.946] at com.caucho.quercus.program.Function.callImpl(Function.java:334)
[15:42:02.946] at com.caucho.quercus.program.Function.call(Function.java:274)
[15:42:02.946] at com.caucho.quercus.program.AbstractFunction.call(AbstractFunction.java:251)
[15:42:02.946] at com.caucho.quercus.env.CallbackFunction.call(CallbackFunction.java:116)
[15:42:02.946] at com.caucho.quercus.env.SessionCallback.write(SessionCallback.java:90)
[15:42:02.946] at com.caucho.quercus.env.Env.sessionWriteClose(Env.java:4422)
[15:42:02.946] at com.caucho.quercus.lib.session.SessionModule.session_write_close(SessionModule.java:588)
[15:42:02.946] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[15:42:02.946] at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
[15:42:02.946] at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
[15:42:02.946] at java.lang.reflect.Method.invoke(Unknown Source)
[15:42:02.946] at com.caucho.quercus.module.StaticFunction.invoke(StaticFunction.java:105)
[15:42:02.946] at com.caucho.quercus.env.JavaInvoker.call(JavaInvoker.java:613)
[15:42:02.946] at com.caucho.quercus.env.JavaInvoker.call(JavaInvoker.java:486)
[15:42:02.946] at com.caucho.quercus.env.JavaInvoker.call(JavaInvoker.java:472)
[15:42:02.946] at com.caucho.quercus.env.CallbackFunction.call(CallbackFunction.java:153)
[15:42:02.946] at com.caucho.quercus.env.Shutdown.call(Shutdown.java:50)
[15:42:02.946] at com.caucho.quercus.env.Env.close(Env.java:4368)
[15:42:02.946] at com.caucho.quercus.servlet.ResinQuercusServlet.service(ResinQuercusServlet.java:160)
[15:42:02.946] at com.caucho.quercus.servlet.QuercusServlet.service(QuercusServlet.java:350)
[15:42:02.946] at javax.servlet.http.HttpServlet.service(HttpServlet.java:91)
[15:42:02.946] at com.caucho.server.dispatch.ServletFilterChain.doFilter(ServletFilterChain.java:103)
[15:42:02.946] at com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:175)
[15:42:02.946] at com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:240)
[15:42:02.946] at com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:263)
[15:42:02.946] at com.caucho.server.port.TcpConnection.run(TcpConnection.java:481)
[15:42:02.946] at com.caucho.util.ThreadPool$Item.runTasks(ThreadPool.java:685)
[15:42:02.946] at com.caucho.util.ThreadPool$Item.run(ThreadPool.java:607)
[15:42:02.946] at java.lang.Thread.run(Unknown Source)
[15:42:04.024] java.lang.NullPointerException
[15:42:04.024] at com.caucho.quercus.lib.db.MysqliModule.escapeString(MysqliModule.java:937)
[15:42:04.024] at com.caucho.quercus.lib.db.MysqliModule.mysqli_real_escape_string(MysqliModule.java:928)
[15:42:04.024] at sun.reflect.GeneratedMethodAccessor32.invoke(Unknown Source)
[15:42:04.024] at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
[15:42:04.024] at java.lang.reflect.Method.invoke(Unknown Source)
[15:42:04.024] at com.caucho.quercus.module.StaticFunction.invoke(StaticFunction.java:105)
[15:42:04.024] at com.caucho.quercus.env.JavaInvoker.call(JavaInvoker.java:613)
[15:42:04.024] at com.caucho.quercus.env.JavaInvoker.call(JavaInvoker.java:486)
[15:42:04.024] at com.caucho.quercus.env.JavaInvoker.call(JavaInvoker.java:472)
[15:42:04.024] at com.caucho.quercus.expr.FunctionExpr.evalImpl(FunctionExpr.java:182)
[15:42:04.024] at com.caucho.quercus.expr.FunctionExpr.eval(FunctionExpr.java:126)
[15:42:04.024] at com.caucho.quercus.program.ReturnStatement.execute(ReturnStatement.java:68)
[15:42:04.024] at com.caucho.quercus.program.BlockStatement.execute(BlockStatement.java:99)
[15:42:04.024] at com.caucho.quercus.program.Function.callImpl(Function.java:334)
[15:42:04.024] at com.caucho.quercus.program.Function.call(Function.java:274)
[15:42:04.024] at com.caucho.quercus.expr.FunctionExpr.evalImpl(FunctionExpr.java:182)
[15:42:04.024] at com.caucho.quercus.expr.FunctionExpr.eval(FunctionExpr.java:126)
[15:42:04.024] at com.caucho.quercus.program.ReturnStatement.execute(ReturnStatement.java:68)
[15:42:04.024] at com.caucho.quercus.program.BlockStatement.execute(BlockStatement.java:99)
[15:42:04.024] at com.caucho.quercus.program.SwitchStatement.execute(SwitchStatement.java:87)
[15:42:04.024] at com.caucho.quercus.program.BlockStatement.execute(BlockStatement.java:99)
[15:42:04.024] at com.caucho.quercus.program.Function.callImpl(Function.java:334)
[15:42:04.024] at com.caucho.quercus.program.Function.call(Function.java:274)
[15:42:04.024] at com.caucho.quercus.program.AbstractFunction.call(AbstractFunction.java:243)
[15:42:04.024] at com.caucho.quercus.env.CallbackFunction.call(CallbackFunction.java:106)
[15:42:04.024] at com.caucho.quercus.lib.RegexpModule.pregReplaceCallbackImpl(RegexpModule.java:686)
[15:42:04.024] at com.caucho.quercus.lib.RegexpModule.pregReplaceCallback(RegexpModule.java:929)
[15:42:04.024] at com.caucho.quercus.lib.RegexpModule.preg_replace_callback(RegexpModule.java:890)
[15:42:04.024] at sun.reflect.GeneratedMethodAccessor26.invoke(Unknown Source)
[15:42:04.024] at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
[15:42:04.024] at java.lang.reflect.Method.invoke(Unknown Source)
[15:42:04.024] at com.caucho.quercus.module.StaticFunction.invoke(StaticFunction.java:105)
[15:42:04.024] at com.caucho.quercus.env.JavaInvoker.call(JavaInvoker.java:613)
[15:42:04.024] at com.caucho.quercus.env.JavaInvoker.call(JavaInvoker.java:486)
[15:42:04.024] at com.caucho.quercus.env.JavaInvoker.call(JavaInvoker.java:472)
[15:42:04.024] at com.caucho.quercus.env.JavaInvoker.callCopy(JavaInvoker.java:481)
[15:42:04.024] at com.caucho.quercus.expr.FunctionExpr.evalImpl(FunctionExpr.java:180)
[15:42:04.024] at com.caucho.quercus.expr.FunctionExpr.evalCopy(FunctionExpr.java:150)
[15:42:04.024] at com.caucho.quercus.expr.AssignExpr.eval(AssignExpr.java:77)
[15:42:04.024] at com.caucho.quercus.program.ExprStatement.execute(ExprStatement.java:64)
[15:42:04.024] at com.caucho.quercus.program.BlockStatement.execute(BlockStatement.java:99)
[15:42:04.024] at com.caucho.quercus.program.Function.callImpl(Function.java:334)
[15:42:04.024] at com.caucho.quercus.program.Function.call(Function.java:274)
[15:42:04.024] at com.caucho.quercus.expr.FunctionExpr.evalImpl(FunctionExpr.java:182)
[15:42:04.024] at com.caucho.quercus.expr.FunctionExpr.eval(FunctionExpr.java:126)
[15:42:04.024] at com.caucho.quercus.program.ExprStatement.execute(ExprStatement.java:64)
[15:42:04.024] at com.caucho.quercus.program.BlockStatement.execute(BlockStatement.java:99)
[15:42:04.024] at com.caucho.quercus.program.Function.callImpl(Function.java:334)
[15:42:04.024] at com.caucho.quercus.program.Function.call(Function.java:274)
[15:42:04.024] at com.caucho.quercus.expr.FunctionExpr.evalImpl(FunctionExpr.java:182)
[15:42:04.024] at com.caucho.quercus.expr.FunctionExpr.eval(FunctionExpr.java:126)
[15:42:04.024] at com.caucho.quercus.program.ExprStatement.execute(ExprStatement.java:64)
[15:42:04.024] at com.caucho.quercus.program.BlockStatement.execute(BlockStatement.java:99)
[15:42:04.024] at com.caucho.quercus.program.IfStatement.execute(IfStatement.java:78)
[15:42:04.024] at com.caucho.quercus.program.BlockStatement.execute(BlockStatement.java:99)
[15:42:04.024] at com.caucho.quercus.program.IfStatement.execute(IfStatement.java:75)
[15:42:04.024] at com.caucho.quercus.program.BlockStatement.execute(BlockStatement.java:99)
[15:42:04.024] at com.caucho.quercus.program.Function.callImpl(Function.java:334)
[15:42:04.024] at com.caucho.quercus.program.Function.callCopy(Function.java:279)
[15:42:04.024] at com.caucho.quercus.expr.FunctionExpr.evalImpl(FunctionExpr.java:180)
[15:42:04.024] at com.caucho.quercus.expr.FunctionExpr.evalCopy(FunctionExpr.java:150)
[15:42:04.024] at com.caucho.quercus.expr.AssignExpr.eval(AssignExpr.java:77)
[15:42:04.024] at com.caucho.quercus.program.ExprStatement.execute(ExprStatement.java:64)
[15:42:04.024] at com.caucho.quercus.program.BlockStatement.execute(BlockStatement.java:99)
[15:42:04.024] at com.caucho.quercus.program.Function.callImpl(Function.java:334)
[15:42:04.024] at com.caucho.quercus.program.Function.callCopy(Function.java:279)
[15:42:04.024] at com.caucho.quercus.expr.FunctionExpr.evalImpl(FunctionExpr.java:180)
[15:42:04.024] at com.caucho.quercus.expr.FunctionExpr.evalCopy(FunctionExpr.java:150)
[15:42:04.024] at com.caucho.quercus.expr.AssignExpr.eval(AssignExpr.java:77)
[15:42:04.024] at com.caucho.quercus.program.ExprStatement.execute(ExprStatement.java:64)
[15:42:04.024] at com.caucho.quercus.program.BlockStatement.execute(BlockStatement.java:99)
[15:42:04.024] at com.caucho.quercus.program.QuercusProgram.execute(QuercusProgram.java:239)
[15:42:04.024] at com.caucho.quercus.page.InterpretedPage.execute(InterpretedPage.java:61)
[15:42:04.024] at com.caucho.quercus.page.QuercusPage.executeTop(QuercusPage.java:119)
[15:42:04.024] at com.caucho.quercus.servlet.ResinQuercusServlet.service(ResinQuercusServlet.java:123)
[15:42:04.024] at com.caucho.quercus.servlet.QuercusServlet.service(QuercusServlet.java:350)
[15:42:04.024] at javax.servlet.http.HttpServlet.service(HttpServlet.java:91)
[15:42:04.024] at com.caucho.server.dispatch.ServletFilterChain.doFilter(ServletFilterChain.java:103)
[15:42:04.024] at com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:175)
[15:42:04.024] at com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:240)
[15:42:04.024] at com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:263)
[15:42:04.024] at com.caucho.server.port.TcpConnection.run(TcpConnection.java:481)
[15:42:04.024] at com.caucho.util.ThreadPool$Item.runTasks(ThreadPool.java:685)
[15:42:04.024] at com.caucho.util.ThreadPool$Item.run(ThreadPool.java:607)
[15:42:04.024] at java.lang.Thread.run(Unknown Source)
[15:42:04.024] Caused by: com.caucho.quercus.QuercusExecutionException: java.lang.NullPointerException
[15:42:04.024] at com.caucho.quercus.lib.db.MysqliModule.escapeString(MysqliModule.java:937)
[15:42:04.024] at com.caucho.quercus.lib.db.MysqliModule.mysqli_real_escape_string(MysqliModule.java:928)
[15:42:04.024] at sun.reflect.GeneratedMethodAccessor32.invoke(Unknown Source)
[15:42:04.024] at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
[15:42:04.024] at java.lang.reflect.Method.invoke(Unknown Source)
[15:42:04.024] at com.caucho.quercus.module.StaticFunction.invoke(StaticFunction.java:105)
[15:42:04.024] at com.caucho.quercus.env.JavaInvoker.call(JavaInvoker.java:613)
[15:42:04.024] at com.caucho.quercus.env.JavaInvoker.call(JavaInvoker.java:486)
[15:42:04.024] at com.caucho.quercus.env.JavaInvoker.call(JavaInvoker.java:472)
[15:42:04.024] at com.caucho.quercus.expr.FunctionExpr.evalImpl(FunctionExpr.java:182)
[15:42:04.024] at com.caucho.quercus.expr.FunctionExpr.eval(FunctionExpr.java:126)
[15:42:04.024] at com.caucho.quercus.program.ReturnStatement.execute(ReturnStatement.java:68)
[15:42:04.024] at com.caucho.quercus.program.BlockStatement.execute(BlockStatement.java:99)
[15:42:04.024] at com.caucho.quercus.program.Function.callImpl(Function.java:334)
[15:42:04.024] at com.caucho.quercus.program.Function.call(Function.java:274)
[15:42:04.024] at com.caucho.quercus.expr.FunctionExpr.evalImpl(FunctionExpr.java:182)
[15:42:04.024] at com.caucho.quercus.expr.FunctionExpr.eval(FunctionExpr.java:126)
[15:42:04.024] at com.caucho.quercus.program.ReturnStatement.execute(ReturnStatement.java:68)
[15:42:04.024] at com.caucho.quercus.program.BlockStatement.execute(BlockStatement.java:99)
[15:42:04.024] at com.caucho.quercus.program.SwitchStatement.execute(SwitchStatement.java:87)
[15:42:04.024] at ._db_query_callback(/C://drupal/includes/database.inc:148)
Any ideas what do I possibly do wrong and how to fix it? It would be appreciated much.
Caucho Quercus
I've used the module, with a lot of success, linking java semantic web libraries with php code.
I am unable to get phpBB3
I am unable to get phpBB3 running on quercus. I am getting this exception:
500 Servlet Exception
java.io.IOException: The process cannot access the file because another
process has locked a portion of the file
at java.io.FileOutputStream.writeBytes(Native Method)
at java.io.FileOutputStream.write(FileOutputStream.java:260)
Awesome
But why is Drupal so slow to begin with? 5 Requests per second is just slooooow!
Drupal so slow???
Drupal is not slow check your internet connectivity please!! :)
Post new comment