My url is as follows
/fcgi-bin/clireports.fcgi?sfPageId=param1&sfBoxId=param2&sfPagecId=param3&sfUsername=param4&sfSession=param5&sfSubmit=param6&showSampleReport=param7&saveAndAdd=param8
My questions is this:
Is there any performance issue when sending so many parameters in the query string ? In my case I am sending 8 parameters in the query string .
Will my website become slow because of this ?
Please enlighten me on this .
The performance is not about number of parameters (or just a little) but about number of bytes send.
The more data you send, the more it's costly to transfer/parse.
Remember that every browser has a hard limit on the maximum number of characters a GET request can handle. I recomment you not to use more than 255 characters to be on the safe side, but you can go higher (IE's limit is around 2000).
If you need more data, use POST.
Finally, your website will not become slow because of this. Because many other factors take much time than parsing GET request (take something like DB connection, or just php warmup)
Shouldn't be any issues, might be worth doing a POST request to clean up your request a bit, but other than that you shouldn't notice any issues as far as performance...just don't exceed the "limits" that vary depending on browser
Related
Sometimes, I request a page and it takes too long to receive a response for the request and then load the page (sometimes the request times out and I never get a response).
However, if I open a new tab, copy the exact URL, and then append it with an arbitrary GET variable (with an arbitrary value), the request gets a response very fast (as the normal state is) and the page then loads, although the request wasn't getting a response without that arbitrary GET variable.
For a fake example, if I request:
http://example.com/
It might take a long time just loading, not receiving any response yet, but if I just open a new tab (at the same time), and request:
http://example.com/?foo=bar
It loads like magic!
Why is that happening to me? what could be the reason along the road between my browser and the page's server? does that have any relevance to ISP servers caching?
Any explanation is much, much appreciated, as I really am eager to know the reason!
P.S: I'm in Syria (where anything crazy is possible in Internet network), and this doesn't happen only to me, but to all people I know.
EDIT:
Note that it happens even if a URL has a GET variable already, for a real example I have a blog, and sometimes requesting this page (I changed the domain):
http://myblogdomain.com/wp-admin/admin.php?page=jetpack
Takes too long time (and sometimes it times out), but if I open a new tab and request:
http://myblogdomain.com/wp-admin/admin.php?page=jetpack&foo=bar
It loads fast (as normal).
It's likely that there is a caching proxy and/or firewall between you and the rest of the internet. There is probably a rule in the proxy that says URLs with GET parameters can pass through since they are likely to return unique content, but URL's without parameters must be fetched through a cache. The cache is likely overloaded or broken.
You probably have a proxy that needs to do some lengthy process (content check, DNS lookup, etc) once per domain.
When you open the second tab, that length process would have already started (for the first tab), so it wouldn't take as long.
If this is the case, opening the first tab with a querystring and the second tab without would still result in the second tab loading faster.
1-form a web developer perspective :
to get more details about what is taking this time , i could the network tab of my best friend (firebug )
as you may see above , i can see how much time spent on each step on the page .
2-even though i think this question should be moved to https://serverfault.com/ to get answers form networks geeks
As far as a performance issue, the server is performing fine. With the exception of the http response wait times. This will become more of an issue as we grow our line of online services. All things being equal, I’m confused how this new server is it not loading pages as quickly as an older server running multiple websites, logging, etc…
Here is a screen shot from http://www.gtmetrix.com the online testing tool I’ve been using. These results are consistent regardless of time of day, The numbers here don’t make sense. The new site page is 75% smaller, yet its total time to live is only 26ms faster. In the below image the left side is NEW SERVER, the right side is OLD SERVER
The left portion of the timeline is the Handshaking portion. So, you can see, the new server, is about the same speed. The purple middle section, that represents wait time. It’s about 4 times the delay in milliseconds as OLD SERVER. The Grayish section on the right represents the actual time to download the file. You will also notice that the new server is significantly faster at downloading the response, this is most likely due to the 75% decrease in the response size.
You can see the complete results for the new server here. http://gtmetrix.com/reports/204.193.113.47/Kl614UCf
Here’s a table of the differences that I’m aware of, let me know if you see one that could be the culprit. I forgot to add this to the table, but the old server, is in production, right now serving requests, when www.gtmetrix is hitting it. In contrast, to my New server, which is just me connecting and generating requests.
My current hypothesis, is that the slowness is caused some combination of the server being virtualized, incorrect IIS settings, or the difference between 32bit and 64bit OSes
OK...
The server in in Sarasota(?), the test agent is in Vancouver so roughly 4,356KM apart (as the crow flies) so the best round trip time you could hope for is around 45ms.
Given it won't be a direct route and things like routers etc. will that add latency then the 155ms round-trip you seem to be getting is pretty reasonable.
Looking at the request for the HTML page the 344ms to complete it a pretty good time - basically 114ms to set up the connection, 115ms to receive the first bytes from server and then 155ms to get the complete response.
Unless you get decrease the roundtrip time then this time isn't going to improve much - have you tried testing from gtmetrix's Dallas server as a comparison?
If it is a slow server response then something like PAL (http://pal.codeplex.com/) is worth using as a first look to see what's happening on the server but I'd also look how quickly the SQL server is responding to the queries that are used on the test page.
A couple of things you want to look at later in the waterfall...
For the two files that are hosted from ajax.aspnetcdn.net it takes longer to resolve their DNS name than it does to download them so you may want to consider hosing them yourself
For the text based content e.g. HTML, CSS, JS etc. what level of gzip compression are you applying and are the compressed files being cached on the server? (the server times for them look a bit long)
Looking at the complete results, it seems the lower bound for the wait times would be 115ms. Not a single request is faster, most are around 125ms, and judging from the requested resources, there's a lot of static resources as well, so serving the response should not involve a lot of CPU. Even though responses are as small as 123 bytes, there's still this delay.
So it looks like a general issue, possibly not even related to IIS. Here some ideas how I'd try to debug this.
How long does a ping roundtrip take? (i.e. Is it a general network issue, routing etc.?)
How long do HTTP requests take when done from the server box (e.g. to localhost)? (If they all take more than ~100ms, start profiling inside the server box)
I'm currently creating a small todo site, and I have multiple questions related to ajax and performance... So here are my questions:
In order to reduce number of request, I want to get all data from one request, so I will pass for example these attributes:
1.1. to get 1 task:
entity=task&id=2&type=single&extra=subtasks%%contexts
1.2. to get list of tasks and events in one listing:
entity=task%%event&user_id=2%type=multiple%order=date&limit=10
Do you think it will reduce number of request and improves some how the performance?
If all requests will go to one file, it means that that .php file might be quite big, is it bad? Or it not really matter?
For the listing. I will be able to change the order of listing and maybe filter it somehow. Do you think it will be better to load all tasks and event to
To keep things fast there are two concerns:
Reduce HTTP requests – if you need two separate bits of data, send them in one file.
Keep the content delivered in each AJAX request small – gzip and caching works wonders here.
So, yes, bundle things together. Large PHP file doesn't make any difference, DB queries are the only real bottleneck in a normally trafficked webpage.
For filtering and sorting, a good approach is to use JSON for the AJAX response, then sort/filter based on that on the client side if you are talking about a smallish number of items (probably upto 1000 items). If you have 100s of thousands of items, then returning a subset from the server will be better.
I am trying to send a very long POST request as an AJAX call in my application. Up until the query length exceeds ~7585 characters (incl. page name) the request goes through fine. However, there is a definite limit going on as adding a single character will make the request fail.
I have ensured that the tomcat server.xml config does not specify maxPostSize, and the documentation says it defaults to 2MB, which is way more room than I am using.
Am I missing something here? I am suspicious that this is a limitation being imposed by the web browser (Firefox 3.6.18).
If this is just an unfortunate truth, how do people get around this? By batching the data into smaller chunks manually? It seems like this would be a common problem for people. Thanks!
What are the strengths of GET over POST and vice versa when creating an ajax request? How do I know which I should use at any given time? Is it a security-minded decision?
Also, what is the difference in how they are actually sent?
GETs should be used for idempotent operations, that is operations that can be safely repeated more than once without changing anything. Browsers will cache GET requests (for normal and AJAX requests)
POSTs should be generally be used for non-idenpotent operations, like saving something. Although you can use them for other operations if you want.
Data for GETs is sent over the URL query string. Data for POSTs is sent separately. Some browsers have a maximum URL length (I think Internet Explorer is 2048 characters), and if the query string becomes too long you'll get an error.
You should use GET and POST requests in AJAX calls just as you would use GET and POST requests in normal calls. Basic rule of thumb:
Will the request modify anything in your Model?
YES: The request will modify (add/update/delete) data from your data store,
or in some other way change the state of the server (cause creation of
a file, for example). Use POST.
NO: The request will not affect the state of anything (database, file system,
sessions, ...) on the server, but merely retrieve information. Use GET.
POST requests are requests that you do not want to accidentally happen. GET requests are requests you are OK with happening by a user pointing a browser to via a URL.
GET requests can be repeated quite simply since their data is based in the URL itself.
You should think about AJAX requests like you think about regular form requests (and their GET and POST)
The Yahoo! Mail team found that when using XMLHttpRequest, POST is implemented in the browsers as a two-step process: sending the headers first, then sending data. So it's best to use GET, which only takes one TCP packet to send (unless you have a lot of cookies). The maximum URL length in IE is 2K, so if you send more than 2K data you might not be able to use GET.
http://developer.yahoo.com/performance/rules.html#ajax_get