here is the url send by solrnet
http://localhost:8983/m_review/maincore/select?facet.field=p_catalog_id&facet=true&fq=p_B2BShow%3a%5b1+TO+*%5d&fq=p_review_type%3a1&sort=p_review_date+desc&rows=4&q=%3a&?
the url always ends with &?
and the costed time during the search is 10 times slower than the normal url
how to solve this problem?
thanks in advance
It may be a bug, but I've never seen any perf or behavior difference because of it. Solr just ignores it.
You might want to try compiling the latest source and see if it fixes your issue. But as I said, I really doubt that's the real cause of a 10x slowdown.
Related
This is somewhat of a hard question, as I've been working to fix this for quite some time now, but I am running out of ideas.
The problem: The loading time for the page takes to long. It looks kinda "creepy". I've already compressed files, moved them together and all of this. But I am having a major problem, which I found no answer of:
https://i.imgur.com/jKzc7uy.jpg
I've removed some parts which delayed the page loading already. However, as you can see, from 600ms to 800ms and ~900ms to ~1500ms is completely empty. Nothing is loading. Thats almost 800s of a total of 1.88s loading time, which the page doesn't do anything.
How can I remove that empty space?
You can use this free tool provided by Google for ideas on improving page loading times for mobile and desktop:
https://developers.google.com/speed/pagespeed/insights/?hl=en&url=https%3A%2F%2Fm.imgur.com%2FjKzc7uy&tab=desktop
Earlier, phantomJS core-dumped during a URL request
and related processing. (My shell does not capture core,
so I can't tell you what happened.)
I presume this is a bug in phantomJS. But more generally,
what is the recommended best practice for handling fatal
behavior in phantomJS? Does the process just return non-zero
if it fails?
Thanks.
PhantomJs has lots of little problems, crashing may be because it's out of memory (even if you have free pagefile space) or because you use it too many times without restarting, or if you try loading in resources it doesn't process properly (like .otf webfonts) or if there's an error in your script, or if you try rendering an image that's too big, or.... well, you get the picture.
The best way to troubleshoot this is to use console.write() statements in your script (everywhere, including in all the WebPage callbacks) and use this to narrow down where the crash is occurring.
The troubleshooting technique is rather crude, but I used this to great effect in my own usages of PhantomJs.
I'm very keen to update a number of our servers to PHP 5.3. This would be in readiness for Zend Framework 2 and also for the apparent performance updates. Unfortunately, i have large amounts of legacy code on these servers which in time will be fixed, but cannot all be fixed before the migration. I'm considering updating but disabling the deprecated function error on all but a few development sites where i can begin to work through updating old code.
error_reporting(E_ALL ^ E_DEPRECATED);
Is there any fundamental reason why this would be a bad idea?
Well, you could forget that you set the flag and wonder why your application breaks in a next PHP update. It can be very frustrating to debug an application without proper error reporting. That's one reason I can think of.
However, if you do it, document it somewhere. It can save you a couple of hours before you remember setting the flag at all.
If you haven't already you should read the migration guide with particular focus on Backward Incompatible Changes and Removed Extensions.
You have bigger issues than deprecation. Ignoring E_DEPRECATED will not suffice. Because of the incompatible changes there will also be other type of errors or, maybe, even worse, unexpected behaviors.
Here's a simple example:
<?php
function goto($line){
echo $line;
}
goto(7);
?>
This code will work fine and output 7 in PHP 5.2.x but will give you a parse error in PHP 5.3.x.
What you need to do is take each item in that guide and check your code and update where needed. To make this faster you could ignore the deprecated functionality in a first phase and just disable error reporting for E_DEPRECATED, but you can't assume that you will only get some harmless warnings when porting to another major PHP branch.
Also don't forget about your hack and fix the deprecated issues as soon as possible.
Regards,
Alin
Note: I tried to answer the question from a practical point of view, so please don't tell me that ignoring warnings is bad. I know that, but I also know that time is not an infinite resource.
I presume you have some kind of test server? If not, you really should set one up and test your code in PHP 5.3. If your code is thoroughly Unit Tested, testing it will take seconds, and fixing it will be fairly quick too, as the unit tests will tell you exactly where to look. If not, then consider making Unit Testing it all a priority before the next release, and in the meantime go through it all, first with E_DEPRECATED warnings disabled and fix anything which comes up, then with it re-enabled once you have time. You could also run a global find-and-replace for easier to fix errors.
The most troublesome bug is the occasional one; there is no definite way to reproduce it.
I've searched a lot on this topic,
and the most probable reason is the charset,
and I've taken some actions by setting the default charset as utf8 in .htaccess (I'm using Apache),
but it still happens, again occasionally!
Have you guys any tips other than setting the default charset to fix it?
As a side note that according to my own experience it happens mostly when the form is submitted from IE, if not all.
Are you using PHP?
Usually any time I hit a blank page, it's because there's an elusive bug in php someplace and errors are turned off.
Just an alternative path you might investigate.
We've got Localsolr (2.9.1 lucene-spatial library) running on Solr 1.4 with Tomcat 1.6. Everything's looking good, except for a couple little issues.
If we specify fl=id (or fl= anything) and wt=json it seems that the fl parameter is ignored (thus we get a lot more detail in our results than we'd like).
If we specify fl=id and leave out wt=json (which defaults to returning xml results), we get the expected fields back. We'd really prefer to use wt=json because the results are easier for us to deal with (also, the same issue also arises with wt=python and wt=ruby).
Ideas? Known issue? Workarounds?